gdb cannot recognize symbol format elf32-i386

[Sergio M. Ammirata, Ph.D.]

Apparently the crash is coming from the malloc function under libc.

Here is more info on the crash:

Program terminated with signal 11, Segmentation fault.
[New process 3278]
[New process 3265]
[New process 3266]
[New process 3267]
[New process 3274]
[New process 3276]
[New process 3277]
[New process 3248]
[New process 3367]
[New process 3264]
#0  0x37783ec1 in malloc (bytes=7719) at
libc/stdlib/malloc-standard/malloc.c:953
953        bck->fd = unsorted_chunks(av);
(gdb) bt
#0  0x37783ec1 in malloc (bytes=7719) at
libc/stdlib/malloc-standard/malloc.c:953
#1  0x080985be in __block_New (p_obj=0x8926648, i_size=7567) at
misc/block.c:55
#2  0x0814946f in Encode (p_enc=0x8926648, p_pict=0x8925478) at x264.c:1345
#3  0x37312e73 in EncoderThread (p_sys=0x88913b0) at transcode.c:2398
#4  0x37809102 in pthread_start_thread (arg=0x3e7ffea0) at
libpthread/linuxthreads.old/manager.c:309
#5  0x37717b92 in clone () at libc/sysdeps/linux/i386/clone.S:106

If it helps, here is the code that does not belong to uClibc in the stack
above:

These are the lines of code at x264.c starting at line 1345:
=========================================================
    p_block = block_New( p_enc, i_out );
    if( !p_block ) return NULL;
    memcpy( p_block->p_buffer, p_sys->p_buffer, i_out );
=========================================================

This is the content on the block_New function in misc/block.c,
Line 55 is the call to malloc
=========================================================
block_t *__block_New( vlc_object_t *p_obj, int i_size )
{
    /* We do only one malloc
     * TODO bench if doing 2 malloc but keeping a pool of buffer is better
     * 16 -> align on 16
     * 2 * BLOCK_PADDING_SIZE -> pre + post padding
     */
    block_sys_t *p_sys;
    const int i_alloc = i_size + 2 * BLOCK_PADDING_SIZE + 16;
    block_t *p_block =
        malloc( sizeof( block_t ) + sizeof( block_sys_t ) + i_alloc );
    .....
}
=========================================================

Thanks,

Sergio


On 11/6/09 6:00 PM, "Mike Frysinger" <vapier at gentoo.org> wrote:

> On Friday 06 November 2009 17:22:12 Sergio M. Ammirata, Ph.D. wrote:
>> 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).
> 
> file a bug with the buildroot people then
> 
>> 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?
> 
> and enable debugging in your code
> 
>> This crash was not happening with 0.9.28 with the same application.
> 
> that doesnt completely implicate uClibc as the problem.  often times changing
> C library can make the application behave slightly differently and thus crash
> in ways it didnt before.
> -mike