Hi, On Sat, 2026-01-03 at 19:44 +0900, Simon Richter wrote: > 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#L90 > > before 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.
And I think the moment either of the exceptions are thrown, the variable isn't ever updated either. Although I don't fully understand what m_poking is for. Either way, this seems to be another case where building a package on a non-x86 architecture seems to reveal real-world bugs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
