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

[Jim Meyering]

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