GNU bug report logs - #6281
Fwd: Possible bug in coreutils-8.5 or associated gnulib version

Previous Next

Full log

Message #26 received at 6281 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org
Cc: chris2553 <at> googlemail.com, Jim Meyering <jim <at> meyering.net>,
	6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Sat, 29 May 2010 00:24:17 +0200

Hi,

> >> Chris Clayton wrote:
> >> > but make check hangs when
> >> > gnulib-tests/test-lock is run. The log showed that the hang occurred
> >> > somewhere after the
> >> > message "Starting test_rwlock" was output
> ...
> > The only thing I can think of is that glibc is a bit old at 2.7,
> 
> Using glibc-2.7 with a new kernel is unusual indeed.

But the kernel people try hard not to break backward compatibility, and
while glibc-2.7 is not as bleeding edge as linux 2.6.34, it is less than
3 years old.

You can easily reduce the size of test-lock.c so that only one of the four
tests is run. The next step will be to manually expand the macros from
gnulib's <lock.h>, so that you get 100% POSIX compliant source code.
With that, you could go to the glibc people and ask for help.

But given that glibc-2.7 is old, you would need someone else to reproduce
it also with a newer glibc. And personally I would guess it's a breakage
in the new linux 2.6.34. But in order to isolate a bug in the multithread
system calls, you need help of a some super hacker like Ulrich Drepper or
Ingo Molnar.

So, can you trim down the testcase to something that fails with glibc-2.11
and submit that through the glibc bugzilla?

Bruno

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.