Charles-François Natali <neolo...@free.fr> added the comment: and Darwin).
It would have been useful... """ interp 0x0, thread state 0x81855380: Program received signal SIGSEGV, Segmentation fault. """ Here, the interpreter state is NULL, and this shouldn't happen. It could be a bug linked to thread-local storage (like issue #10517): it's just a wild guess, but if for some reason the TLS key isn't reset before the second pass (by _PyGILState_Init()), the current tstate after PyGILState_Ensure() could be the first pass' - stale - tstate, with a potentially NULL interp. Could you try building Python with --with-pydebug and re-test? But given the stack trace, it looks more like a stack corruption/compiler problem. If you're motivated, you could try setting a watchpoint on the current tstate's interpreter: """ cf@neobox:~/cpython$ gdb Modules/_testembed [...] (gdb) watch ((PyThreadState*)_PyThreadState_Current)->interp Watchpoint 1: ((PyThreadState*)_PyThreadState_Current)->interp """ and see when it gets assigned NULL. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12588> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
