uClibc-0.9.28.3 bugs

[Carmelo Amoroso]

Kevin Day wrote:
> 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.
What does it mean? kernel builds independently of any *libc
> 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.
>
Note that uclibc ld.so doesn't support symbol versioning.
Check carefully your ELF binaries.


> 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).
> 
I'm convinced, at first glance, your problem are within your kernel,
nothing to do with *libc libraries.

Regards,
Carmelo