Bug#932678: glib2.0: tests timeout on i386 and mips
On Sun, 28 Jul 2019 at 00:04:01 +0200, Aurelien Jarno wrote:
> The UTM8 based buildds like mips-sil-01 are much faster than the
> mips-aql-0{1,2,4,5} buildds, and also have an FPU, although I am not
> sure it plays a role here.
The test that timed out uses g_random_double_range() in a fairly tight
loop, and that function casts random integers to doubles, so if mips-aql-*
is emulating floating point in software I'm not necessarily surprised
it's so slow.
> After giving back this package, it built successfully on mips-manda-01.
> I have therefore blacklisted glib2.0 from the slowest buildds.
In 2.60.6 I've also disabled that test on mips.
smcv
Bug#932678: glib2.0: tests timeout on i386 and mips
On 2019-07-26 23:39, Simon McVittie wrote:
> > On mips, the gvariant test timed out.
>
> This is failing a fuzz-test that randomly modifies binary data and
> tries to parse it. I thought it might be reaching some pathological
> case where the parser breaks, but no - it looks like the actual problem
> is that g_random_double_range() is really slow on at least some mips
> hardware (repeatedly calling g_random_double_range() in a loop is 100
> times as fast on my laptop as on the porterbox minkus, which according
> to db.debian.org is the same EdgeRouter Pro hardware as mips-aql-01,
> the buildd where this test timed out).
>
> mips porters: Is this something that is expected to be so slow? The
> same test took 60 seconds (so at least 6 times as fast) on mips-sil-01,
> which is apparently a Rhino Labs UTM8 with a somewhat newer CPU.
> For comparison, it took 8 seconds on the i386 buildd.
The UTM8 based buildds like mips-sil-01 are much faster than the
mips-aql-0{1,2,4,5} buildds, and also have an FPU, although I am not
sure it plays a role here.
After giving back this package, it built successfully on mips-manda-01.
I have therefore blacklisted glib2.0 from the slowest buildds.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#932678: glib2.0: tests timeout on i386 and mips
On Fri, 26 Jul 2019 at 23:39:54 +0100, Simon McVittie wrote: > On Sun, 21 Jul 2019 at 15:49:38 -0400, Michael Gilbert wrote: > > On i386, the gmenumodel test timed out. > > The failing test-case seems to be /gmenu/dbus/peer/subscriptions, which > has a watchdog timer that is meant to kill the process with SIGALRM > after 65 seconds, so I'm surprised it survived to 360s - either the > watchdog timer isn't working, or multiple test-cases must have taken a > lot longer than they are meant to. There is some test setup that is not covered by the watchdog timer, which has thread data races that have been fixed in upstream git master. If this was the root cause then I'm not surprised I couldn't reproduce the problem. I've backported that patch in the hope that it will fix this test, but since it's unreproducible it's hard to be sure, so I'll also skip this test at build-time. We can revisit that change when GNOME 3.32 (or 3.34?) has landed in unstable. smcv
Bug#932678: glib2.0: tests timeout on i386 and mips
On Sun, 21 Jul 2019 at 15:49:38 -0400, Michael Gilbert wrote: > On i386, the gmenumodel test timed out. I can't reproduce this locally, and it normally takes about 6-7 seconds on an i386 VM on my laptop. It has had issues with arbitrary delays in the past, and got moved to the "slow" test suite because it was sometimes taking more than 60s in upstream's CI, so I'm quite prepared to believe that there is some intermittent problem. The failing test-case seems to be /gmenu/dbus/peer/subscriptions, which has a watchdog timer that is meant to kill the process with SIGALRM after 65 seconds, so I'm surprised it survived to 360s - either the watchdog timer isn't working, or multiple test-cases must have taken a lot longer than they are meant to. If I can't reproduce this well enough to debug it, the best I'll be able to do is to disable this particular test at build-time. > On mips, the gvariant test timed out. This is failing a fuzz-test that randomly modifies binary data and tries to parse it. I thought it might be reaching some pathological case where the parser breaks, but no - it looks like the actual problem is that g_random_double_range() is really slow on at least some mips hardware (repeatedly calling g_random_double_range() in a loop is 100 times as fast on my laptop as on the porterbox minkus, which according to db.debian.org is the same EdgeRouter Pro hardware as mips-aql-01, the buildd where this test timed out). mips porters: Is this something that is expected to be so slow? The same test took 60 seconds (so at least 6 times as fast) on mips-sil-01, which is apparently a Rhino Labs UTM8 with a somewhat newer CPU. For comparison, it took 8 seconds on the i386 buildd. There probably isn't much point in trying very hard to run this test on mips, so I'll disable this one as a build-time test too. smcv
Bug#932678: glib2.0: tests timeout on i386 and mips
package: src:glib2.0 severity: serious version: 2.60.5-1 The latest glib2.0 upload fails to build on i386 and mips [0]. On i386, the gmenumodel test timed out. On mips, the gvariant test timed out. Best wishes, Mike [0] https://buildd.debian.org/status/package.php?p=glib2.0
