hang in gettext tests

Ken Moffat ken at linuxfromscratch.org
Fri Nov 14 16:13:50 PST 2008


On Wed, Nov 12, 2008 at 11:10:49AM +0000, Ken Moffat wrote:
>  In my build of 6.4-rc1, the box was hanging, apparently for more
> than 10 minutes, in the gettext tests.  Last thing in the log was
> make[3]: Entering directory
> `/building/gettext-0.17/gettext-runtime/tests'
> Starting test_lock ... OK
> Starting test_rwlock ...
> 
>  I killed it with ^C, then took a look around.  Deleted test_lock
> and test_lock.o in gettext-runtime and gettext-tools/gnulib-tests,
> reran make check, again it hung.
> 
>   I guessed that I might be able to turn the debugging on with
> CFLAGS=-DENABLE_DEBUGGING=1 (didn't seem to add debugging output)
> but the tests sailed through.  Deleted the test_lock files, repeated
> without attempting to enable debugging, again sailed through.
> 
>  Back to the script, put a tail -f on the log: halted on
> 
> test_rwlock, but showed an interruptmake[3]: Entering directory
> `/building/gettext-0.17/gettext-runtime/tests'
> Starting test_lock ... OK
> Starting test_rwlock ...make[3]: *** [check-TESTS] Interrupt
> make[2]: *** [check-am] Interrupt
> make[1]: *** [check-recursive] Interrupt
> make: *** [check-recursive] Interrupt
> 
>  and there it appeared to be stopped while I was writing up my
> notes, until I realised it had moved on to the next package.  The
> test log now shows
> Starting test_lock ... OK
> Starting test_rwlock ... OK
> Starting test_recursive_lock ... OK
> Starting test_once ... OK
> PASS: test-lock
> ==================
> All 1 tests passed
> ==================
> 
>  followed by the main tests (1 FAIL in format-c-5 FWIW).
> 
>  Strange.  Maybe it will never happen again.  Maybe it will always
> get through if left for a sufficiently long time.
> 
 I'm doing a fresh build, after discovering I'd only installed a few
locales.

 Left the build running in gettext, used another machine, came back
to it more than 4 hours later, it hadn't advanced.

 top showed
 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
5560 root      30  10 44356  580  416 S 99.7  0.1 268:16.62 test-lock

log showed

make[3]: Entering directory
`/building/gettext-0.17/gettext-runtime/tests'
Starting test_lock ... OK
Starting test_rwlock ...

 So, it _doesn't_ automatically get past any hang!

 Killed it.  Repeated.  The 'system activity window' on the taskbar
in icewm shows system is busy, but firing up 'top' shows that top is
the process using high % of cpu, which seems somewhat unlikely.
Test log ends

make[3]: Entering directory
`/building/gettext-0.17/gettext-runtime/tests'
Starting test_lock ... OK
Starting test_rwlock ...make[3]: *** [check-TESTS] Interrupt
make[2]: *** [check-am] Interrupt
make[1]: *** [check-recursive] Interrupt
make: *** [check-recursive] Interrupt

 A little later, the testlog has fresh results, so this one will get
through - indeed, it has and I'm now up to man-db.

 We haven't altered gettext in some time.  Maybe this only happens
on this machine, either with this compiler, or this kernel, or this
glibc.

 It would be reassuring to know who has run the full testsuites
without problems, and gone on to build their normal software without
any strange issues ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-dev mailing list