From Bugzilla Helper: User-Agent: Mozilla/4.7 [en]C-AOLNSCP (WinNT; U) Description of problem: I filed this bug as bug libc/2451 at http://bugs.gnu.org/cgi-bin/gnatsweb.pl. Since we are using a Red Hat product, I thought I should also file a bug report here. The following text is copied from bug libc/2451. This bug may be related to bug libc/2450, but since the stack trace looks completely different and the frequency is much lower (I've only seen one core file with this stack trace), I am filing this as a separate bug. Our project is a set of C libraries and command-line tools. Although we are not using the -pthread flag, all the C files are compiled with -D_REENTRANT and all the executables are linked with -lpthread before any other system libraries. We are having intermittent segmentation faults when running our command-line tools or test programs on Red Hat Linux 7.1. (Both of our Red Hat Linux 7.1 systems are dual-processors.) One of the core files has this stack trace: (gdb) where #0 __pthread_alt_lock (lock=0x402dd9d0, self=0x0) at spinlock.c:407 #1 0x401a0c86 in __pthread_mutex_lock (mutex=0x402dd9c0) at mutex.c:120 #2 0x401e2328 in __new_exitfn () at cxa_atexit.c:55 #3 0x401e22cb in __on_exit (func=0x401a22f0 <pthread_onexit_process>, arg=0x0) at on_exit.c:26 #4 0x401a1539 in pthread_initialize () at pthread.c:449 #5 0x401a5d25 in __do_global_ctors_aux () at eval.c:41 #6 0x4019da1a in _init () at eval.c:41 #7 0x4000e0f7 in _dl_init () at eval.c:41 (gdb) It looks like the process crashed before main() was even executed. The output of the 'ldd' command on the executable that crashed shows that we link with -lpthread before -lc: % ldd tstclnt libssl3.so => not found libsmime3.so => not found libnss3.so => not found libplc4.so => not found libplds4.so => not found libnspr4.so => not found libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40022000) libdl.so.2 => /lib/libdl.so.2 (0x40037000) libc.so.6 => /lib/i686/libc.so.6 (0x4003b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) How reproducible: Sometimes Steps to Reproduce: I don't have a small test program that reproduces the problem, so I am afraid that you will need to build our project and run our tests. Even with our tests it may be difficult to reproduce this crash. I have only seen this stack trace once. (It is easy to reproduce the crashes reported in bug libc/2450 with our tests though.) Our source code can be downloaded as a gzipped tar file from ftp://ftp.mozilla.org/pub/security/nss/releases/NSS_3_3_RTM/src/nss-3.3.tar.gz. To build it, unpack the tar file and do: % cd mozilla/security/nss % make nss_build_all To run the tests, follow these steps: % cd mozilla/security/nss/tests % ./all.sh The test results will be in mozilla/tests_results/security/<host>.<n>, where <host> is the host name and <n> is 1, 2, ... indicating the n-th run of ./all.sh. There are two files in the <host>.<n> directory that you need to look at: results.html and output.log. If any of the tests crashes, the core file will be found under a subdirectory in <host>.<n>. You may need to run ./all.sh repeatedly to cause a segmentation fault because the crash is intermittent. The executables of the tests are in mozilla/dist/Linux2.4_x86_glibc_PTH_DBG.OBJ/bin. Actual Results: Got a segmentation fault from the test 'tstclnt'. Expected Results: The results.html files under mozilla/tests_results/security/<host>.<n> should be all "Passed" in green. Additional info: OS: Red Hat Linux 7.1 Kernel: 2.4.2-2smp on a 2-processor i686 gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) glibc version 2.2.2
The more frequent segmentation fault in __errno_location() (libc/2450) was filed as Bugzilla bug 50661.
Try RHL9 which contains a completely new thread implementation. There is no known issues of this kind with the code in glibc 2.3.2-27.9.