SIGUSR1 when `cargo run` of vault on RHEL9

[tcullum-rh]

Hi,

I have attempted to cargo run vault (current main branch) on RHEL9 using Rust 1.76.0 and I have the following signal occur:

(gdb) run run
Starting program: /home/researcher/.cargo/bin/cargo run
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
process 3129045 is executing new program: /home/researcher/.rustup/toolchains/1.76-x86_64-unknown-linux-gnu/bin/cargo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff7a7f640 (LWP 3129049)]
[New Thread 0x7ffff787e640 (LWP 3129050)]
[Thread 0x7ffff7a7f640 (LWP 3129049) exited]
[Thread 0x7ffff787e640 (LWP 3129050) exited]
[New Thread 0x7ffff787e640 (LWP 3129051)]
    Finished dev [unoptimized + debuginfo] target(s) in 0.72s

Thread 4 "cargo" received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7ffff787e640 (LWP 3129051)]
__GI___libc_read (nbytes=1, buf=0x7ffff787d8ff, fd=7) at ../sysdeps/unix/sysv/linux/read.c:26
26    return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) backtrace
#0  __GI___libc_read (nbytes=1, buf=0x7ffff787d8ff, fd=7) at ../sysdeps/unix/sysv/linux/read.c:26
#1  __GI___libc_read (fd=7, buf=0x7ffff787d8ff, nbytes=1) at ../sysdeps/unix/sysv/linux/read.c:24
#2  0x0000555556c9be83 in std::sys::unix::fd::FileDesc::read () at library/std/src/sys/unix/fd.rs:92
#3  std::sys::unix::fs::File::read () at library/std/src/sys/unix/fs.rs:1230
#4  0x0000555556b55f17 in <jobserver::imp::Client>::acquire_allow_interrupts ()
#5  0x0000555556b55183 in std::sys_common::backtrace::__rust_begin_short_backtrace::<jobserver::imp::spawn_helper::{closure#1}, ()> ()
#6  0x0000555556b55496 in <<std::thread::Builder>::spawn_unchecked_<jobserver::imp::spawn_helper::{closure#1}, ()>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} ()
#7  0x0000555556ca17a5 in alloc::boxed::{impl#47}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2015
#8  alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2015
#9  std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#10 0x00007ffff7d45802 in start_thread (arg=<optimized out>) at pthread_create.c:443
#11 0x00007ffff7ce5450 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Note: The source of the bug is probably not vault itself, but wanted to document it here in case anyone else experiences it.

[dominikwilkowski]

Thanks for logging this @tcullum-rh If you have the time can you try to run any of the floem examples on RHEL9? Maybe the counter example which is the most basic one. Just trying to pin down where this issue comes from.

[tcullum-rh]

Thanks for logging this @tcullum-rh If you have the time can you try to run any of the floem examples on RHEL9? Maybe the counter example which is the most basic one. Just trying to pin down where this issue comes from.

I'd love to, but unfortunately that machine is completely borked right now due to 2 power outages that occurred here last night! I'm working on getting it back up, but so far been at it 1.5 hrs to no avail! Obviously in the worst case I'll set up a fresh machine, but I really wanted to leave it as-is for the sake of debugging this issue and other unrelated reasons.

[dominikwilkowski]

oh wow. No stress on our end :D

[tcullum-rh]

Well I finally fixed the RHEL box, and now it won't reproduce... Maybe it was a one-off... Anyway, I'm looking forward to testing more. I am going to keep testing this for a bit longer and if it still won't reproduce, I'll return and close this issue. I had to make a few system changes to get the box to boot again, which may have "solved" the issue unfortunately/fortunately lol.

[tcullum-rh]

Closing this as it is no longer reproducible.