[Python-bugs-list] [ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter()

[noreply@sourceforge.net]

Bugs item #639611, was opened at 2002-11-17 10:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gernot Hillier (yoda_gh)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash (SEGV) in Py_EndInterpreter()

Initial Comment:
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();  
}  

----------------------------------------------------------------------

>Comment By: Gernot Hillier (yoda_gh)
Date: 2002-11-21 07:09

Message:
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! 

----------------------------------------------------------------------

Comment By: Gernot Hillier (yoda_gh)
Date: 2002-11-20 09:12

Message:
Logged In: YES 
user_id=633130

It really seems to have some connection with my exception handling. 
 
I'm investigating further. Please stand by... 

----------------------------------------------------------------------

Comment By: Grzegorz Makarewicz (makaron)
Date: 2002-11-18 15:00

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470