Bug#880883: FTBFS on arm64: test suite times out (on arm-arm-04)

Punit Agrawal punitagrawal at gmail.com
Wed Nov 22 11:49:46 UTC 2017


Hi,

On Fri, 17 Nov 2017 18:37:42 +0100 Emilio Pozuelo Monfort
<pochu at debian.org> wrote:
> On 12/11/17 15:02, Michael Biebl wrote:
> > Am 05.11.2017 um 13:14 schrieb Michael Biebl:

[...]

> I gave it back again, and it again got picked by arm-arm-04. With the help from
> jcristau (as I don't have access to that machine) I determined that the build
> gets killed while running the closures test, which gets executed by is way too
> slow on that machine (it'd take around 200 minutes to complete it).

I'm not sure what the specs on arm-arm-04 are, but I tried building
the package on an ARM system I have access to and the "closure" test
hadn't completed after 2h15m (at which point I interrupted the build)

>
> I'm not sure where it's taking so much time on this machine (can't know without
> access or some debugging logs) but I wonder if it's on g_closure_ref/unref,
> which happen quite a lot. Maybe atomic operations are too slow on this hardware?

>From my understanding the "closure" tests runs three threads -
thread1, thread2 and the main thread each respectively printing "c",
"C" and ".\n" periodically.

Manually running the tests I see a lot of "c" and "C" in the test
output but very few ".\n" suggesting that signal emissions is really
slow on this box. In contrast, running the test on an x86 VM I saw a
lot more ".\n" in the output.

Not knowing much about signal emissions and glib, I have a feeling
that the extremely slow progress in the main thread points to a
problem - it's unclear whether it's in the library or elsewhere (maybe
atomics as you surmise above).

Not sure how best to help get to the bottom of this. I am happy to try
out patches if it helps narrow down the problem area.

Thanks,
Punit

>
> Cheers,
> Emilio
>
>



More information about the pkg-gnome-maintainers mailing list