Different extension modules share space

[pearu]

BPO	521854
Nosy	@loewis
Files	py2.1-bug.tgz: TGZ file containing 4 files that demonstrate a bug in Py-2.1.2

^{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 2002-02-23.22:57:27.000>
created_at = <Date 2002-02-23.19:20:27.000>
labels = ['extension-modules']
title = 'Different extension modules share space'
updated_at = <Date 2002-02-23.22:57:27.000>
user = 'https://bugs.python.org/pearu'

bugs.python.org fields:

activity = <Date 2002-02-23.22:57:27.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2002-02-23.19:20:27.000>
creator = 'pearu'
dependencies = []
files = ['347']
hgrepos = []
issue_num = 521854
keywords = []
message_count = 2.0
messages = ['9381', '9382']
nosy_count = 2.0
nosy_names = ['loewis', 'pearu']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue521854'
versions = []

[pearu]

Hi!
I have found that if two extension modules use the same
third party
library that defines a static variable, then this
static variable is shared
in both extension modules. In real applications, this
can cause curious segmentation faults if both extension
modules are used in the same
Python script or session. Using these extension modules
in separate
session generates no problems whatsoever.
This is observed only with Python version 2.1.1 and
2.1.2.
Python 2.0 and 2.2 are free from the described
symptoms. Therefore,
it makes me argue that there are still bugs in 2.1.2
that are related to importing extension modules. I have
prepared a small example to demonstrate all this. The
example consists of 4 files: runme.py, foo.c, bar.c,
and fun.c that are attached to this report. You only
need to run runme.py.
Here are the outputs of runme.py when used with
different Python
versions:
$ python2.0 runme.py
From foo: set_var: var=0; Doing var++
From bar: set_var: var=0; Doing var++
$ python2.1 runme.py
From foo: set_var: var=0; Doing var++
From bar: set_var: var=1; Doing var++ <- note that
var=1 was set in foo
$ python2.2 runme.py
From foo: set_var: var=0; Doing var++
From bar: set_var: var=0; Doing var++
These tests are performed on Debian Woody with
gcc-2.95.4.

I appreciate if you could suggest a fix or workaround
to extension modules that are build under Python 2.1.2,
of course only if possible.
Thanks,
Pearu

[loewis]

Logged In: YES
user_id=21627

That's a bug in the Debian package. Debian uses the patch

--- python2.1-2.1.2.orig/Python/dynload_shlib.c
+++ python2.1-2.1.2/Python/dynload_shlib.c
@@ -87,7 +87,7 @@
 #ifdef RTLD_NOW
        /* RTLD_NOW: resolve externals now
           (i.e. core dump now if some are missing) */
-       handle = dlopen(pathname, RTLD_NOW);
+       handle = dlopen(pathname, RTLD_NOW | RTLD_GLOBAL);
 #else
        if (Py_VerboseFlag)
                printf("dlopen(\"%s\", %d);\n", pathname,

which results in exactly this behaviour. Please report the
bug to them; it works fine in the standard Python 2.1
distribution.

They claim that this "solves" bug debbug:97146, and that it
is a good thing to copy that strategy from Redhat. This is
foolish; the use of RTLD_GLOBAL has been stopped since
Python 1.5.2 precisely to avoid the problem you are now
seeing, and Redhat should have never changed the Python
source in that way.

Any library that relies on RTLD_GLOBAL needs to be fixed
(through exposure of CAPI objects); any application that
relies on RTLD_GLOBAL can use sys.setdlopenflags (available
since Python 2.2).