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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6281 in the body.
You can then email your comments to 6281 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Chris Clayton <chris2553 <at> googlemail.com>
To: bug-coreutils <at> gnu.org
Subject: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Date: Thu, 27 May 2010 15:40:09 +0100

Resend because the first try somehow ended up at the Debbugs-submit
mailing list!

Fingers crossed.


---------- Forwarded message ----------
From: Chris Clayton <chris2553 <at> googlemail.com>
Date: 27 May 2010 09:19
Subject: Possible bug in coreutils-8.5 or associated gnulib version
To: bug-coreutils <at> gnu.org


Hi,

I've just tried to build coreutils-8.5. The compilation finished OK,
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, so I've added some
additional debugging output to the
test_rwlock function so that it now looks like:

static void
test_rwlock (void)
{
 int i;
 gl_thread_t checkerthreads[THREAD_COUNT];
 gl_thread_t threads[THREAD_COUNT];

 /* Initialization.  */
 for (i = 0; i < ACCOUNT_COUNT; i++)
   account[i] = 1000;
 rwlock_checker_done = 0;

 /* Spawn the threads.  */
 printf ("\nCreating %d rwlock_checker_threads:", THREAD_COUNT);
 for (i = 0; i < THREAD_COUNT; i++)
   checkerthreads[i] = gl_thread_create (rwlock_checker_thread, NULL);
 printf ("OK\n");
 printf ("Creating %d rwlock_mutator_threads:", THREAD_COUNT);
 for (i = 0; i < THREAD_COUNT; i++)
   threads[i] = gl_thread_create (rwlock_mutator_thread, NULL);
 printf ("OK\n");

 /* Wait for the threads to terminate.  */
 printf ("Waiting for rwlock_mutator_threads to terminate:\n");
 for (i = 0; i < THREAD_COUNT; i++) {
   printf ("\t%d\n", i);
   gl_thread_join (threads[i], NULL);
 }
 rwlock_checker_done = 1;
 printf ("Waiting for rwlock_checker_threads to terminate:\n");
 for (i = 0; i < THREAD_COUNT; i++) {
   printf ("\t%d\n", i);
   gl_thread_join (checkerthreads[i], NULL);
 }
 check_accounts ();
}

I compiled the amended test app and ran it a few times. The output I
got is as follows:

[root:/home/chris/rpm/build/coreutils-8.5/gnulib-tests]$ ./test-lock
Starting test_lock ... OK
Starting test_rwlock ...
Creating 10 rwlock_checker_threads:OK
Creating 10 rwlock_mutator_threads:OK
Waiting for rwlock_mutator_threads to terminate:
       0
       1
^C
[root:/home/chris/rpm/build/coreutils-8.5/gnulib-tests]$ ./test-lock
Starting test_lock ... OK
Starting test_rwlock ...
Creating 10 rwlock_checker_threads:OK
Creating 10 rwlock_mutator_threads:OK
Waiting for rwlock_mutator_threads to terminate:
       0
       1
^C
[root:/home/chris/rpm/build/coreutils-8.5/gnulib-tests]$ time ./test-lock
Starting test_lock ... OK
Starting test_rwlock ...
Creating 10 rwlock_checker_threads:OK
Creating 10 rwlock_mutator_threads:OK
Waiting for rwlock_mutator_threads to terminate:
       0
       1
^C

real    23m14.207s
user    0m3.039s
sys     0m4.329s

The final run shows that even if I leave the app to run for several
minutes, it still fails to
complete.

I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525
(prerelease) (this week's 4.4
snapshot), although I get the same hang if I build and test with gcc-3.4.6.

I'm not subscribed, so please cc me into any reply  More than happy to
provide any other information
you need to solve this.

Thanks,

Chris Clayton

--
The more I see, the more I know. The more I know, the less I
understand. Changing Man - Paul Weller



-- 
The more I see, the more I know. The more I know, the less I
understand. Changing Man - Paul Weller

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

