gdb cannot recognize symbol format elf32-i386

[Sergio M. Ammirata, Ph.D.]

Hello ...

I am trying to debug the cause of a pthread crash. When I use gdb to look at
the coredump file I get this message:
I'm sorry, Dave, I can't do that. Symbol format `elf32-i386` unknown
what am I missing? I need to find out where the crash is coming from.

Thanks,

Sergio
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Mike Frysinger]

On Friday 06 November 2009 13:37:21 Sergio M. Ammirata, Ph.D. wrote:
> I am trying to debug the cause of a pthread crash. When I use gdb to look
>  at the coredump file I get this message:
> I'm sorry, Dave, I can't do that. Symbol format `elf32-i386` unknown
> what am I missing? I need to find out where the crash is coming from.

you really need to describe your system in detail every time you post a
question here.  we cant read your mind and going through any recent
correspondences for details wastes our time.

assuming you're doing a self hosting x86/uClibc install with NPTL, and you're
running gdb natively as well ... still dont know what version of gdb you're
using though ...

what about debugging a simple application ?  compile a simple 'main(){}',
break on the main symbol, and create a core dump with generate-core-file.  see
if gdb can work on that simple file.  that would indicate a general problem
with core files rather than a specific one with pthreads (since gdb needs
invasive support in order to properly debug threaded apps).
-mike


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[tike64-2]

Hi,

I can't actually help but I can give another data point. Although I have an ARM
system I have exactly the same symptoms.

Sergio M. Ammirata, Ph.D. wrote:
> I am trying to debug the cause of a pthread crash.

I have an application which links with libvncclient 0.9.7 and crashes before
main somewhere in pthread initialization. When I linked the libvncclient
statically, the crash went away - don't know yet if the vnc functionality works
properly though.

> When I use gdb to look at the coredump file I get this message: I'm sorry,
> Dave, I can't do that. Symbol format `elf32-i386` unknown what am I missing?
> I need to find out where the crash is coming from.

When I tried to debug the application (gdb 6.8), I got exactly the same message
(elf32-littlearm in place of elf32-i386). Funny thing is that the gdb worked
when I built it outside of the buildroot but with the same tools and with
virtually the same configuration, only irrelevant points simplified. I have not
yet found out which one of the simplifications was not so irrelevant...

--

Timo

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Sergio M. Ammirata, Ph.D.]

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.

BTW: I am using a main trunk uclibc snapshot from today. It is compiled
using x86/586 and using a buildroot snapshot from 10/31/2009

Thanks,

Sergio


On 11/6/09 4:19 PM, "tike64@..." <tike64@...> wrote:

> Hi,
>
> I can't actually help but I can give another data point. Although I have an
> ARM
> system I have exactly the same symptoms.
>
> Sergio M. Ammirata, Ph.D. wrote:
>> I am trying to debug the cause of a pthread crash.
>
> I have an application which links with libvncclient 0.9.7 and crashes before
> main somewhere in pthread initialization. When I linked the libvncclient
> statically, the crash went away - don't know yet if the vnc functionality
> works
> properly though.
>
>> When I use gdb to look at the coredump file I get this message: I'm sorry,
>> Dave, I can't do that. Symbol format `elf32-i386` unknown what am I missing?
>> I need to find out where the crash is coming from.
>
> When I tried to debug the application (gdb 6.8), I got exactly the same
> message
> (elf32-littlearm in place of elf32-i386). Funny thing is that the gdb worked
> when I built it outside of the buildroot but with the same tools and with
> virtually the same configuration, only irrelevant points simplified. I have
> not
> yet found out which one of the simplifications was not so irrelevant...
>
> --
>
> Timo

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Mike Frysinger]

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


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

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
_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Sergio M. Ammirata, Ph.D.]

Hello Mike,

On 11/6/09 6:00 PM, "Mike Frysinger" <vapier@...> 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
>

I will do that. And will also report the coreutils not compiling problem. I
did not realize they had a different list.

>> 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
>

I already had debugging enabled in my code. The app doubled in size with the
symbols. I will enable the other debugging parameters and try again.

>> 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

I am compiling in the exact same machine with almost identical uclibc-config
as in 0.9.28. The only significant difference is the version of the gcc
library (gcc 4.3.4 vs. 3.x) being compiled by the toolchain. Is this what
you mean?

I have also tried with different gcc selection (4.3.3 and 4.4x) with the
same results.

Thanks,

Sergio


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Sergio M. Ammirata, Ph.D.]

