[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib ve
From: |
Chris Clayton |
Subject: |
Re: bug#6281: Fwd: Possible bug in coreutils-8.5 or associated gnulib version |
Date: |
Sun, 30 May 2010 09:41:13 +0100 |
User-agent: |
KMail/1.9.10 |
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