From: Jim Meyering <jim <at> meyering.net>
To: Chris Clayton <chris2553 <at> googlemail.com>
Cc: 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Thu, 27 May 2010 19:12:11 +0200

Chris Clayton wrote:
> I've just tried to build coreutils-8.5. The compilation finished OK,
> 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, so I've added some
> additional debugging output to the
> test_rwlock function so that it now looks like:
...
> The final run shows that even if I leave the app to run for several
> minutes, it still fails to
> complete.
>
> I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525
> (prerelease) (this week's 4.4
> snapshot), although I get the same hang if I build and test with gcc-3.4.6.
>
> I'm not subscribed, so please cc me into any reply  More than happy to
> provide any other information
> you need to solve this.

Thanks for the report.

I cannot reproduce a problem with 2.6.34 and gcc-4.4.4.
Is there anything else about your environment that might be unusual?

Can you reproduce that using the latest from git?
If you're up to it, here's the build-from-git procedure:

    http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking

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

From: Chris Clayton <chris2553 <at> googlemail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Thu, 27 May 2010 23:31:41 +0100

On Thursday 27 May 2010, Jim Meyering wrote:
> Chris Clayton wrote:
> > I've just tried to build coreutils-8.5. The compilation finished OK,
> > 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, so I've added some
> > additional debugging output to the
> > test_rwlock function so that it now looks like:
>
> ...
>
> > The final run shows that even if I leave the app to run for several
> > minutes, it still fails to
> > complete.
> >
> > I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525
> > (prerelease) (this week's 4.4
> > snapshot), although I get the same hang if I build and test with
> > gcc-3.4.6.
> >
> > I'm not subscribed, so please cc me into any reply  More than happy to
> > provide any other information
> > you need to solve this.
>
> Thanks for the report.
>

Thanks for the reply.

> I cannot reproduce a problem with 2.6.34 and gcc-4.4.4.
> Is there anything else about your environment that might be unusual?
>

The only thing I can think of is that glibc is a bit old at 2.7, but if I update to a later version, 
some of my apps stop working [e.g. midnight commander (mc)] and no matter how much recompiling I 
do, I can't get them to work again. The system started out (5 or 6 years ago) as Peanut Linux, 
which was a Slackware derivative amended to use rpm for package management. Nowadays, however, 
many, many packages have been added (KDE,OpenOffice, udev, cherokee - I could go on and on here) 
and upgraded. But it's finely tuned to the things I do with my computer. I tend to update packages 
as new versions become available, other than where I bump into dependency clashes or massive 
rebuild of packages.

> Can you reproduce that using the latest from git?
> If you're up to it, here's the build-from-git procedure:
>
>     http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking

Had to build and install a few dependencies, but I've done the build-from-git thing and I get the 
same hang. 

The call to configure during the build is as follows:

./configure --prefix=/usr --disable-nls --mandir=/usr/man --infodir=/usr/info --disable-acl --disable-rpath --disable-xattr

Interestingly, I've just run test-lock under gdb a few times and it always ran successfully. I'm not 
really that well qualified to have a stab like this, but that fact does make me wonder whether we 
have a race/timing problem here. I'll do a bit more hacking on the test-lock program and see if I 
can get any more diagnostics.

Thanks for your help so far.

Chris

-- 
The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller

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

From: Jim Meyering <jim <at> meyering.net>
To: chris2553 <at> googlemail.com
Cc: bug-gnulib <at> gnu.org, 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Fri, 28 May 2010 07:47:25 +0200

Chris Clayton wrote:
> On Thursday 27 May 2010, Jim Meyering wrote:
>> Chris Clayton wrote:
>> > I've just tried to build coreutils-8.5. The compilation finished OK,
>> > 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, so I've added some
>> > additional debugging output to the
>> > test_rwlock function so that it now looks like:
>>
>> ...
>>
>> > The final run shows that even if I leave the app to run for several
>> > minutes, it still fails to
>> > complete.
>> >
>> > I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525
>> > (prerelease) (this week's 4.4
>> > snapshot), although I get the same hang if I build and test with
>> > gcc-3.4.6.
>> >
>> > I'm not subscribed, so please cc me into any reply  More than happy to
>> > provide any other information
>> > you need to solve this.
>>
>> Thanks for the report.
>>
>
> Thanks for the reply.
>
>> I cannot reproduce a problem with 2.6.34 and gcc-4.4.4.
>> Is there anything else about your environment that might be unusual?
>>
>
> 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.
Definitely suspect.  I've Cc'd bug-gnulib, since it's clearly involved.

