[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[Irit Katriel]

Change by Irit Katriel :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[Irit Katriel]

Irit Katriel  added the comment:

IIUC:

(1) 2.7 is well past its EOL date, so it's not clear whether this issue is 
still there. 

(2) mingw is not supported and distutils is deprecated, so it's not clear if 
it's relevant.

(3) it was, to begin with, a documentation issue and it was not clear where 
this point should be documented.


If there won't be any objections, I will close this.

--
nosy: +iritkatriel
resolution:  -> third party
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[R. David Murray]

R. David Murray added the comment:

Well, clearly you are the interested party that solved it :)  Thanks.

Unfortunately I don't know that we have a place where this could be documented, 
since currently mingw isn't a fully supported platform.  Perhaps in the 
distutils docs somewhere?

--
assignee:  - docs@python
components: +Documentation
nosy: +docs@python
type: crash - 

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23743
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[Steve Dower]

Steve Dower added the comment:

I think these days as soon as a repro includes import distutils or import 
setuptools the docs go straight to http://pypa.io :)

--
nosy: +ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23743
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[Nick Coghlan]

Nick Coghlan added the comment:

pypa.io hosts the internal dev docs for PyPA, I believe you meant 
packaging.python.org, and that would indeed be the right home.

However, this kind of C/C++ linker related problem is way too advanced for the 
current state of the binary extension docs which basically say C/C++ is hard 
relative to Python, let someone else deal with creating your extension modules 
for you: https://packaging.python.org/en/latest/extensions.html

For the scientific stack in particular we go even further and say to get 
someone else to build and link the extension modules for you: 
https://packaging.python.org/en/latest/science.html

Folks encountering the kind of problem described in this issue is thus mostly 
useful as a data point in *why* we give those instructions: because DIY 
cross-platform C/C++ development is a teeming morass of fun interoperability 
bugs like this one just waiting to be discovered :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23743
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[R. David Murray]

R. David Murray added the comment:

Oh, I'm afraid it can still be ignored :).  What filing it here means is that 
it won't be *forgotten*, and hopefully there will eventually be someone with 
the time and interest to address it.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23743
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[matham]

matham added the comment:

Well, we won't have to wait until interested solves it. After hours of 
debugging including compiling Python with VS2013 and looking at windows dump 
files, it seems that hard work pays off - sorry, I mean asking someone who 
knows the answer pays off :P.

I asked on #mingw and it was suggested that I use mingw compiled with the SJLJ 
exception model. And indeed, using sjlj fixed this so that it does not crash 
anymore. It seems that mingw from mingw.org compiles with 
`--disable-sjlj-exceptions`, so one has to use mingw-w64's distribution which 
offers a sjlj build (for x86 and SEH for x64).

I am wondering whether this information should be somewhere on the python 
website so that other people do not run into this issue. I'm not sure what the 
proper resolution is here so I'll live it open. Or maybe it should be open 
until the docs is updated to warn about this issue.

Anyway, here's the pertinent parts of my #mingw chat:

jon_y matham: I suggest going for SJLJ on 32bit
jon_y SEH on 64bit
jon_y avoid dw2 exception like the plague
matham ok, the one I got from mingw-get says --disable-sjlj-exceptions 
--with-dwarf2
matham I'll try with sjlj
matham from mingw-w64
matham jon_y, \o/\o/\o/\o/\o/\o/\o/ omg I'm so happy :D it looks like using 
sjlj fixed it
jon_y matham: I mean --disable-sjlj-exceptions
jon_y that is the C++ exception part
jon_y dwarf2 as debug is fine
jon_y --with-dwarf2 specifies the debug data format
jon_y yeah, dw2 (when --disable-sjlj-exceptions is used) has lots of issues 
with python
matham so the problem is when sjlj is disabled?
matham I thought it was either/or with sjlj vs dw2
jon_y dw2 doesn't quite work right for windows
jon_y it requires ALL dll code use the same shared libgcc dll
jon_y failure to do so leads to random crashes, especially during program 
termination
matham so why does mingw-get automatically do --disable-sjlj-exceptions?
jon_y mingw.org only provides toolchain that uses dw2 exceptions
jon_y this has been so ever since the 4.2.1 days
jon_y (that was the first widely used Windows gcc 4.x version)
jon_y matham: Cygwin had the same problem with python and their dw2 gcc 
recently
jon_y but had some local patches done in to fix it

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23743
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod

[matham]

New submission from matham:

I have encountered a situation where python crashes when python exits if one 
imports a c compiled extension followed by a cpp compiled extension (but not if 
imported in the reverse order). This is on windows with mingw (current using 
mingw-get install gcc g++ msys-make) and py2.7.9.

This is basically the issue reported at 
https://mail.python.org/pipermail/python-win32/2013-April/012798.html a while 
back by someone else, but I'm filing it in bug form so it can't be ignored :D

Here's how to replicate it:

cplayground.c:

#include Python.h

static PyObject*
say_hello(PyObject* self, PyObject* args)
{
Py_RETURN_NONE;
}

static PyMethodDef HelloMethods[] =
{
 {say_hello, say_hello, METH_VARARGS, Greet somebody.},
 {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC
initcplayground(void)
{
 (void) Py_InitModule(cplayground, HelloMethods);
}


cplayground.cpp:

#include Python.h

static PyObject*
say_hello(PyObject* self, PyObject* args)
{
Py_RETURN_NONE;
}

static PyMethodDef HelloMethods[] =
{
 {say_hello, say_hello, METH_VARARGS, Greet somebody.},
 {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC
initcppplayground(void)
{
 (void) Py_InitModule(cppplayground, HelloMethods);
}


setup.py:

from distutils.core import setup
from distutils.extension import Extension
import Cython.Compiler.Options
from Cython.Distutils import build_ext
from os.path import join, sep, dirname, abspath

def get_extensions_from_sources():
ext_modules = []
ext_modules.append(Extension('src.cplayground', 
sources=['src/cplayground.c']))
ext_modules.append(Extension('src.cppplayground', 
sources=['src/cplayground.cpp']))
return ext_modules

setup(
name='Playground',
version='.1',
author='Matthew Einhorn',
ext_modules=get_extensions_from_sources(),
cmdclass={'build_ext': build_ext},
packages=['src']
  )


Here's a demonstration of the issue:

G:\Python\libs\Playground\srcpython
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type help, copyright, credits or license for more information.
 import cplayground
 import cppplayground
 exit()

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

G:\Python\libs\Playground\srcpython
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type help, copyright, credits or license for more information.
 import cppplayground
 import cplayground
 exit()

Here's my config:

G:\Python\libs\Playground\srcgcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

G:\Python\libs\Playground\srcg++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

--
components: Extension Modules, Windows
messages: 238981
nosy: matham, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python crashes upon exit if importing g++ compiled mod after importing 
gcc compiled mod
type: crash
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23743
___
___
Python-bugs-list mailing list