Hi, On Fri, 17 Nov 2017 18:37:42 +0100 Emilio Pozuelo Monfort <po...@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 > >
