Re: Perl package failing to migrate to testing

Jeff <[email protected]> Mon, 5 Aug 2024 12:22:31 +0000
Newsgroups	gmane.linux.debian.devel.perl
Message-ID	<[email protected]>
On 04/08/2024 19:10, Russ Allbery wrote:
> The concrete answer to your question is that Debian has porterboxes
> available for various architectures including this one.  DDs should
> already have access; Debian maintainers who are not DDs can request guest
> access.  See https://wiki.debian.org/PorterBoxHowToUse.

Thanks for the link. That got me to a very nice script from Enrico Zini:

https://salsa.debian.org/enrico/debug-on-porterbox

> For the problem itself, this looks suspiciously like a race condition to
> me, although I'm not sure why it would fail only on riscv64.  The test
> code that's failing is the following in 1111_save_pdf.t:

You are absolutely correct that started_callback() is running twice. The 
threading mechanism should prevent that, which is the bug. The 
interesting question is why it only occurs on riscv64.

> I have absolutely zero experience with the Perl Glib integration, but just
> eyeballing this code, it looks like the finished_callback is supposed to
> set $flag to false so that $loop->run doesn't run (a second time? there
> seems to be some threading or other implicit parallelization going on
> here).

The threading isn't done with GLib - it uses the Perl internal threading 
mechanism.

> So my hypothesis, which is a straight-up guess that may be wrong since I
> don't know how these libraries work, is that for some reason on this
> platform this code gets run twice, presumably because the
> finished_callback hasn't run before it reaches the $loop->run line, and
> that's also causing some sort of race that causes the total counter to be
> 1 instead of 2.

Having just fired up the porterbox I see that the bug does occur 
reproducibly there, either. i.e. as you suggest, there is a race 
condition somewhere.

> If it is a race condition, this may be a general problem with the test
> that could trigger elsewhere, but just happened to trigger on this
> architecture for some reason.  But it's also quite possible that glib
> works subtly differently on this platform for some reason.

Yup. Thanks for your time and pointing me in the right direction.

Regards

Jeff
OpenPGP_signature.asc (application/pgp-signature, 840 B)