Created attachment 4898 [details]
Sample code

When compiling one of my applications with -static and uclibc, every detached thread crashes on exit as long as I use pthread_exit. 

It's reproducible with a minimal sample that I am attaching, and it only happens in static builds. There is no crash with the sample when using glibc with static linking. 

When running the sample with a dynamic compilation ( "i586-linux-gcc -pthread -o test detached.c" ), this is the result:

# ./test 
Main: creating thread
Thread starting...
Thread done.
Main: program completed. Exiting.
# 


When compiling a static binary using "i586-linux-gcc -static -pthread -o test detached.c", this is the result:

# ./test 
Main: creating thread
Thread starting...
Thread done.
Segmentation fault
# 


Using gdb to backtrace the crash gives this result:

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 12596]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0804baf1 in siglongjmp ()
#2  0x0804ab19 in ?? ()
#3  0x08055cd1 in _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf778fdf0, context=context@entry=0xf778fa14)
    at /mnt/External/toolchains/buildroot-2013.02/output/toolchain/gcc-4.7.2/libgcc/unwind.inc:163
#4  0x080560fc in _Unwind_ForcedUnwind (exc=0xf778fdf0, stop=0x804aa40, stop_argument=0xf778fb34)
    at /mnt/External/toolchains/buildroot-2013.02/output/toolchain/gcc-4.7.2/libgcc/unwind.inc:207
#5  0x0804aba9 in __pthread_unwind ()
#6  0x0804a1ae in pthread_exit ()
#7  0x080489d2 in doWork ()


The siglongjmp seems to be trying to jump to NULL, so my limited knowledge makes me think there's some function not being added to the final binary in the static linking and ending up being NULL in the table.

Dynamic builds work as expected. Removing pthread_exit(NULL) from the thread function makes the thread end gracefully as far as I can tell. According to the manpage for pthread_exit, "Performing a return from the start function of any thread other than the main thread results in an implicit call to pthread_exit()", so I'm not sure if there isn't another bug hidden there.

This should be easily reproduced on linux using buildroot-2013.02 with the attached .config file. Also tested selecting gcc 4.6 in buildroot, with the same result.