SIGBUS has to be sent twice before the rust runtime exits

[silence-coding]

Why Does the Rust Not Occur When the SIGBUS Is Killed Once?

[jyn514]

@silence-coding I'm not sure what you're trying to say. Could you post more info about the problem you're running into?

[silence-coding]

@jyn514 Thank you for your reply.
I tried to generate a coredump file, but have to execute twice kill SIGBUS pid to make the process core. My question is why the coredump file is not generated after the first kill is performed.

[jyn514]

It looks like the standard library installs a signal handler:

(gdb) run
Starting program: /home/joshua/.local/lib/cargo/target/debug/hello-world 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x00007ffff7e3e334 in __GI___clock_nanosleep (clock_id=<optimized out>, 
    clock_id@entry=0, flags=flags@entry=0, req=0x7fffffffdec0, rem=0x7fffffffdec0)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78	../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
(gdb) step
std::sys::unix::stack_overflow::imp::signal_handler ()
    at library/std/src/sys/unix/stack_overflow.rs:93
93	library/std/src/sys/unix/stack_overflow.rs: No such file or directory.

rust/library/std/src/sys/unix/stack_overflow.rs

Line 93 in 6df26f8

unsafe extern "C" fn signal_handler(

I think it needs to re-raise the same signal it receives after unregistering itself as the signal handler.

@alexcrichton you were the author of #27338 - does that sound about right to you?

[alexcrichton]

Well #27338 is 6+ years old so I only remember but so much. SIGBUS IIRC needs to be installed to catch some out-of-stack conditions at least at the time (it may no longer be the case). We assume SIGBUS signals are generated in-process so by unregistering the signal handler and returning the expectation is that the process will exit immediately.

[silence-coding]

Is there a follow-up plan for this issue?

[Amanieu]

For a normal SIGBUS there is no need to re-raise the signal since simply returning from the signal handler will cause the instruction that triggered the signal to execute again and re-trigger the signal.

This only happens because you are sending an "artificial" SIGBUS using kill, which is not caused by an instruction. I don't think this is something we need to support.

As a workaround you can use a different signal that generates a core dump like SIGABRT.