You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The inner binlog appears 100% successful, the error appears to be "outside" the inner MSBuild but still "inside" the Exec.
(I don't know if this is the exact OOM kill that caused the error--I ran some other simulations to see what it does and don't know how to differentiate them. The build takes long enough that I didn't want to just rerun it.)
A few things we can try:
Remove libraries that we're 100% confident no future builds will use to reduce overall footprint.
Investigate situations that might be using more memory than necessary.
I wonder if calling so many Execs with inner builds might be causing some particularly bad behavior in the binlog logger. I want to try this out with the 5.0 changes (no more Execs) to see if it still happens there, and play with the limit.
Upgrade the distro version.
Upgrade the .NET Core version.
Disable binlogs. (😢 please, no.)
I haven't tried to actually get a core dump, not sure if it'll actually have anything valuable in this situation. Maybe it would let MSBuild improve its error logging or handle this without a segfault in a future version.
I used --memory 512MB on my docker run command to repro the SBRP error.
The text was updated successfully, but these errors were encountered:
Perhaps adding something to log memory usage to see how much memory the build is consuming at different stages to help identify memory requirements for the build.
When I build soruce-build-reference-packages
cd5a8c6f
with low memory, it fails with this end of log:There's a segfault in an Exec task. From the binlog (also shows up on console):
This same error has been showing up as flakiness in the SBRP official build.
When I run the build locally, I see an error like this in `dmesg | grep -C10 'out of memory':
The inner binlog appears 100% successful, the error appears to be "outside" the inner MSBuild but still "inside" the Exec.
(I don't know if this is the exact OOM kill that caused the error--I ran some other simulations to see what it does and don't know how to differentiate them. The build takes long enough that I didn't want to just rerun it.)
A few things we can try:
Exec
s with inner builds might be causing some particularly bad behavior in the binlog logger. I want to try this out with the 5.0 changes (no moreExec
s) to see if it still happens there, and play with the limit.I haven't tried to actually get a core dump, not sure if it'll actually have anything valuable in this situation. Maybe it would let MSBuild improve its error logging or handle this without a segfault in a future version.
I used
--memory 512MB
on mydocker run
command to repro the SBRP error.The text was updated successfully, but these errors were encountered: