Mesa with NPTL makes Python extensions crash with std::cerr

[alanic7]

BPO	1730372
Nosy	@tiran, @bitdancer
Files	spam.cc: example program from referenced thread

^{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 2011-12-23.11:50:40.586>
created_at = <Date 2007-06-03.20:35:41.000>
labels = ['extension-modules', 'invalid']
title = 'Mesa with NPTL makes Python extensions crash with std::cerr'
updated_at = <Date 2011-12-23.11:50:40.551>
user = 'https://bugs.python.org/alanic7'

bugs.python.org fields:

activity = <Date 2011-12-23.11:50:40.551>
actor = 'neologix'
assignee = 'none'
closed = True
closed_date = <Date 2011-12-23.11:50:40.586>
closer = 'neologix'
components = ['Extension Modules']
creation = <Date 2007-06-03.20:35:41.000>
creator = 'alanic7'
dependencies = []
files = ['13465']
hgrepos = []
issue_num = 1730372
keywords = []
message_count = 7.0
messages = ['32196', '32197', '59360', '59370', '84505', '116685', '150155']
nosy_count = 6.0
nosy_names = ['nnorwitz', 'christian.heimes', 'alanic7', 'r.david.murray', 'neologix', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1730372'
versions = ['Python 2.6', 'Python 2.7']

[alanic7]

When Mesa is built with NPTL support, Python extensions linked to libGL
segfault when std::cerr is used. Please see the following thread for
descriptions, details and sample programs:

http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470

[nnorwitz]

I can't reproduce this error on head with Ubuntu Linux/amd64 gcc 4.1.2. What are the platform details? OS, compiler, etc.

$ gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -I/usr/include -I/usr/local/include -I./Include -I. -c ../spam.cc -o spam.o
$ gcc -pthread -shared spam.o -L/usr/lib64 -L/usr/local/lib -Wl,-R/usr/lib64 -ldb-4.4 -o build/lib.linux-x86_64-2.6/spam.so -lstdc++
$ ./python
>>> import spam
>>> spam.system('ls')
this be cerr
big5.py               __db.003    libpython2.6.a   Objects        python-clean
build                 __db.004    LICENSE          Parser         python-fast
config.log            __db.005    log.0000000001   PC             README
config.status         Demo        Mac              PCbuild        RISCOS
config.status.lineno  Doc         Makefile         PCbuild8       setup.py
configure             Grammar     Makefile.pre     pyconfig.h     Tools
configure.in          Include     Makefile.pre.in  pyconfig.h.in
__db.001              install-sh  Misc             python
__db.002              Lib         Modules          Python
0

[tiran]

Please provide a failing test program or we have to close the bug. I
can't reproduce it on my x86 machine with Python 2.5 and GCC 4.2 either.

[alanic7]

If by not being able to reproduce, you mean that you campiled Mesa
with NPTL support and tried a Python extension that's using std::cerr
(like the attached source in the other thread I linked to) and is
linked to -lGL, then fine.

Mesa with NPTL support is compiled with

# Add '-DGLX_USE_TLS' to ARCH_FLAGS to enable TLS support.

as quoted from configuration files in config/ directory of Mesa source
tree.

I use Gentoo, if you believe it matters.

[bitdancer]

I compiled the referenced test program on Gentoo, where my Mesa library
is compiled with NPTL:

rdmurray@partner:~>equery uses mesa
[ Searching for packages matching mesa... ]
[ Legend : Left column (U) - USE flags from make.conf ]
[ : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for media-libs/mesa-7.3 ]
U I
<snip>
+ + nptl

gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-I/usr/include -I/usr/local/include -I./Include -I. -c spam.cc -o spam.o
gcc -pthread -shared spam.o -L/usr/lib -L/usr/local/lib -Wl,-R/usr/lib
-lGL -o build/lib.linux-i686-2.7/spam.so -lstdc++
rdmurray@partner:~/python/trunk>strings build/lib.linux-i686-2.7/spam.so
|grep -i libgl
libGL.so.1
>./python
Python 2.7a0 (unknown, Mar 29 2009, 16:10:14) 
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import spam
>>> spam.system('ls')
this be cerrzsh: segmentation fault  ./python

Without the '-lGL' it works fine.

Now, is it a bug in Python, or Mesa?

I haven't checked if it is still a problem in py3k since spam.cc
does not compile cleanly under py3k.

[BreamoreBoy]

Could a Linux guru try to reproduce this with the latest trunk, thanks.

[neologix]

I assume this was due to the following bug:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
http://lists.freedesktop.org/archives/mesa-dev/2011-March/006180.html

In short, MESA didn't use the correct TLS model for thread-local variables, which ended up in some libstdc++ thread-local variables not being initialized when called from a dynamically loaded libraries (such as spam).

I couldn't reproduce the problem on Debian testing (which has a mesa version containing the patch posted on mesa-dev).