op-reth: print a backtrace when an integration test dies on a signal

[sebastianst]

Stacked on #21909 — review that first; this PR's diff is the second commit only.

Makes the next recurrence of #20973 yield a faulting stack. Instrumentation only: no behavior change to any test, no effect unless a fatal signal fires.

p2p_version::peers_negotiate_eth_69 segfaults during teardown after its body has passed. A binary killed by a signal produces no Rust backtrace — RUST_BACKTRACE only covers panics — so five recurrences over two months have yielded nothing beyond the signal number, and it has never reproduced locally across 570+ attempts. Investigation is stalled for want of a stack.

Core dumps can't supply one. On the CircleCI Docker executor /proc/sys is read-only so core_pattern cannot be set, and the host's pipe pattern makes the kernel write the core outside the container — verified by running an actual segfault in the base image. An in-process handler needs no privileges, no artifacts and no CI config, and works locally.

The faulting thread name is the payload. It discriminates directly between the candidate causes enumerated in this analysis — a database atexit destructor racing its own live threads, background threads outliving process exit, or a runtime teardown race.

Output against a simulated teardown crash:

=== fatal signal 11 in thread 'mdbx-rs-txn-mgr' faulting address 0x0000000000000000 ===
.../deps/flaky-58aa09ba589b158c(+0x362db) [0x560a585772db]
/usr/lib/libc.so.6(+0x3e270) [0x7f6e7d23e270]
...

Two details worth knowing before reviewing the handler:

The stack is emitted in two stages, and the order is load-bearing. backtrace_symbols_fd runs first: it writes straight to the fd and does not call malloc. std::backtrace::Backtrace runs second for names and line numbers — its symbolization allocates heavily and faults a second time when called from a handler, killing the process before anything is printed, since SIGSEGV is blocked inside its own handler. That was the first version of this patch, and it printed nothing at all. Attempting it only after the reliable frames are already on the wire makes that failure free. Expect the symbolized section to be empty in practice.

It re-raises with the default disposition, so the process still dies with the original signal and nextest still records a crash rather than a pass. That composes with #21909: the failed attempt's stderr — this backtrace — is captured into the JUnit <flakyFailure> that #21909 keeps as an artifact and that triggers its Slack alert, so a recurrence yields a durable, retrievable stack even though the retry keeps the job green.

Resolution is module + offset, not function names, because Rust doesn't export symbols to the dynamic table; resolve offline with addr2line, or add -rdynamic later if it proves necessary.

libc is already a workspace dependency; added here as a dev-dependency only.

🤖 Co-created with Claude Opus 4.8 (1M context)

[wiz-0f98cca50a]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	3  2  3
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	-
Software Management Findings	-
Total	3  2  3

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.

[einar-oplabs]

Preliminary Claude review.