[ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter()
SourceForge.net
noreply at sourceforge.net
Sat Jan 8 09:52:51 CET 2005
Bugs item #639611, was opened at 2002-11-17 10:38
Message generated for change (Comment added) made by yoda_gh
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: Works For Me
Priority: 3
Submitted By: Gernot Hillier (yoda_gh)
Assigned to: Guido van Rossum (gvanrossum)
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: 2005-01-08 09:52
Message:
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.
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-08 06:19
Message:
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
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-11 22:10
Message:
Logged In: YES
user_id=6380
No time for this now, lowering priority. If someone has a
patch, feel free to submit to SF.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2002-12-31 22:35
Message:
Logged In: YES
user_id=31435
Guido should look at it -- subinterpreters were his idea
<wink>.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 14:19
Message:
Logged In: YES
user_id=33168
Tim, it was suggested you see this. Is this documented
somewhere? What should be done?
----------------------------------------------------------------------
Comment By: Grzegorz Makarewicz (makaron)
Date: 2002-11-21 10:31
Message:
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.
----------------------------------------------------------------------
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
More information about the Python-bugs-list
mailing list