> but if I update to a later version,
> some of my apps stop working [e.g. midnight commander (mc)] and no matter how much recompiling I
> do, I can't get them to work again. The system started out (5 or 6 years ago) as Peanut Linux,
> which was a Slackware derivative amended to use rpm for package management. Nowadays, however,
> many, many packages have been added (KDE,OpenOffice, udev, cherokee - I could go on and on here)
> and upgraded. But it's finely tuned to the things I do with my computer. I tend to update packages
> as new versions become available, other than where I bump into dependency clashes or massive
> rebuild of packages.
>
>> Can you reproduce that using the latest from git?
>> If you're up to it, here's the build-from-git procedure:
>>
>>     http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking
>
> Had to build and install a few dependencies, but I've done the build-from-git thing and I get the
> same hang.
>
> The call to configure during the build is as follows:
>
> ./configure --prefix=/usr --disable-nls --mandir=/usr/man --infodir=/usr/info --disable-acl --disable-rpath --disable-xattr
>
> Interestingly, I've just run test-lock under gdb a few times and it always ran successfully. I'm not
> really that well qualified to have a stab like this, but that fact does make me wonder whether we
> have a race/timing problem here. I'll do a bit more hacking on the test-lock program and see if I
> can get any more diagnostics.
>
> Thanks for your help so far.
>
> Chris

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

From: Chris Clayton <chris2553 <at> googlemail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Fri, 28 May 2010 08:28:06 +0100

Hi Jim,

I've done some more testing and the outcome is reported below.

On Thursday 27 May 2010, Chris Clayton wrote:
> On Thursday 27 May 2010, Jim Meyering wrote:
> > Chris Clayton wrote:
> > > I've just tried to build coreutils-8.5. The compilation finished OK,
> > > 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, so I've added some
> > > additional debugging output to the
> > > test_rwlock function so that it now looks like:
> >
> > ...
> >
> > > The final run shows that even if I leave the app to run for several
> > > minutes, it still fails to
> > > complete.
> > >
> > > I am running kernel 2.6.34 and my gcc is gcc (GCC) 4.4.5 20100525
> > > (prerelease) (this week's 4.4
> > > snapshot), although I get the same hang if I build and test with
> > > gcc-3.4.6.
> > >
> > > I'm not subscribed, so please cc me into any reply  More than happy to
> > > provide any other information
> > > you need to solve this.
> >
> > Thanks for the report.
>
> Thanks for the reply.
>
> > I cannot reproduce a problem with 2.6.34 and gcc-4.4.4.
> > Is there anything else about your environment that might be unusual?
>
> The only thing I can think of is that glibc is a bit old at 2.7, but if I
> update to a later version, some of my apps stop working [e.g. midnight
> commander (mc)] and no matter how much recompiling I do, I can't get them
> to work again. The system started out (5 or 6 years ago) as Peanut Linux,
> which was a Slackware derivative amended to use rpm for package management.
> Nowadays, however, many, many packages have been added (KDE,OpenOffice,
> udev, cherokee - I could go on and on here) and upgraded. But it's finely
> tuned to the things I do with my computer. I tend to update packages as new
> versions become available, other than where I bump into dependency clashes
> or massive rebuild of packages.
>
> > Can you reproduce that using the latest from git?
> > If you're up to it, here's the build-from-git procedure:
> >
> >     http://git.sv.gnu.org/cgit/coreutils.git/tree/README-hacking
>
> Had to build and install a few dependencies, but I've done the
> build-from-git thing and I get the same hang.
>
> The call to configure during the build is as follows:
>
> ./configure --prefix=/usr --disable-nls --mandir=/usr/man
> --infodir=/usr/info --disable-acl --disable-rpath --disable-xattr
>

