[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help diagnosing libtorrent build test failure on ppc64el



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


Reply to: