Segmentation fault but no backtrace when run with RUST_BACKTRACE=1


#1

I want to see the backtrace of a random Segmentation fault issue, so I setRUST_BACKTRACE=1 environment variable, normally it should have the backtrace info printed, but actually this time it doesn’t. Does anybody know the reason why the RUST_BACKTRACE doesn’t work?

$ RUST_BACKTRACE=1 ./target/debug/grin-miner
...
Segmentation fault: 11

Have tried multiple times and always got nothing backtraces. If the error is in the external libraries, RUST_BACKTRACE will do the job or not?


#2

My first guess is stack overflow, which reliably SIGSEGVs, but isn’t a panic so doesn’t hit that machinery. Maybe try running in a debugger and seeing what it says when you hit the fault?


#3

As @scottmcm mentioned, backtraces only come if a panic occurred - a segfault (modulo stack overflows in some cases) isn’t a Rust panic.

Do you have unsafe code in use?


#4

Thanks. It has some external libraries, including a c lib, so, yes, it have unsafe code.


#5

That’s where I’d look, particularly around the handoff points between Rust and C.


#6

Thanks scottmcm. I will try $ rust-lldb ./target/debug/grin-miner


#7

The lldb did the job:slightly_smiling_face:
$ rust-lldb ./target/debug/grin-miner
(lldb) r

Process 36024 stopped

  • thread #6, stop reason = EXC_BAD_ACCESS (code=1, address=0x70000c4f2ea0)
    frame #0: 0x00007fff5ed45f6d libsystem_platform.dylib_platform_memmove$VARIANT$Haswell + 77 libsystem_platform.dylib_platform_memmove$VARIANT$Haswell:
    -> 0x7fff5ed45f6d <+77>: vmovups -0x10(%rsi,%rdx), %xmm1
    0x7fff5ed45f73 <+83>: subq $0x20, %rdx
    0x7fff5ed45f77 <+87>: jbe 0x7fff5ed45fa3 ; <+131>
    0x7fff5ed45f79 <+89>: vmovups (%rsi), %ymm0
    Target 0: (grin-miner) stopped.

    (lldb) thread backtrace

    • thread #6, stop reason = EXC_BAD_ACCESS (code=1, address=0x70000c4f2ea0)
      • frame #0: 0x00007fff5ed45f6d libsystem_platform.dylib_platform_memmove$VARIANT$Haswell + 77 frame #1: 0x00000001025a07c8 mean_cpu_30.cuckoopluginblake2b_update + 328
        frame #2: 0x00000001025a3485 mean_cpu_30.cuckoopluginblake2b + 453 frame #3: 0x0000000102596f89 mean_cpu_30.cuckooplugincuckoo_call + 233
        frame #4: 0x0000000102596db1 mean_cpu_30.cuckoopluginprocess_internal_worker(void*) + 49 frame #5: 0x00007fff5ed4c661 libsystem_pthread.dylib_pthread_body + 340
        frame #6: 0x00007fff5ed4c50d libsystem_pthread.dylib_pthread_start + 377 frame #7: 0x00007fff5ed4bbf9 libsystem_pthread.dylibthread_start + 13
        (lldb)

#8

This is an utter stab in the dark but I’ve seen segfaults in memmove when an incorrect FFI type definition was used (ie Rust defines an incorrect ABI layout for a struct that C receives).