Segfault from from 100% safe code

[dstu]

I have 100% safe code that segfaults, presumably due to stack exhaustion.

Exhausting stack space in a simple Rust program triggers telltale error messages (thread 'foo' has overflowed its stack, fatal runtime error: stack overflow) and death via SIGABRT. In the behavior I have encountered, these messages are not printed, and the process is killed with SIGSEGV.

It is my understanding that a crate consisting of 100% safe Rust (even if it has bugs) should not segfault like this. I would expect an explicit stack exhaustion error and death by SIGABRT. When examining this in gdb, I see a large number of stack frames (over 40,000) due to the erroneous fmt::Display implementation. In the bottom frame, there is a clear null pointer dereference (call to a method where &self has address 0).

Example code can be found at https://git.sdf.org/vitrine/shatterc/src/branch/reproduce-segfault. You can reproduce this with these steps:

1. Clone https://git.sdf.org/vitrine/shatterc.git
2. Switch to the reproduce-segfault branch
3. Execute cargo run -- example-cycle.c

Two thoughts about where to look next:

• The second stack frame from the bottom appears to be here: https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/rt.rs#L178. As noted in a FIXME comment in the formatter code, there is a CFI violation in how formatter is invoked. Perhaps this is related to CFI: core and std have explict CFI violations #115199.
• Perhaps that unsafe block is a red herring, and this is really just a case of things behaving poorly when stack space is exhausted. (Cf. discussion at https://sunshowers.io/posts/rustc-segfault-illumos/.) If this is the case, is there a bug in how stack exhaustion is being handled?

[zachs18]

Line 35 of main.rs calls clang::Index::new, which calls clang_sys::clang_createIndex, which is this, which calls this, which (unless the LIBCLANG_DISABLE_CRASH_RECOVERY env var is set), calls llvm::CrashRecoveryContext::Enable(), which calls installExceptionOrSignalHandlers(), which sets a SIGSEGV handler (and some other signals), overriding Rust's SIGSEGV handler.

If I set LIBCLANG_DISABLE_CRASH_RECOVERY=yes, then I do see the thread 'main' has overflowed its stack fatal runtime error: stack overflow message printed from Rust's SIGSEGV handler.

[saethlin]

So this isn't 100% safe code. I think it's fair to call this expected, though you can argue with clang/LLVM about whether this behavior is good.

[dstu]

Thanks for taking a look, and good catch.