uClibc-0.9.28.3 bugs

Kevin Day thekevinday at gmail.com
Sat Sep 29 00:23:12 UTC 2007


On 9/28/07, Bernhard Fischer <rep.dot.nop at gmail.com> wrote:
> On Fri, Sep 28, 2007 at 05:14:32PM -0500, Kevin Day wrote:
>
> >Is there to be a release of 0.9.28.4 with this fix?
> >I currently cannot use 0.9.29 due to obscure bugs that vanish when I
> >simply change uClibc to 0.9.28.3.
>
> What kind of bugs do you see with 0.9.29?
> Do you have some small testcases that exhibit the problem(s)?
>
I wish I could give you "small" test cases. Most of the problems do
not surface until the more complicated applications begin to appear.

That aside, here are my problems, of which may or may not be related:

1) Kernel 2.6.2? compiled with SMP enabled, will systematically
destroy itself and collapse  in a series of kernel panics flood the
system until the OS comes to a complete windows style lockup.

My first impression was that there was some serious regression in the
kernel+hardware I was using or that the kernel may have had an
isolated corrupt compilation.  Repeated attempts on different hardware
and the SMP-kernel crash was consistent.
I later build a uClibc-0.9.28.3 system and I have yet to see the
SMP-kernel crash reproduce itself on the same hardware.
The 0.9.29 crash took no more than a day and I have been running an
intel dual-processor server for a few weeks now under the SMP kernel
compiled under a uClibc-0.9.28.3.
My memory checks out clear and compilation between tests was done
under different systems just in case.

I have no way of figuring out what/where this is happening,
considering that the kernel has its own internal libc equivalent code.

That suggests that gcc and/or binutils is somehow becoming corrupt under 0.9.29?
If so, this may be the cause of the other obscure problems I am having..

2) Fuse jumps into a (threaded?) deadlock.
This problem exists in 0.9.28.3, but I have a work-around under
0.9.28.3. That work-around no longer works around the problem in
0.9.29. I explecitly need fuse and so long as I cannot use fuse, I
cannot change to 0.9.29.

I mount a fuse filesystem such as sshfs:
1) sshfs localhost:/home/kevin/directory1 /home/kevin/directory2
2) df
3) deadlock.

1) sshfs localhost:/home/kevin/directory1 /home/kevin/directory2
2) ls /home/kevin/<tab key pressed at this point>
3) deadlock.

1) sshfs localhost:/home/kevin/directory1 /home/kevin/directory2
2) cd /home/kevin/directory2/
3) deadlock.

While studing fuse's code, I noticed asm that added ".symver" elf tags
as well as other different link time ".symver" references.  Removing
the asm from the code caused the problem to vanish.  The only harm is
not having version .symver elf tags.

I thought the problem was with .symver and also specific to fuse's
asm.  For that reason, I saw no reason to report the problem here.
Now that 0.9.29 is out, I eventually noticed that fuse was once again
deadlocking, despite the asm-removal.  Removal of the .symver elf tags
no longer solved/worked-around the problem.

3) And for reference, there is this problem:
http://uclibc.org/lists/uclibc/2007-May/017920.html
But I keep forgetting to check to see if using binutils-2.18 removes
this particular problem just like switching to 0.9.28.3 removes the
problem.

4) There are more problems with deadlocking as with #2 or random
crashing as with #1.
#1 seems to happen mostly with applications that are graphical (xorg
or gtk based apps..).
#2 happens to a very small number of apps, such as qingy (in qingy's
case the crash is a fatal kernel-level deadlock, time to hard-reboot).

-- 
Kevin Day



More information about the uClibc mailing list