[ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so

[SourceForge.net]

Bugs item #814726, was opened at 2003-09-30 06:55
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Nobody/Anonymous (nobody)
Summary: RedHat 9 blows up at dlclose of pyexpat.so

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-11-22 17:42

Message:
Logged In: YES 
user_id=29957

Closing as not a bug.


----------------------------------------------------------------------

Comment By: benson margulies (benson_basis)
Date: 2003-11-22 01:49

Message:
Logged In: YES 
user_id=876734

The suggested solution (--without-cxx) did the job.


----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2003-11-03 07:01

Message:
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...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-04 10:26

Message:
Logged In: YES 
user_id=29957

configure --without-cxx 
is the magic you probably want.


----------------------------------------------------------------------

Comment By: benson margulies (benson_basis)
Date: 2003-10-04 00:15

Message:
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.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-10-04 00:14

Message:
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.

----------------------------------------------------------------------

Comment By: benson margulies (benson_basis)
Date: 2003-10-03 23:37

Message:
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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-10-03 23:33

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470