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:
#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)
#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
It looks like the process crashed before main() was even
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)
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
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
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
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.
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.