Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version

[Chris Clayton]

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