Repository navigation
rustc segfaults when printing a backtrace for ICEs when debug=true is set #69151
Description
When debug=true is set in config.toml, my machine generates a librustc_driver.so with a size of 2.2 GB, of which 2.1 GB is debuginfo. This ends up triggering ianlancetaylor/libbacktrace#32. Since backtrace-rs ignores errors from libbacktrace, we continue trying to print the backtrace, which leads to a segfaut since the strtab has been freed due to the libbacktrace error.
There are a couple of ways that we can address this:
- Fix the
libbacktracebug - I think this should be fairly straightforward, but I haven't attempted it yet. - Switch over to using
backtrace-rs'sgimlibackend - however, I don't think it's feature-complete atm.
It would probably also be a good idea to investigate why 2.1 GB of debuginfo is getting generated - this seems really excessive.
Activity
Mark-Simulacrum commentedon Feb 14, 2020
cc @eddyb for debuginfo size, though I imagine this is just another case where our defaults being =2 vs. =1 is probably not ideal.
eddyb commentedon Feb 15, 2020
You pretty much never want
debug=true. For backtraces, all you need isdebuginfo-level=1.debug=trueis for steppingrustcin a debugger and inspecting variables... which I'm not really aware of anyone doing (with perhaps the rare exception of a crash inside LLVM?)MeFisto94 commentedon Feb 15, 2020
Note that the same happens when building servo in debug mode, it's just that when 2GiB of Debug Symbols are exceeded libbacktrace failed.
The actual error is ianlancetaylor/libbacktrace#29, where there even is a patch added, I just need to try it out.
The read() call failing just triggers the bug of not properly failing and/or a premature free of the table.
MeFisto94 commentedon Feb 15, 2020
The patch at ianlancetaylor/libbacktrace#29 fixes things, but mmapio should still be used, which actually also removes the trigger condition for the bug present in
#29Aaron1011 commentedon Jun 1, 2020
With #70361 merged, this can be closed