Update backtrace to 0.3.57

[jclulow]

Adds support for symbol resolution on illumos systems.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify submodules.

[jclulow]

(will combine with the resolution to #84254 to fix stack unwinding and functional backtraces on illumos systems)

[Mark-Simulacrum]

Can you say more about the newly added docs which indicate "inaccurate unwind information can lead this library to segfault" -- is any additional mitigation or whatever necessary in std to avoid problems here? I'm not quite clear if this is a case of "malformed executables -> obviously problematic" or what the situation here is in practice.

cc @alexcrichton

[alexcrichton]

Oh sure yeah, that's just documenting behavior since the beginning of time, nothing is new here. Unwind information that's referring to refers to .eh_frame or the equivalent. This is generated by compilers, loaded with the rest of the executable, and parsed by _Unwind_Backtrace (or other unwinding runtimes). The backtrace crate doesn't deal with any of this itself, it's just documenting what's always been a dependency.

This is very different from debug information which is loaded at runtime (and could mismatch the executable). The backtrace crate should never segfault (pending bugs in the crate itself) on invalid or bad debug info.

tl;dr: no change, just documenting what's always been there. This isn't an issue afaik because there's no way to feed in arbitrary unwind info.

[Mark-Simulacrum]

Ah sounds great, that pretty much matched what I had expected but the new docs surprised me a bit. Maybe worth a commit to clarify that segfaults aren't expected unless, like, your compiler has bugs in the unwind generation or so (which, seems true with or without the crate).

Thanks!

@bors r+

[bors]

📌 Commit d21fb2b has been approved by Mark-Simulacrum