Message140986
| Author |
neologix |
| Recipients |
landry, neologix, pitrou, rpetrov, rpointel |
| Date |
2011年07月23日.13:38:55 |
| SpamBayes Score |
2.3367555e-09 |
| Marked as misclassified |
No |
| Message-id |
<CAH_1eM3CP-8WYqAMWEh6d-pF8sCyRLdTU=rw1Wx-O0qWV2EtTA@mail.gmail.com> |
| In-reply-to |
<1311374141.24.0.917737373224.issue12588@psf.upfronthosting.co.za> |
| Content |
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. |
|