search

Amanieu / parking_lot

Compact and efficient synchronization primitives for Rust. Also provides an API for creating custom synchronization primitives.
Apache License 2.0
2.7k stars 213 forks source link

SIGSEGV when it tries to wait for a futex #451

Open techmetx11 opened 3 weeks ago

techmetx11 commented 3 weeks ago

The code segfaults when it tries to wait for a futex (related to Tokio) More info: https://github.com/iv-org/inv_sig_helper/issues/12 A coredump of the crash and build is provided at https://github.com/iv-org/inv_sig_helper/issues/12#issuecomment-2289084639 From the coredump, the program is shown crashing at these first few locations in the code:

  1. unknown function (0x00007fc5ed1a3719)
  2. https://github.com/Amanieu/parking_lot/blob/master/core/src/thread_parker/linux.rs#L112
  3. https://github.com/Amanieu/parking_lot/blob/master/core/src/thread_parker/linux.rs#L66
  4. https://github.com/Amanieu/parking_lot/blob/master/core/src/parking_lot.rs#L635
  5. https://github.com/Amanieu/parking_lot/blob/master/core/src/parking_lot.rs#L600
Amanieu commented 3 weeks ago

Are you sure it's actually crashing in that thread? It seems like this is just the main thread which is blocked waiting on a lock while the crash is happening in another thread.

techmetx11 commented 3 weeks ago

All the other threads are also blocked waiting for a lock (in the coredump)

Amanieu commented 3 weeks ago

All of the threads in that core dump are in system calls, which shouldn't be able to cause a SIGSEGV. It seems the core dump was not taken at the moment the crash happened.

techmetx11 commented 3 weeks ago

All of the threads in that core dump are in system calls, which shouldn't be able to cause a SIGSEGV. It seems the core dump was not taken at the moment the crash happened.

That's weird, because the kernel makes a core dump after the program crashed (or at least, it should be)

Also, it seems like it crashes due to a malloc header corruption at times, as seen in the linked issue