Hi, On 1/3/26 03:48, Jonathan McDowell wrote:
Looking at the tests it's the torrent/ utils::TestSignalInterrupt::test_thread_interrupt test that's failing, which appears to be trying to do signal delivery to a C++ thread and confirm it behaves as expected.
Looking into the SignalInterrupt class, that one seems to use a socket pair, not even a signal, and optimizes to send fewer notifications by noting down in an atomic boolean when it has already sent one.
After a quick glance at the code, I'm not convinced this is actually safe, because that variable is reset to false with an unconditional write at the end of processing when it should be reset at the beginning of processing in order to not lose events, i.e. we would need to reach this line
https://salsa.debian.org/debian/libtorrent/-/blob/master/src/utils/signal_interrupt.cc?ref_type=heads#L90before we even take a look at whatever other channel we're sending data through, such as shared memory with a mutex, otherwise a notification can be eaten here.
That alone is fishy. I'm not sure this is the culprit, though, just the first thing I found, without testing anything on actual hardware.
Simon
Attachment:
OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature