gary
May 22, 2018, 2:16am
1
I want to see the backtrace of a random Segmentation fault issue, so I set RUST_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?
My first guess is stack overflow, which reliably SIGSEGV
s, 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?
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?
gary
May 22, 2018, 2:35am
4
Thanks. It has some external libraries, including a c lib, so, yes, it have unsafe code.
That’s where I’d look, particularly around the handoff points between Rust and C.
gary
May 22, 2018, 2:42am
6
Thanks scottmcm. I will try $ rust-lldb ./target/debug/grin-miner
gary
May 22, 2018, 2:56am
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.cuckooplugin
blake2b_update + 328
frame #2: 0x00000001025a3485 mean_cpu_30.cuckoopluginblake2b + 453 frame #3: 0x0000000102596f89 mean_cpu_30.cuckooplugin
cuckoo_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.dylib
thread_start + 13
(lldb)
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).
1 Like