Re: Help diagnosing libtorrent build test failure on ppc64el

Jonathan McDowell <[email protected]> Sat, 3 Jan 2026 18:57:14 +0000
Newsgroups gmane.linux.debian.ports.powerpc
Message-ID <[email protected]>
On Sat, Jan 03, 2026 at 01:01:14PM +0100, John Paul Adrian Glaubitz wrote:
>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.

Thanks Simon + Adrian. I figured out how to access perotto, and this 
does seem like a flaky test/code; I couldn't reproduce the failure on 
0.15.7, or with latest git master.

J.