gnulib test-lock test can hang on some machines.

[ken@…]

Specifically, on my current AMD Kaveri - it uses 100% of all the cores, until killed (first time, it did that for several hours). The old version of the test has been problematic from time to time, and often was very slow on large machines.

This has been fixed upstream in gnulib ​https://github.com/coreutils/gnulib/commit/b20e8afb0b2cc9548fac073d71fcd19ede29ce60 and the iomportant part of that change is

#define EXPLICIT_YIELD 1
 
 /* Whether to use 'volatile' on some variables that communicate information
-   between threads.  If set to 0, a lock is used to protect these variables.
-   If set to 1, 'volatile' is used; this is theoretically equivalent but can
-   lead to much slower execution (e.g. 30x slower total run time on a 40-core
-   machine.  */
+   between threads.  If set to 0, a semaphore or a lock is used to protect
+   these variables.  If set to 1, 'volatile' is used; this is theoretically
+   equivalent but can lead to much slower execution (e.g. 30x slower total
+   run time on a 40-core machine), because 'volatile' does not imply any
+   synchronization/communication between different CPUs.  */
 #define USE_VOLATILE 0

i.e. it now mentions sempaphore or lock.

Affected files -

coreutils

gnulib-tests/test-lock.c

findutils

tests/test-lock.c

gettext

gettext-tools/gnulib-tests/test-lock.c

gettext-runtime/tests/test-lock.c

The latter has an offset of 111 lines

I am about to run a full test build using seds to stop this particular test being run. The purpose of the ticket is so that we can check newer versions of these packages to see if the sed is still required.

[ken@…]

Expanded details, fixed typo and reformatted. In my chroot build both versions of the test in gettext needed to be suppressed, my earlier tests on a completed system only needed to remove one of them. Perhaps there is also a race in the old code.

[bdubbs@…]

I think we can close this as fixed with the changes made today.