The mips build of swi-prolog failed:

Running scripts from core .......................................
E: Build killed with signal TERM after 360 minutes of inactivity

The bug can be reproduced on mips porterbox. Hitting Ctrl+X gives:

Interrupted test cgc:shift_cgc at /home/dogsleg/swi-prolog-7.6.1+dfsg/src/Tests/core/test_cgc.pl:102

The most strange thing is that 7.6.1-1 built successfully on mips. The
only difference between 7.6.1-1 and 7.6.1-2 is that java tests (only
tests) are disabled now (via debian/rules). Note that the 7.6.1-2
version builds successfully on mipsel and mips64el (little-endian), but
fails on mips (big-endian).

The similar problem occures on powerpc [1][2], which also works in
big-endian mode:

Running scripts from core ........................................Makefile:418: recipe for target 'check' failed
make[2]: *** [check] Terminated

[1] https://buildd.debian.org/status/fetch.php?pkg=swi-prolog&arch=powerpc&ver=7.6.1%2Bdfsg-2&stamp=1510047696&raw=0

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869701

7.3.33+dfsg-1 failed the same way a year ago:
https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=mips

I would not rule out that this might be an old bug causing random build
failures, that either just happened twice in the row or became more
likely due to some change somewhere.
https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpc
https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpcspe

cu
Adrian

Hi Adrian,

Ср 15 ноя 2017 @ 08:06 Adrian Bunk <bunk@debian.org>:

In the past there were some wierd build problems from time to time. You
can find logs and build history in usual place. These build problems
were unreproducible and were typically resolved with rebuilding. Not
that time.

True. And as I can see powerpcspe also works in big-endian mode.

I've informed upstream about the issue. Their answer is as follows:

Upstream will try to run these stress tests on powerpc and mips again,
but they claim that they were not able to reproduce some issues with
these tests in 7.6.1. Guess the issue may be related to Debian build
environment. At least, I cannot think of any other reason that 7.6.1-1
was built successfully on mips and 7.6.1-2 failed, where the only one
change is disabling Java tests (due to CVE-2017-1000364). I've uploaded
7.6.1-2 on the next day after 7.6.1-1 upload.

Cheers!
Lev

Hi Lev,

you already quoted the reason:

Based on the mips/powerpc/powerpcspe results one could say that there
is a 50% chance that a build attempt fails.

That would give a 37.5% probability for 2 builds failing and one
succeeding when trying 3 times.

Considering the older mips failure and the more frequent
powerpc/powerpcspe failures, the 7.6.1-1 success might
just have been "luck".

cu
Adrian

Hi,

I had a look at this and indeed the build fails on mips randomly usually
hanging in the test_cgc test (as mentioned earlier).

One thread always hangs in the global_generation function which is only
enabled if ATOMIC_GENERATION_HACK is enabled (only on arches without
64-bit atomics).

Excerpt from pl-inline.h:465

In the above loop, GD->_generation and GD->_last_generation are not
modified within the loop, nor are they declared volatile. Therefore the
"last" and "g" assignments are invariant and GCC will hoist them out of
the loop (into something like what is shown below). This causes the
hangs on mips if g < last for some reason.

last = GD->_last_generation;
g = (gen_t)GD->_generation.gen_u<<32 | GD->_generation.gen_l;
do {} while (g < last);

As a side note, I also notice GD->_generation is loaded without any
memory barriers on all architectures (pl-incl.h:999) which looks a bit
dodgy (although I don't know if it actually breaks anything).

IMO the best solution is to remove all the ATOMIC_GENERATION_HACK code
and use libatomic, but this will take some porting work because
swi-prolog uses the old __sync primitives everywhere.

I have attached a hack which marks _generation and _last_generation as
volatile. This seems to work but isn't a long term solution.

James

Hi James,

Пт 17 ноя 2017 @ 17:15 James Cowgill <jcowgill@debian.org>:

Thanks for your input! I've informed upstream about the issue you found
and your suggestions.

Regards,
Lev