-
Notifications
You must be signed in to change notification settings - Fork 140
Description
I'm seeing some of our CI builds fail. In particular, these jobs are using an SDK that was cross-targetting the OS that runs the failing build.
MSBUILD : error MSB4166: Child node "8" exited prematurely. Shutting down. Diagnostic information may be found in files in "/tmp/msbuilddebuglogs" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
0 Warning(s)
1 Error(s)
Often the failure occurs in the arcade build, but arcade sometimes completes and then another repo shows the error.
The MSBUILDDEBUGPATH that is mentioned does not have any files in it. That doesn't change when I set MSBUILDDEBUGENGINE=1 or when I set it to another path.
Looking at the binlog of a failed arcade build shows that the node did some work and suddenly went missing.
journalctl shows an OOM kill:
Feb 26 11:00:51 3a8321f4-540e-4e5f-bfea-aa8f2a089f6d kernel:
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg
=/user.slice/user-0.slice/session-17.scope,task=dotnet,pid=45077,uid=0
Feb 26 11:00:51 3a8321f4-540e-4e5f-bfea-aa8f2a089f6d kernel: Out of memory: Killed process 45077
(dotnet) total-vm:41361040kB, anon-rss:6604848kB, file-rss:0kB, shmem-rss:52316kB, UID:0
pgtables:13836kB oom_score_adj:0
-> The .NET process was using 6.3GB of memory.
Bisecting vmr suggests dotnet/dotnet#4810 introduced this regression.
@jkotas do you have some thoughts what runtime change might be causing the higher memory usage?
cc @omajid
Metadata
Metadata
Assignees
Labels
Type
Projects
Status