While having a look into a layout-related panic, I found that sometimes when servo crashes, it takes _all_ my memory with it.
- I'm using linux (fedora 21) - I see it maybe 80% of the time in a debug build (the other ~20% are clean crashes which just exit after stacktrace) - I've never seen it do this in a release build I don't know whether this is servo, or whether (perhaps more likely) rust has some builtin panic-diagnostic behavior which is going out of control, but I thought I'd post here in case anyone has seen it before, or has an idea what might be causing it. For brevity, I've put the console output and relevant strace snippet into a gist: https://gist.github.com/gfxmonk/4c3a67ad42a521f43c88 Basically, on the console I get a panic! stacktrace from the failure in the layout code. I then get a stacktrace from the servo constellation in RecvError, which seems fairly reasonable. After that however, servo (along with my entire X server) becomes unresponsive, and system monitor shows servo rapidly consuming 100% of RAM until I kill it. Perhaps more usefully, if I use `ulimit` to only allow it a couple GB of my memory and run it under `strace` (relevant output included in the gist), I see that after it write()s the stacktrace strings to the console, the next thing it does is just to `mmap` the world in increasingly large quantities, until it runs out of memory and dies. I guess that series of syscalls could probably fit any number of runaway allocation scenarios, but perhaps someone has an idea what might be causing it, or how to narrow down the possible culprits a little? Does servo have its own crash diagnostics, or is this more likely the rust runtime misbehaving? Cheers, - Tim _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
