RedHat 9 blows up at dlclose of pyexpat.so

[bensonbasis]

BPO	814726
Nosy	@loewis, @aleaxit

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2003-11-22.06:42:38.000>
created_at = <Date 2003-09-29.20:55:10.000>
labels = ['extension-modules']
title = 'RedHat 9 blows up at dlclose of pyexpat.so'
updated_at = <Date 2003-11-22.06:42:38.000>
user = 'https://bugs.python.org/bensonbasis'

bugs.python.org fields:

activity = <Date 2003-11-22.06:42:38.000>
actor = 'anthonybaxter'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2003-09-29.20:55:10.000>
creator = 'benson_basis'
dependencies = []
files = []
hgrepos = []
issue_num = 814726
keywords = []
message_count = 9.0
messages = ['18441', '18442', '18443', '18444', '18445', '18446', '18447', '18448', '18449']
nosy_count = 4.0
nosy_names = ['loewis', 'aleax', 'anthonybaxter', 'benson_basis']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue814726'
versions = ['Python 2.3']

[bensonbasis]

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

[loewis]

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?

[bensonbasis]

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.

[loewis]

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.

[bensonbasis]

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.

[anthonybaxter]

Logged In: YES
user_id=29957

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

[aleaxit]

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

[bensonbasis]

Logged In: YES
user_id=876734

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

[anthonybaxter]

Logged In: YES
user_id=29957

Closing as not a bug.