If I add --enable-threads=pth to the call to configure, test-lock runs successfuly ever time. If I 
make it --enable-threads=posix (or let it default to posix), test-lock will very occasionally 
succeed, but more often than not hangs as per my report above. If I define ENABLE_DEBUGGING as 1 in 
test-lock.c, test-lock succeeds regardless of the threading library that's used.

I guess this all points to something like a thread sync problem in libpthread at glibc-2.7. However, 
it appears that the --enable-threads=blah setting only affects the test applications. Whatever I 
set it to, the coreutils binary rpm I produce only ever requires libpthread and only test-tls and 
test-lock switch between requiring libpthread and libpth depending on the setting. In that case I'm 
happy to build the package to use libpth. In any case,  test-lock et al seem to me to be testing 
gnulib rather than coreutils, although happy to be corrected on that.

On the other hand, rpm reports that 492 packages installed on my system require libpthread.so.0. 
Frequency of use of applications and libraries from those packages may vary from every day (X.org, 
kdelibs et al) to very rarely (efax-gtk), but none of them hang in the way that this test 
application does.

If you want to try and track this down, I'm more than happy to help, but equally, I'm cool about it 
if you have better things to do with your time. One day I'm going to have to bite the bullet and 
upgrade to a more modern distro :-)

Thanks again,

Chris

> Interestingly, I've just run test-lock under gdb a few times and it always
> ran successfully. I'm not really that well qualified to have a stab like
> this, but that fact does make me wonder whether we have a race/timing
> problem here. I'll do a bit more hacking on the test-lock program and see
> if I can get any more diagnostics.
>
> Thanks for your help so far.
>
> Chris

-- 
The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller

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

From: Jim Meyering <jim <at> meyering.net>
To: chris2553 <at> googlemail.com
Cc: 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Fri, 28 May 2010 09:45:39 +0200

Chris Clayton wrote:
> Hi Jim,
>
> I've done some more testing and the outcome is reported below.
...

[I've reformatted this paragraph for you -- wrapping to 100 columns
 makes it render in a relatively hard-to-read manner on my 80-col window]
> If I add --enable-threads=pth to the call to configure, test-lock
> runs successfuly ever time. If I make it --enable-threads=posix (or
> let it default to posix), test-lock will very occasionally succeed,
> but more often than not hangs as per my report above. If I define
> ENABLE_DEBUGGING as 1 in test-lock.c, test-lock succeeds regardless of

Thanks for the details.

> the threading library that's used.  I guess this all points to something
> like a thread sync problem in libpthread at glibc-2.7. However, it
> appears that the --enable-threads=blah setting only affects the test
> applications. Whatever I set it to, the coreutils binary rpm I produce
> only ever requires libpthread and only test-tls and test-lock switch
> between requiring libpthread and libpth depending on the setting. In
> that case I'm happy to build the package to use libpth. In any case,
> test-lock et al seem to me to be testing gnulib rather than coreutils,
> although happy to be corrected on that.

That's right.  The tests under coreutils' gnulib-tests/ directory
are unit tests of the gnulib modules used by coreutils.
However, as you would expect of thorough unit tests, in many cases they
test functionality that is seldom (or never) used in the parent package.
So if getting a working coreutils-8.5 package is all you want right now,
you're probably safe.

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

From: Chris Clayton <chris2553 <at> googlemail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: bug-gnulib <at> gnu.org, 6281 <at> debbugs.gnu.org
Subject: Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib
	version
Date: Fri, 28 May 2010 09:53:27 +0100

On Friday 28 May 2010, Jim Meyering wrote:
> Chris Clayton wrote:
> > Hi Jim,
> >
> > I've done some more testing and the outcome is reported below.
>
> ...
>
> [I've reformatted this paragraph for you -- wrapping to 100 columns
>  makes it render in a relatively hard-to-read manner on my 80-col window]
>
Sorry, I've reconfigured kmail to wrap at column 80.

