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.