rustc segfaults when printing a backtrace for ICEs when debug=true is set

[Aaron1011]

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:

1. Fix the libbacktrace bug - I think this should be fairly straightforward, but I haven't attempted it yet.
2. Switch over to using backtrace-rs's gimli backend - 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.

[Mark-Simulacrum]

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]

It would probably also be a good idea to investigate why 2.1 GB of debuginfo is getting generated - this seems really excessive.

You pretty much never want debug=true. For backtraces, all you need is debuginfo-level=1.

debug=true is for stepping rustc in 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]

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]

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 #29

[Aaron1011]

With #70361 merged, this can be closed