Hello Khem,


On 11/6/09 6:39 PM, "Khem Raj" <raj.khem@...> 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


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[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@...> 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

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Mike Frysinger]

On Saturday 07 November 2009 07:04:40 Sergio M. Ammirata, Ph.D. wrote:
> Apparently the crash is coming from the malloc function under libc.

or someone tromped on memory they shouldnt and uClibc crashed due to that

try using the malloc-simple implementation and see if that crashes as well

or post some simple code that reproduces the crash for someone else to verify
-mike


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Sergio M. Ammirata, Ph.D.]

Mike,

Here is the backtrace when using malloc:

Program terminated with signal 11, Segmentation fault.
[New process 1788]
[New process 1752]
[New process 1784]
[New process 1783]
[New process 1789]
[New process 1791]
[New process 1787]
[New process 1785]
[New process 1786]
#0  0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
184          mem = MALLOC_SETUP (mem, size);
(gdb) bt
#0  0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
#1  0x3782e53c in malloc (size=506912) at libc/stdlib/malloc/malloc.c:223
#2  0x3782eb10 in memalign (alignment=16, size=506880) at
libc/stdlib/malloc/memalign.c:48
#3  0x08083fd1 in __vout_AllocatePicture (p_this=0x8d74f6c, p_pic=0x9a1a048,
i_chroma=808596553, i_width=704, i_height=480, i_aspect=576000) at
video_output/vout_pictures.c:515
#4  0x373bdacf in video_new_buffer (p_this=0x8d74f6c, pp_ring=0x8893868,
p_sys=0x8885680) at transcode.c:2499
#5  0x08144ed4 in DecodeBlock (p_dec=0x8d74f6c, pp_block=0x3efff89c) at
libmpeg2.c:604
#6  0x373c026d in Send (p_stream=0x887f6c8, id=0x8892bf8,
p_buffer=0xcf0bec0) at transcode.c:2030
#7  0x373e00a6 in Send (p_stream=0x887e32c, id=0x8892bd0,
p_buffer=0xcf0bec0) at duplicate.c:277
#8  0x0809182c in sout_InputSendBuffer (p_input=0x8892bc0,
p_buffer=0xcf0bec0) at stream_output/stream_output.c:279
#9  0x080d31e8 in DecoderDecode (p_dec=0x88a91bc, p_block=0xd232f28) at
input/decoder.c:579
#10 0x080d70ac in EsOutSend (out=0x887b21c, es=0x88a6e08, p_block=0xd232f28)
at input/es_out.c:1107
#11 0x080ffed9 in ParsePES (p_demux=0x8890c64, pid=0x999cf10) at
../../include/vlc_es_out.h:109
#12 0x08101a58 in Demux (p_demux=0x8890c64) at ts.c:1927
#13 0x08073a6f in MainLoop (p_input=0x8882170) at input/input.c:538
#14 0x08074b17 in Run (p_input=0x8882170) at input/input.c:444
#15 0x378b3136 in pthread_start_thread (arg=0x3efffea0) at
libpthread/linuxthreads.old/manager.c:309
#16 0x377c2c12 in clone () at libc/sysdeps/linux/i386/clone.S:106

The crash happens in a completely different part of the application but it
is still a malloc crash. I will try malloc-simple next.

Sergio

On 11/7/09 8:14 AM, "Mike Frysinger" <vapier@...> wrote:

> On Saturday 07 November 2009 07:04:40 Sergio M. Ammirata, Ph.D. wrote:
>> Apparently the crash is coming from the malloc function under libc.
>
> or someone tromped on memory they shouldnt and uClibc crashed due to that
>
> try using the malloc-simple implementation and see if that crashes as well
>
> or post some simple code that reproduces the crash for someone else to verify
> -mike


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Sergio M. Ammirata, Ph.D.]

Hello,

With the malloc-simple uclibc, my main buildscript goes to 100% CPU usage
and never comes back.

According to Mike, the most likely scenario is the calling application
corrupting memory. So, I am going down the path of trying to upgrade
VLC/x264 to the latest version.

I compiled the latest x264 without much difficulty but I am stuck on VLC
because of 2 missing functions on the new pthread:

pthread_condattr_setclock
pthread_condattr_getclock

I know these functions are in the nptl branch. Can someone point me in the
right direction for how to patch the main branch with them?

Thanks,

Sergio


On 11/7/09 8:57 AM, "Sergio M. Ammirata, Ph.D." <sergio@...> wrote:

> Mike,
>
> Here is the backtrace when using malloc:
>
> Program terminated with signal 11, Segmentation fault.
> [New process 1788]
> [New process 1752]
> [New process 1784]
> [New process 1783]
> [New process 1789]
> [New process 1791]
> [New process 1787]
> [New process 1785]
> [New process 1786]
> #0  0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
> heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
> 184          mem = MALLOC_SETUP (mem, size);
> (gdb) bt
> #0  0x3782e44a in __malloc_from_heap (size=506916, heap=0x37870bd8,
> heap_lock=0x37874e3c) at libc/stdlib/malloc/malloc.c:184
> #1  0x3782e53c in malloc (size=506912) at libc/stdlib/malloc/malloc.c:223
> #2  0x3782eb10 in memalign (alignment=16, size=506880) at
> libc/stdlib/malloc/memalign.c:48
> #3  0x08083fd1 in __vout_AllocatePicture (p_this=0x8d74f6c, p_pic=0x9a1a048,
> i_chroma=808596553, i_width=704, i_height=480, i_aspect=576000) at
> video_output/vout_pictures.c:515
> #4  0x373bdacf in video_new_buffer (p_this=0x8d74f6c, pp_ring=0x8893868,
> p_sys=0x8885680) at transcode.c:2499
> #5  0x08144ed4 in DecodeBlock (p_dec=0x8d74f6c, pp_block=0x3efff89c) at
> libmpeg2.c:604
> #6  0x373c026d in Send (p_stream=0x887f6c8, id=0x8892bf8,
> p_buffer=0xcf0bec0) at transcode.c:2030
> #7  0x373e00a6 in Send (p_stream=0x887e32c, id=0x8892bd0,
> p_buffer=0xcf0bec0) at duplicate.c:277
> #8  0x0809182c in sout_InputSendBuffer (p_input=0x8892bc0,
> p_buffer=0xcf0bec0) at stream_output/stream_output.c:279
> #9  0x080d31e8 in DecoderDecode (p_dec=0x88a91bc, p_block=0xd232f28) at
> input/decoder.c:579
> #10 0x080d70ac in EsOutSend (out=0x887b21c, es=0x88a6e08, p_block=0xd232f28)
> at input/es_out.c:1107
> #11 0x080ffed9 in ParsePES (p_demux=0x8890c64, pid=0x999cf10) at
> ../../include/vlc_es_out.h:109
> #12 0x08101a58 in Demux (p_demux=0x8890c64) at ts.c:1927
> #13 0x08073a6f in MainLoop (p_input=0x8882170) at input/input.c:538
> #14 0x08074b17 in Run (p_input=0x8882170) at input/input.c:444
> #15 0x378b3136 in pthread_start_thread (arg=0x3efffea0) at
> libpthread/linuxthreads.old/manager.c:309
> #16 0x377c2c12 in clone () at libc/sysdeps/linux/i386/clone.S:106
>
> The crash happens in a completely different part of the application but it
> is still a malloc crash. I will try malloc-simple next.
>
> Sergio
>
> On 11/7/09 8:14 AM, "Mike Frysinger" <vapier@...> wrote:
>
>> On Saturday 07 November 2009 07:04:40 Sergio M. Ammirata, Ph.D. wrote:
>>> Apparently the crash is coming from the malloc function under libc.
>>
>> or someone tromped on memory they shouldnt and uClibc crashed due to that
>>
>> try using the malloc-simple implementation and see if that crashes as well
>>
>> or post some simple code that reproduces the crash for someone else to verify
>> -mike
>
>
> _______________________________________________
> uClibc mailing list
> uClibc@...
> http://lists.busybox.net/mailman/listinfo/uclibc

_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc

[Mike Frysinger]

On Sunday 08 November 2009 09:27:42 Sergio M. Ammirata, Ph.D. wrote:
> With the malloc-simple uclibc, my main buildscript goes to 100% CPU usage
> and never comes back.
>
> According to Mike, the most likely scenario is the calling application
> corrupting memory. So, I am going down the path of trying to upgrade
> VLC/x264 to the latest version.

malloc-simple is as simple as you can get -- it's based entirely on calling
mmap/munmap from the kernel.  so the likely hood of that code having a bug is
very small.  that doesnt mean other things (like pthread) are bug free, just
that you probably have to look elsewhere.
-mike


_______________________________________________
uClibc mailing list
uClibc@...
http://lists.busybox.net/mailman/listinfo/uclibc