strange segfault with pthreads in 0.9.28

[Rupert Mazzucco]

> segfault.  A minimal reproduction is below.  Does anybody have an idea 
> what could be causing this?
> 
> Something has to be wrong on your site, I am using many apps that are 
> linked against libpthread and haven't seen this

Yes, I'm afraid so.  Google found hardly any reference to such a problem. 
About the only one was, interestingly, an old linuxthreads faq on the
uclibc.org site (can't find it now from the homepage), where the same
symptom was described for apps compiled without -D_REENTRANT.

> (only if you use uClibc-svn and the new linuxthreads)

No, it's stock 0.9.28 release.  I would have tried a newer one, but are
somewhat discouraged by what the list archives have to say about the status
of the svn.  Binutils are 2.16.1, btw.  So just to verify that what I did
_should_ normally work, or maybe someone can spot a problem there:

- I used a recent buildroot snapshot to build a
uClibc-09.28/gcc-3.4.6/binutils-2.16.1 toolchain and a minimal busybox root
file system.  I had buildroot put the tools on the target fs to continue
development there (so it's not really a cross-compiler, but a host
compiler).

- At first, I would chroot into the new root fs, because I had no bootable
system yet.  Partly for testing the build environment, and partly because I
thought it couldn't hurt, I then rebuilt gcc (I found I had to use the
patched sources that know --host=i686-linux-uclibc) and uClibc, also
upgraded make from 3.80 to 3.81 because of some dubious problem with vm
exhaustion, replaced some busybox utils with GNU's because I (or rather,
scripts) found them lacking functionality (find, tar, cpio, diff, patch),
deleted ccache by hand because it annoyed me with its attempts to scribble
around on my precious flash card, built some more stuff and eventually a
kernel with all the above stuffed into an initramfs.  So all in all, I think
I gave the toolchain a good workout, and didn't notice any problems.  But i
seems now that was because nothing so far had touched pthreads.

- I have to note that all that was done under the 2.4.26 kernel of the host
system where I had my chroot jail.  I realized only later that using the
built-with-2.6-headers-uclibc apps with this kernel was not guaranteed to
work, but it seems like it did, and so far I didn't notice any difference in
app behaviour in the chroot jail and with the real 2.6 kernel.

It occurs to me while I write this, that for some reason this could have
prevented the pthreads support from building properly.  Does that sound like
a possibility?  Anyway, I'll have to to try and rebuild my toolchain under
the new kernel now.

Thank you,
Rupert

> 
> Peter
>  
> > # cat > foo.c
> > int main() {}
> > # gcc foo.c
> > # ./a.out
> > # gcc foo.c -lpthread
> > # ./a.out
> > Segmentation fault
> > # ldd a.out
> >         libpthread.so.0 => /lib/libpthread.so.0 (0x40008000)
> >         libc.so.0 => /lib/libc.so.0 (0x4001a000)
> >         ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
> > # gcc -D_REENTRANT foo.c -lpthread
> > # ./a.out
> > Segmentation fault
> > # gcc -v
> > Reading specs from /pkg/tools/lib/gcc/i686-linux-uclibc/3.4.6/specs
> > Configured with: ../buildroot/toolchain_build_i686/gcc-3.4.6/configure
> --host=i686-linux-uclibc --prefix=/pkg/tools --enable-shared
> --enable-threads --disable-nls --with-arch=c3
--with-sysroot=/pkg/uClibc-0.9.28
> --enable-languages=c,c++,f77 --disable-__cxa_atexit
> > 
> > (uClibc built with kernel headers from 2.6.16, buildroot snapshot
> 20060418)
> > 
> > 
> 
> -- 
> Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
> Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2
> 

-- 
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl