Kevin Day wrote: > On 9/28/07, Bernhard Fischer <[EMAIL PROTECTED]> 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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
