Bug 146786 - crash in pthread_exit() (tls version) when using new and -rdynamic flag
crash in pthread_exit() (tls version) when using new and -rdynamic flag
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-01 11:54 EST by Gerard Nantel
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-07 15:47:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Sample program that reproduces the issue. (718 bytes, text/plain)
2005-02-01 11:56 EST, Gerard Nantel
no flags Details

  None (edit)
Description Gerard Nantel 2005-02-01 11:54:53 EST
Description of problem:
I am observing a crash in pthread_exit() on ES 3.0 when running a 
binary compiled on RH 7.2.

Stack trace:
#0  0xbf7ebc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xbf6a8a09 in raise () from /lib/tls/libc.so.6
#2  0xbf6aa235 in abort () from /lib/tls/libc.so.6
#3  0xbee78f61 in __frame_state_for () from /lib/libgcc_s.so.1
#4  0xbee79393 in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1
#5  0xbf7e52a4 in _Unwind_ForcedUnwind () 
from /lib/tls/libpthread.so.0
#6  0xbf7e3486 in __pthread_unwind () from /lib/tls/libpthread.so.0
#7  0xbf7dfae2 in pthread_exit () from /lib/tls/libpthread.so.0
#8  0x0804a5a0 in Thread(void*) ()

C++ source code for binary:
See sample.cpp attachment.

Compile System:
Red Hat Linux release 7.2 (Enigma)
Kernel 2.4.7-10smp on an i686

Compiler version:
gcc-3.2.2 (configured with --enable-languages=c++ --enable-
threads=posix --with-pic --disable-shared)
(Also tried gcc-3.4.3 configured the same way)

Compile command:
g++ sample.cpp -rdynamic -lpthread -o sample

Running the sample on RH 7.2 works fine.  Running the sample on RH ES 
3.0 causes the above-mentioned crash.

- Note the -rdynamic flag.  Without this flag, the crash goes away.
- Note that the sample program contains a call to new.  Without a 
call to new, the crash goes away.  Moving the call to new around 
(global scope, Thread() scope, main() scope at begin/end) doesn't 
change a thing.
- As expected, without the call to pthread_exit(), the crash also 
goes away.

Test system:
Red Hat Enterprise Linux ES release 3 (Taroon)
Kernel 2.4.21-4.ELsmp on an i686

Test system pthread library:
/lib/tls/libpthread.so.0 (as can be seen from stack trace)

Note that if /lib/i686/libpthread.so.0 is used instead, there is no 
crash.

How reproducible:
Every Time.

Steps to Reproduce:
1. Compile attached sample.cpp on RH 7.2 using gcc 3.2.2 or 3.4.3 
with command: "g++ sample.cpp -rdynamic -lpthread -o sample"
2. Run sample on RH ES 3.0 making sure that it is linking 
against /lib/tls/libpthread.so and not /lib/i686/libpthread.so
  
Actual results:
The sample binary crashed.

Expected results:
The sample binary should have exited normally.

Additional info:
Comment 1 Gerard Nantel 2005-02-01 11:56:40 EST
Created attachment 110501 [details]
Sample program that reproduces the issue.
Comment 2 Gerard Nantel 2005-02-02 11:15:41 EST
Setting LD_ASSUME_KERNEL=2.4.19 (or 2.2.5) on the RH ES 3.0 machine 
also makes the crash go away.
Comment 3 Jakub Jelinek 2005-02-07 15:47:34 EST
That's a bug in RHL 7.2, not RHEL 3.  It was incorrectly marking pthread_exit
(among other functions) as throw (), while they in fact can throw.

Either use LinuxThreads for RHL7.2 compiled C++ programs, or build on RHEL3+,
or fix RHL 7.2 headers so that they don't have throw () on their prototypes.
The fix was
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/sysdeps/pthread/pthread.h.diff?r1=1.34&r2=1.35&cvsroot=glibc

As RHL 7.2 is no longer supported, there is nothing else that can be done about
this.

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