Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9
On Tue, 20 Aug 2019 at 12:21:43 +0200, Matthias Klose wrote:
> Control: tags -1 + upstream moreinfo
>
> now https://gcc.gnu.org/PR91491
That bug report is a bit misleading: the glib2.0 build doesn't fail
(it succeeds and passes all its tests!), but it results in a GLib library
binary package that makes the clutter tests fail to terminate. clutter is
a library that depends on glib2.0.
As Iain previously noted, this is very, very far from a minimal reproducer,
but it's the only one we have.
> On 02.08.19 23:27, Simon McVittie wrote:
> > On Fri, 02 Aug 2019 at 19:49:20 +0100, Simon McVittie wrote:
> >> If you compile test_run_seed() with -O1, and the rest of gtestutils.c
> >> with -O2, the clutter test hangs.
>
> so building this all with -O2, and with the flags above, it both fails?
The "bad" behaviour is that glib2.0 builds successfully, and the glib2.0
tests all pass, but the clutter test does not terminate and eventually
fails with a timeout. The "good" behaviour is that everything succeeds.
With those definitions, the results were:
- Build glib2.0 with gcc-8 -O2: good
- Build glib2.0 with gcc-9 -O2: bad
- Build glib2.0 with gcc-9 -O1: good
- Build glib2.0 with gcc-9 -O2, except test_run_seed() with -O1 via
an __attribute__: good
- Build glib2.0 with gcc-9 -O2, except test_run_seed()
with __attribute__((optimize("no-tree-pre"))): good
This was a few gcc-9 revisions ago, so I'll have to check whether subsequent
gcc-9 changes have affected the result.
> can you tell where exactly the test case loops?
It isn't in a busy-loop or anything like that; it's in the GLib event
loop (a typical general-purpose event loop based on poll(), similar to
libevent/libuv/etc.), waiting for an event that is meant to terminate the
event loop by waking it up via an eventfd, but that event never happens.
I have no idea why changing the optimization level of test_run_seed()
would affect the behaviour of the event loop much later in the program's
execution, but it seems like it does.
> can you outline how you did setup your test case for that?
I can try to do that later. Sorry, it was quite an improvised setup,
initially involving hacking the generated ninja.build to use a different
compiler for different files, so I cannot easily summarize it in a couple
of lines.
Again, this is very far from a minimal reproducer but it's the best
we have.
> can you have a look at the search script in
> https://gcc.gnu.org/viewcvs/gcc/branches/gcc-9-branch/gcc/dbgcnt.def?view=markup
> and run 'gcc "-fdbg-cnt=treepre_insert:$lb:$ub"' in $cmd? so the whole $cmd
> should rebuild gtestutils, perform the link steps and run the test.
I'll try.
smcv
Reply to: