| msg13319 - (view) |
Author: Gernot Hillier (yoda_gh) |
Date: 2002-11-17 09:38 |
| I experience a 80% reproducable SIGSEGV in a multithreaded app I wrote using different embedded sub interpreters in its threads. I have a C++ class (PClass) which encapsulates the sub-interpreters somehow - it creates a new one in its constructor and deletes it in the destructor (see below). When 2 objects of this class are destroyed at nearly the same time thus resulting in subsequent calls to Py_EndInterpreter() (but for the different threads), I get the following SIGSEGV in most cases: > gdb application core.31889 [...] Program terminated with signal 11, Segmentation fault. [...] Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 169 _PyObject_GC_UNTRACK(op); (gdb) bt #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 #1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at Python/pystate.c:190 #2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at Python/pystate.c:77 #3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at Python/pythonrun.c:381 #4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123 When the 2nd object is destroyed some seconds later, everything seems to be fine. It only crashes when the 2 objects are deleted within a short period of time. I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built Python-2.2.2 with the same result. :-( Here's a very short snippet of the python related code in my class: // Constructor, initializes Python sub-interpreter PClass::PClass() { PyEval_AcquireLock(); py_state=Py_NewInterpreter(); PyEval_SaveThread(); } // destructor, kills the Python sub-interpreter PClass::~PClass() { PyEval_RestoreThread(py_state); Py_EndInterpreter(py_state); py_state=NULL; PyEval_ReleaseLock(); // release lock } // thread code, runs Python function void PClass::run() { PyEval_RestoreThread(py_state); PyObject_CallFunction(...) PyEval_SaveThread(); } |
|
|
| msg13320 - (view) |
Author: Grzegorz Makarewicz (makaron) |
Date: 2002-11-18 14:00 |
| Logged In: YES user_id=115179 I have found it (perhaps), while an python exception is pending and PyEval_RestoreThread is called, my Python anwalys bumps. After adding PyErr_Clear or PyErr_Print just before this call makes python happy. |
|
|
| msg13321 - (view) |
Author: Gernot Hillier (yoda_gh) |
Date: 2002-11-20 08:12 |
| Logged In: YES user_id=633130 It really seems to have some connection with my exception handling. I'm investigating further. Please stand by... |
|
|
| msg13322 - (view) |
Author: Gernot Hillier (yoda_gh) |
Date: 2002-11-21 06:09 |
| Logged In: YES user_id=633130 Ok, after cleaning up my exception handling a little bit (especially preventing exceptions to be triggered from outside after run() has finished) I can't reproduce the problems any more. So the bug is worked around for me. I leave it open if you consider this to be a real bug which has to be fixed. If you don't fix it and an user must always call PyErr_Clear() before Py_EndInterpreter() this should be documented IMHO. TIA! |
|
|
| msg13323 - (view) |
Author: Grzegorz Makarewicz (makaron) |
Date: 2002-11-21 09:31 |
| Logged In: YES user_id=115179 I think it should be documented and additional check performed before killing thread state or interpereter. Leave it open - Tim Peters should see this. |
|
|
| msg13324 - (view) |
Author: Neal Norwitz (nnorwitz) *  |
Date: 2002-12-31 13:19 |
| Logged In: YES user_id=33168 Tim, it was suggested you see this. Is this documented somewhere? What should be done? |
|
|
| msg13325 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2002-12-31 21:35 |
| Logged In: YES user_id=31435 Guido should look at it -- subinterpreters were his idea . |
|
|
| msg13326 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2003-02-11 21:10 |
| Logged In: YES user_id=6380 No time for this now, lowering priority. If someone has a patch, feel free to submit to SF. |
|
|
| msg13327 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2005-01-08 05:19 |
| Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo |
|
|
| msg13328 - (view) |
Author: Gernot Hillier (yoda_gh) |
Date: 2005-01-08 08:52 |
| Logged In: YES user_id=633130 Hmm, I'm quite sorry, but I changed my application quite thoroughly in the meantime and never ever experienced any problem again - and the application is widely used in the meantime. I also can't really remember what I've changed in the "workaround" of 2002-11-21 07:09. I could try to find these details if someone is really interested in my old archives, but if not, I'll consider this as fixed/"works for me" now. |
|
|