[Python-bugs-list] [ python-Bugs-521854 ] Different extension modules share space

[noreply@sourceforge.net]

Bugs item #521854, was opened at 2002-02-23 11:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521854&group_id=5470

Category: Extension Modules
Group: Python 2.1.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Pearu Peterson (pearu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different extension modules share space

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

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-02-23 14:57

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

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

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