gdb cannot recognize symbol format elf32-i386

Sergio M. Ammirata, Ph.D. sergio at ammirata.net
Sat Nov 7 04:59:50 UTC 2009


Hello Khem,


On 11/6/09 6:39 PM, "Khem Raj" <raj.khem at gmail.com> wrote:

> On (06/11/09 17:22), Sergio M. Ammirata, Ph.D. wrote:
>> Hello Timo,
>> 
>> Thanks for your advise. I was indeed compiling gdb as part of the buildroot
>> process. I compiled it on my target instead and now I can see the backtrace
>> without any errors (I use a plain ./configure and make on the original gdb
>> source).
>> 
>> Program terminated with signal 11, Segmentation fault.
>> [New process 8262]
>> [New process 8260]
>> [New process 8249]
>> [New process 8350]
>> [New process 8248]
>> [New process 8194]
>> [New process 8246]
>> [New process 8247]
>> [New process 8259]
>> [New process 8251]
>> #0  0x3767fb0e in malloc () from /lib/libc.so.0
>> (gdb) bt
>> #0  0x3767fb0e in malloc () from /lib/libc.so.0
>> #1  0x00000000 in ?? ()
>> 
>> How can I dig deeper into this error now?
>> Should I compile the uclibc with full debug symbols and remove the strip
>> option in the config as well?
>> 
>> This crash was not happening with 0.9.28 with the same application.
> 
> this could be happening because libpthread.so is not being loaded before
> use. which threading library are you using ?
> 
> what happens if you pass -pthread on commandline does the app segfault
> sameway ?
> 
> another issue I remember with new linuxthreads, there were some issues because
> some parts were not
> compiled with SHARED which also caused problems.
> 
> Post your complete link commands with verbose options.
> 
> Thx
> 
> -Khem

At first I thought it was a problem with pthreads too. As a matter of fact,
I spent a week trying to get nptl trunk compiled and integrated into my
build. I was 99% there. I had to statically link it with my apps because of
a bug in non-shared symbols but I could not get past the fact that when
statically linking it into shared libs it makes them unusable (they won't
load complaining about fPIC as well).

Now, I went back to trying to find out more about the crash. I tried with
the main uclibc trunk (snapshot from yesterday) and configured and tested
with new libpthread and the old stable one. In both cases the crash occurs.
So, I think the problem is not directly there but in some common code
between the two. However, if I tell the application to use only one thread,
it does not crash.

The application does not crash right away either, nor does it crash always.
It depends on the source file (I am doing transcoding using vlc/x264).

Any more ideas?

Thanks,

Sergio




More information about the uClibc mailing list