> > If I add --enable-threads=pth to the call to configure, test-lock
> > runs successfuly ever time. If I make it --enable-threads=posix (or
> > let it default to posix), test-lock will very occasionally succeed,
> > but more often than not hangs as per my report above. If I define
> > ENABLE_DEBUGGING as 1 in test-lock.c, test-lock succeeds regardless of
>
> Thanks for the details.
>
> > the threading library that's used.  I guess this all points to something
> > like a thread sync problem in libpthread at glibc-2.7. However, it
> > appears that the --enable-threads=blah setting only affects the test
> > applications. Whatever I set it to, the coreutils binary rpm I produce
> > only ever requires libpthread and only test-tls and test-lock switch
> > between requiring libpthread and libpth depending on the setting. In
> > that case I'm happy to build the package to use libpth. In any case,
> > test-lock et al seem to me to be testing gnulib rather than coreutils,
> > although happy to be corrected on that.
>
> That's right.  The tests under coreutils' gnulib-tests/ directory
> are unit tests of the gnulib modules used by coreutils.
> However, as you would expect of thorough unit tests, in many cases they
> test functionality that is seldom (or never) used in the parent package.
> So if getting a working coreutils-8.5 package is all you want right now,
> you're probably safe.

Because my glibc is so old, I'm fine with that, but if the gnulib folks want to 
follow it up, I'm more than happy to help.

-- 
The more I see, the more I know. The more I know, the less I understand. 
Changing Man - Paul Weller

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

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

From: Chris Clayton <chris2553 <at> googlemail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: bug-gnulib <at> gnu.org, 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: Sun, 30 May 2010 09:41:13 +0100

Hi,

On Friday 28 May 2010, Bruno Haible wrote:
> 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.
>

I built and installed glibc-2.11.1, this time against 2.6.33.4 kernel headers 
instead of the 2.6.26.x headers that were previously in /usr/src/linux. My idea 
was to just test the failing coreutils test application (test-lock), although, 
of course, a failure with this configuration may have been a false failure. 
Anyway. my system seems to be completely stable (although I do have the comfort 
of an archive of the old glibc-2.7-based system) and more importantly in the 
context of coreutils and gnulib, test-lock succeeds every time. I guess that 
could be a false success because all my apps are built against glibc-2.7 but 
running against glibc-2.11.1, but I've given my most frequently used 
applications a quite a good workout and everything seems to be working. On the 
face of it, the problem is in libpthread in glibc-2.7, especially as it went 
away when the coreutil test applications were built against libpth.

Unless someone knows of a really good reason to do so, I'm not minded to chase 
this any longer. I have a workaround to build and test coreutils should I find 
that I need to revert to my glibc-2.7-based system, but for the time being at 
least, I think I'll stick with 2.11.1.

Thanks for your help.

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

-- 
The more I see, the more I know. The more I know, the less I understand. 
Changing Man - Paul Weller

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

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

Chris Clayton wrote:
...
> I built and installed glibc-2.11.1, this time against 2.6.33.4 kernel headers
> instead of the 2.6.26.x headers that were previously in /usr/src/linux. My idea
> was to just test the failing coreutils test application (test-lock), although,
> of course, a failure with this configuration may have been a false failure.
> Anyway. my system seems to be completely stable (although I do have the comfort
> of an archive of the old glibc-2.7-based system) and more importantly in the
> context of coreutils and gnulib, test-lock succeeds every time.

Good!  Thanks for letting us know.

...
> Unless someone knows of a really good reason to do so, I'm not minded to chase
> this any longer.

Sounds good to me.
Life is short enough as it is.

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

From: Jim Meyering <jim <at> meyering.net>
To: 6281-done <at> debbugs.gnu.org
Subject: Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Date: Sun, 17 Apr 2011 10:36:49 +0200

Closing.  This was resolved.  see http://debbugs.gnu.org/6281

Previous Next

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