GNU bug report logs -
#6281
Fwd: Possible bug in coreutils-8.5 or associated gnulib version
Previous Next
Full log
Message #17 received at 6281 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 14 years and 41 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.