Bug 50663 - Crash in __pthread_alt_lock() during pthread_initialize() on Red Hat Linux 7.1.
Summary: Crash in __pthread_alt_lock() during pthread_initialize() on Red Hat Linux 7.1.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-01 22:31 UTC by Wan-Teh Chang
Modified: 2016-11-24 15:24 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2003-04-22 02:02:29 UTC

Attachments (Terms of Use)

Description Wan-Teh Chang 2001-08-01 22:31:12 UTC
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

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)

How reproducible:

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
% ./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

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

Comment 1 Wan-Teh Chang 2001-08-01 22:33:44 UTC
The more frequent segmentation fault in __errno_location() (libc/2450) was filed
as Bugzilla bug 50661.

Comment 2 Ulrich Drepper 2003-04-22 02:02:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.