i've been trying to do a
./x.py build --stage 1 of rustc since yesterday morning without any luck
llvm-dsymutil is invoked, and that freezes my computer and I have to reboot
what platform? Linux? If so, which distribution?
MacOSX 10.14 mojave
I've tried it again with the activity monitor open and it appears that
kernel_task consume all resources and freeze.
the freeze happens so fast that the activity monitor never refreshes, so its hard to tell what's actually going on - I can't see memory consumption or CPU usage
I can try
straceing what happens, but I need to look up how to do that on OSX
let me try that - brb after my computer crashes
weird so I left my computer frozen, went grab a coffee, and now its not frozen anymore :/
i wonder if opening xcode right before, which installed something, fixed the issue, or whether piping the system logs to a file did
if it makes kernel spin up that’s a kernel bug
do report it to Apple
I bet it’ll have something to do with APFS
i have a mojave system at home
so I'll also try to reproduce this tonight
BTW @gnzlbg i think the
strace equivalent on "OS X" is
dtruss doesn't work in mjoave anymore - one has to use
i collected a log, but everything worked out fine this time =/ I have tried it 6 times since yesterday midday, and they all froze the computer
for like > 15 min till i rebooted
the only different things i did this time was 1) opening xcode before, which installed something, and 2) collect a log
/me wonders if he should go back to the previous "OS X" version
dtruss was never properly supported =/ you can use Instruments if you need more info that what
but I don't know how to use instruments for that =/
So everything froze again but now I’m not collecting logs
clearly your only choice is to always collect logs just to avoid Schrodinger's Cat freezing
I’m going to wait
But it’s rustc_codegen_llvm again
Maybe 8Gb of Ram isn’t enough?
So it’s been compiling for 40 minutes now but I managed to start dumping logs after the first 20
The computer isn’t fully frozen, but almost
So I was able to collect a better log and it appears that memory pressure is the reason
So I was able to get a better log and it appears that memory pressure is the issue
When dsymutil starts, the kernel starts killing processes like crazy, that’s probably the oom killer at work
There are many:
kernel: memorystatus: killing_idle_process ...
llvm-dsymutil starts executing.