> -----Original Message----- > From: Kevin Day [mailto:[EMAIL PROTECTED] > Sent: den 16 maj 2007 21:37 > To: [EMAIL PROTECTED] > Cc: uclibc > Subject: Re: 0.9.29, somethings wrong with linker or threading > > On 5/16/07, Joakim Tjernlund <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-05-16 at 08:32 -0600, Kevin Day wrote: > > > On 5/16/07, Joakim Tjernlund > <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2007-05-15 at 18:27 -0600, Kevin Day wrote: > > > > > okay, with all debug optiosn except LD_DEBUG_EARLY, > things compiled as > > > > > they did before. > > > > > > > > > > Now that I have a debuggability, I performed two tests. > > > > > I used perl for my tests as it also produces the same > errors and..well > > > > > just about all things using pthread. > > > > > first was 'gcc -lperl -lpthread test.c' > > > > > i then logged 'LD_DEBUG=all ./a.out' > > > > > > > > > > the second was 'gcc -lperl test.c' > > > > > i then logged 'LD_DEBUG=all ./a.out' > > > > > > > > > > To see what is going on differently between the two, > I made a diff of > > > > > the two logs. > > > > > I called it log.patch so vim would use syntax > highlighting (.patch extension). > > > > > > > > > > The diff of the two tests is attached. > > > > > > > > > > > > > Its a bit hard to make out what is going on from a diff > only, but it > > > > appears that the INIT processing in libpthread is SEGV, > but only if > > > > libpthread is loadead after libc. Perhaps commenting stuff out > > > > in pthread_initialize() will pinpoint the error. > > > > Maybe it is an uncommon CONFIG option thats causing it(LOCALE?) > > > > > > > > Jocke > > > > > > > > > > > > > > > > > > I constantly worry about size limitations, but here is my > config and > > > the complete segfaulting log > > > > > > I will look into pthread_initialize. > > > locale is enabled > > > > Try turning locale off. > > > > > > > > What i am seeing on the patch is that the non-segfaulting version > > > calls _dl_get_ready_to_run:814: calling INIT: > /lib/libintl.so.8 before > > > libpthread. > > > > Can you post can the other log too? > > You already have it, in a manner of speaking. > put the complete segfaulting log I gave you, and the diff in > the same directory > use patch for the diff of the logs, 'patch -Np0 -i log.patch' > This will give you the complete log for the non-segfaulting version
Yeah, that hit me shortly after sending the reply, was in a hurry trying to get home in time. > > > > > > > > > > Another thing that sticks out to me is that > "_dl_fixup:664: relocation > > > processing: /lib/libpthread.so.0" happends in the > non-segfaulting one, > > > but does appear in the segfaulting one. > > ? something is missing here. That message is present in both cases. > > Are you familiar with diff files? I know them fairly well :) > > In diff files, there is a first character for each line > a space ' ' means no change > a minus '-' means remove this > a plus '+' means add this > > when the diff file contains only a '+' and is not followed by or > preceded by a relating '-', then this means that there is something > completely different. > > Just in case you are in fact not familair with diff and do not have > the patch command, I will attach the other log anyway. > > > > > > > > > And finally there is the part you mentioned about pthread. > > > > > > Those things stood out to me in the diff, i will look > into commenting > > > out pthread_initialize() > > > > Start with commenting out locale stuff and then stdio > > > > Jocke > > > > I am working on getting the locale off, but I will again have to > completely build a new system in part due to the new build system > depending on, which is then linked to locale, so I cannot. > > First I will build a system only disabling locale via the > uclibc.config options and after that is logged, directly start > commenting out code, which should hopefully be only stdio code at that > point due to locale no longer being built. Got your logs with locale off and I can't see anything new in there. Now you got a fairly common config and a fairly common case that SEGV. Your are the first to report such problems in a long time. Your are using gcc 4.1.2(binutils version?) and I don't think many are using such a new compiler. So I am guessing that eithter you have a bug in you toolchain, something changed w.r.t relocation/weak syms etc. or your new toolchain managed to expose a bug in uClibc. I think it is time to bring out GDB and look at a coredump to see exactly where it crashed. Jocke _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
