Bug#884659: glib2.0: sometimes FTBFS on reproducible-builds: gwakeup, gwakeup-fallback tests terminated by SIGALRM

[Simon McVittie]

(Re-sending to the correct bug, sorry for the noise. Please reply to
this copy, not the previous one.)

On Mon, 18 Dec 2017 at 09:17:46 +0000, Simon McVittie wrote:
> [#884654] is not new. It has also happened (more often for
> gwakeup-fallback) in earlier versions:
> https://tests.reproducible-builds.org/debian/rbuild/stretch/amd64/glib2.0_2.50.3-2.rbuild.log
> https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/glib2.0_2.54.1-1.rbuild.log
> https://tests.reproducible-builds.org/debian/logs/buster/armhf/glib2.0_2.54.1-1.build2.log.gz
> Presumably it doesn't happen on the real buildds because the reproducible
> build workers are more heavily-loaded, or have more or fewer CPUs, or
> some other factor. It isn't the build vs. build2 variation, because this
> test failure has been seen in both.

It looks as though the failing test is always /gwakeup/threaded or
/gwakeup/threaded-fallback (we see /gwakeup/semantics{,-fallback} pass
before the test fails, and threaded{,-fallback} is the only other test
in this executable).

That's a multi-threaded stress-test for GWakeup:

- set an alarm for 60 seconds, so that on failure we don't block forever
- create 50 threads
- create 5 "tokens", each with a TTL of 100K
- each token is owned by one thread at a time
- each thread is woken up when it owns at least one token, and at that
  point it will do:
  - for each token:
    - decrement the TTL
    - if the TTL is nonzero, choose a random thread and send the token
      to that thread
- when all tokens' TTLs are zero, wake up the main thread, which exits

It reliably passes on the buildds (even those for weaker architectures
like mips). Are the reproducible-builds machines perhaps doing other
things in parallel with running the glib2.0 test suite, such as building
another package?

The 60 second alarm is completely arbitrary (it was increased from
30 because some ARM systems took more than 30 seconds to finish). The
thread count, number of tokens and token TTL are probably also completely
arbitrary, and could be reduced, at the cost of being less likely to
detect bugs (unfortunately this sort of threading stress-test is usually
probabilistic).

    smcv