Compiling an running the following test program gets a segfault when compiled with -O2 and dynamically linked: #define _REENTRANT #define _THREAD_SAFE #define _MIT_POSIX_THREADS 1 #include <pthread.h> void *foo(void *bar) { pthread_exit(0); return 0; } pthread_mutexattr_t attr; pthread_mutex_t tmp; pthread_t gazonk; int main() { void *sune; pthread_mutexattr_init(&attr); pthread_mutex_init(&tmp, &attr); pthread_mutex_lock(&tmp); pthread_create(&gazonk,0,foo,0); pthread_join(gazonk,&sune); exit(0); } $ gcc -g -o pthread_test -O pthread_test.c -lpthread $ ./pthread_test $ gcc -g -o pthread_test -O2 pthread_test.c -lpthread $ ./pthread_test Segmentation fault $ gcc -g -o pthread_test -static -O2 pthread_test.c -lpthread $ ./pthread_test $ As usual a recent gdb has problems with the stack: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2305843009224864384 (zombie)] 0x2000000000abe400 in _Unwind_GetBSP () from /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.2/libgcc_s.so.1 (gdb) bt #0 0x2000000000abe400 in _Unwind_GetBSP () from /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.2/libgcc_s.so.1 #1 0x2000000000abe7a0 in _Unwind_GetBSP () from /usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.2/libgcc_s.so.1 Previous frame identical to this frame (corrupt stack?) It used to work with glibc-2.3.2, but that didn't have support for nptl on ia64. Reproducible: Always Steps to Reproduce: 1. As above Actual Results: The test program segfaulted. Expected Results: It should have exited with exit code 0. Portage 2.0.51-r8 (default-linux/ia64/2004.3, gcc-3.3.2, glibc-2.3.4.20041102-r0, 2.6.8-gentoo-r3 ia64) ================================================================= System uname: 2.6.8-gentoo-r3 ia64 Gentoo Base System version 1.6.7 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Nov 29 2004, 11:29:43)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.6.3, 1.8.5-r2, 1.7.9, 1.4_p6, 1.9.3 sys-devel/binutils: 2.14.90.0.8-r1, 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1, 2.6.8.1-r1 ACCEPT_KEYWORDS="ia64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi berkdb bitmap-fonts bzlib canna cjk crypt cups emacs encode f77 foomaticdb fortran freetds gdbm gif gmp gnutls gpm gtk gtk2 ia64 imlib ipv6 jpeg libg++ libwww maildir mbox mhash mikmod mime motif mule multilib mysql mysqli ncurses nis nls nptl odbc offensive oggvorbis opengl oss pam pcre pdflib perl pic pie png posix python qt quicktime readline recode samba sdl spell sqlite ssl tcpd tiff truetype unicode xml2 xmms xpm xv zlib"
no problems here why dont you try upgrading your gcc from one that isnt so old ? :p gcc-3.3.4-r1 is x86 stable
x86 stable, yes, ia64 stable, no: # emerge -p gcc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-devel/gcc-3.3.2-r2 But I'll try with the ~ia64 gcc (3.4.3-r1).
Ok, seems gcc-3.4.3-r1 fixes the problem, so the remainder is that gcc-3.4.3 must go stable for ia64 before glibc-2.3.4 does.
bah, i missed the ia64 fact fyi, i dont think any dev has done nptl on ia64 :P i know i havent, and i tend to be the ia64 dev guy who tests the latest crap
