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

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.

Logged In: YES 
user_id=633130

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

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! 

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.

Logged In: YES 
user_id=33168

Tim, it was suggested you see this.  Is this documented
somewhere?  What should be done?

Logged In: YES 
user_id=31435

Guido should look at it -- subinterpreters were his idea 
<wink>.

Logged In: YES 
user_id=6380

No time for this now, lowering priority. If someone has a
patch, feel free to submit to SF.

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

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.