0.9.29, somethings wrong with linker or threading

[Joakim Tjernlund]

On Mon, 2007-05-14 at 21:03 -0600, Kevin Day wrote:
> First off, good job with this version, for the most part it is
> noticably working better than the previous versions.
> 
> I just ran into a problem with either posix threads (stable)
> (LINUXTHREADS_OLD=y) or something weird going on with the dynamic
> linker.

The dynamic linker hasn't received much updates lately, I suspect
toolchain. Maybe a if you compile uClibc with SUPPORT_LD_DEBUG=y
and run your test app with 
  LD_DEBUG=all ./a.out
can tell us more.

 Jocke
> 
> A simple file is used for testing purposes called test.c, its contents
> are only "int main(){}"
> Using gcc-4.1.2.
> 
> This works
> # gcc test.c
> # ./a.out
> 
> This does not
> # gcc -lao test.c
> # ./a.out
> # Segfault
> 
> This does not
> # gcc -lfuse test.c
> # ./a.out
> # Segfault
> 
> In all two cases above that segfault, directly adding -lpthread fixes
> the segfault problem.
> Looks like anything that depends on some library that links to
> pthread, does not properly recursively link to the pthread (should
> it?).
> As noted by the test.c, no threading is directly done there, but if
> threading is including in a linked library, runtime segfault occurs.
> 
> Here is the valgrind log for vim:
> 
> ==18960==
> ==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFFC
> ==18960==
> ==18960== Process terminating with default action of signal 11 (SIGSEGV)
> ==18960==  Access not within mapped region at address 0xBE2EDFFC
> ==18960==    at 0x4060BEB: _pthread_cleanup_push_defer (in
> /lib/libuClibc-0.9.29.so)
> ==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFF8
> ==18960==
> ==18960== Process terminating with default action of signal 11 (SIGSEGV)
> ==18960==  Access not within mapped region at address 0xBE2EDFF8
> ==18960==    at 0x400A194: _vgnU_freeres (in
> /tools/lib/valgrind/x86-linux/vgpreload_core.so)
> 
> The ldd on vim:
> 	libncurses.so.6 => /lib/libncurses.so.6 (0xb7f75000)
> 	libiconv.so.2 => /lib/libiconv.so.2 (0xb7e97000)
> 	libperl.so => //lib/perl5/5.8.8/i686-linux-thread-multi/CORE/libperl.so
> (0xb7d7d000)
> 	libm.so.0 => /lib/libm.so.0 (0xb7d71000)
> 	libutil.so.0 => /lib/libutil.so.0 (0xb7d6e000)
> 	libc.so.0 => /lib/libc.so.0 (0xb7cdc000)
> 	libintl.so.8 => /lib/libintl.so.8 (0xb7cd3000)
> 	libtinfo.so.6 => /lib/libtinfo.so.6 (0xb7ca9000)
> 	libdl.so.0 => /lib/libdl.so.0 (0xb7ca5000)
> 	libpthread.so.0 => /lib/libpthread.so.0 (0xb7c93000)
> 	libnsl.so.0 => /lib/libnsl.so.0 (0xb7c91000)
> 	libcrypt.so.0 => /lib/libcrypt.so.0 (0xb7c7c000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f94000)
> 
> An ldd on libperl:
> checking sub-depends for '/lib/libnsl.so.0'
> 	libc.so.0 => /lib/libc.so.0 (0xb7efd000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f93000)
> checking sub-depends for '/lib/libdl.so.0'
> 	libc.so.0 => /lib/libc.so.0 (0xb7e9e000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f34000)
> checking sub-depends for '/lib/libm.so.0'
> 	libc.so.0 => /lib/libc.so.0 (0xb7eba000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f50000)
> checking sub-depends for '/lib/libcrypt.so.0'
> 	libc.so.0 => /lib/libc.so.0 (0xb7ed4000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f6a000)
> checking sub-depends for '/lib/libutil.so.0'
> 	libc.so.0 => /lib/libc.so.0 (0xb7eaa000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f40000)
> checking sub-depends for '/lib/libpthread.so.0'
> 	libc.so.0 => /lib/libc.so.0 (0xb7ee0000)
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f76000)
> checking sub-depends for '/lib/libc.so.0'
> 	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7fcc000)
> checking sub-depends for '/lib/libintl.so.8'
> 	libnsl.so.0 => /lib/libnsl.so.0 (0x00000000)
> 	libdl.so.0 => /lib/libdl.so.0 (0x00000000)
> 	libm.so.0 => /lib/libm.so.0 (0x00000000)
> 	libcrypt.so.0 => /lib/libcrypt.so.0 (0x00000000)
> 	libutil.so.0 => /lib/libutil.so.0 (0x00000000)
> 	libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
> 	libc.so.0 => /lib/libc.so.0 (0x00000000)
> 	libintl.so.8 => /lib/libintl.so.8 (0x00000000)
> 	not a dynamic executable
> 
> It looks like the address' were lost during the sub-depends step
>