This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: RedHat 9 blows up at dlclose of pyexpat.so
Type: Stage:
Components: Extension Modules Versions: Python 2.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: aleax, anthonybaxter, benson_basis, loewis
Priority: normal Keywords:

Created on 2003-09-29 20:55 by benson_basis, last changed 2022-04-10 16:11 by admin. This issue is now closed.

Messages (9)
msg18441 - (view) Author: benson margulies (benson_basis) Date: 2003-09-29 20:55
With python 2.3, built with GCC 3.2.

With RedHat 9.0 ... glibc-2.3.2-27.9

With python linked into the application as a shared 
library...

a SIGSEGV at exit. Perhaps the modules should be 
marked -z nodelete to duck this latest incarnation of an 
old familiar glibc bug?

atexit:

(gdb) where
#0  0x42073771 in free () from /lib/tls/libc.so.6
#1  0x420ebd8e in __unregister_atfork () 
from /lib/tls/libc.so.6
#2  0x42029fb8 in __cxa_finalize () 
from /lib/tls/libc.so.6
#3  0x41fd19fc in __do_global_dtors_aux () 
from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so
#4  0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72-
gcc-3.2/python/pyexpat.so
#5  0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2
#6  0x42029d40 in exit () from /lib/tls/libc.so.6
#7  0x42015708 in __libc_start_main () 
from /lib/tls/libc.so.6
msg18442 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-10-03 13:33
Logged In: YES 
user_id=21627

This sounds like a bug in the system to me, not a bug in Python.

Maybe it can be worked-around by not building Python with g++?

Maybe it can be worked-around by not using buggy TLS
implementations?
msg18443 - (view) Author: benson margulies (benson_basis) Date: 2003-10-03 13:37
Logged In: YES 
user_id=876734

If this is a system bug, it's a glibc bug, not a gcc bug. So 
avoiding gcc won't help. RedHat/glibc have a very bad track 
record of exploding when dlclosing C++ shared libraries. 
They've had many bugs of this form. If pyexpat has to have 
C++ code, it should be coded with no static constructor 
usage to avoid this problem, and similiar problems that might 
arise other places. TLS isn't in action.
msg18444 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-10-03 14:14
Logged In: YES 
user_id=21627

I did not suggest to avoid gcc, but to avoid g++ (I'm only
guessing here, since you haven't reported the build log, ldd
output for pyexpat.so, or similar - but it might be that
pyexpat.so was linked with g++, which would explain that it
somehow calls __cxa_finalize).

pyexpat itself has no C++ in it.
msg18445 - (view) Author: benson margulies (benson_basis) Date: 2003-10-03 14:15
Logged In: YES 
user_id=876734

I didn't realize that the decision to use g++ as the linker was 
one that we made here locally (I didn't do the build). We'll try 
avoiding it and see if things get better.
msg18446 - (view) Author: Anthony Baxter (anthonybaxter) (Python triager) Date: 2003-10-04 00:26
Logged In: YES 
user_id=29957

configure --without-cxx 
is the magic you probably want.
msg18447 - (view) Author: Alex Martelli (aleax) * (Python committer) Date: 2003-11-02 20:01
Logged In: YES 
user_id=60314

any news on this, i.e., does the --without-cxx solve everything?  Just seeing if the bug can be marked as closed...
msg18448 - (view) Author: benson margulies (benson_basis) Date: 2003-11-21 14:49
Logged In: YES 
user_id=876734

The suggested solution (--without-cxx) did the job.
msg18449 - (view) Author: Anthony Baxter (anthonybaxter) (Python triager) Date: 2003-11-22 06:42
Logged In: YES 
user_id=29957

Closing as not a bug.
History
Date User Action Args
2022-04-10 16:11:29adminsetgithub: 39334
2003-09-29 20:55:10benson_basiscreate