Hello,
I have embedded Python into and extended it with functionality from a
graphical tool I use. One of the things it allows me to do is to
export Python objects to a simple scripting language ("ascanf"), and
call them as if they were native functions.
I have the following situation in which I get a systematic
segmentation violation in Py_EnterRecursiveCall(), in Python 2.4 2.5
and 2.6 (OS X) and on Cygwin with 2.5 and 2.6 .
I enter an interactive Python 'console' from within my application,
either the one from the interact package, or the IPython shell. My
application has a callback defined for the readline routines that
calls the graphical event handler, allowing for instance
refresh/redraws to continue while working in the Python console. The
crash occurs when during such events handled through the readline
callback, I call an exported Python object. This does not appear to be
related to recursion per se, but rather to "calling a python
interpreter behind the back of the currently active
console/interpreter".
To be clearer, suppose I have some Python code
def Py_travDistCalc(a,b,c):
...
return x
ascanf.ExportVariable("travDistCalc", Py_travDistCalc )
I can then issue a call
1) travDistCalc[a,b,c] from an ascanf script.
2) ascanf.Eval( 'travDistCalc[a,b,c]' ) from the Python console
Call 1) provokes a crash in Py_EnterRecursiveCall() when invoked
through the readline callback when the Python console is open, but
call 2) succeeds normally.
Note that this is a single-threaded application.
My workaround is to keep track of the readline callback recursion
level, and compare the current level with the level recorded when
entering a Python console before doing the PyObject_CallObject()
required in call 1) and 2) above.
In Python 2.3, the Py_xxxRecursiveCall functions are missing, but I
also get a crash, so I guess I'm doing something really nasty.
I'm not sure if this is a bug in Python. It is the sort of crash
situation I'd try to avoid, though.
--
http://mail.python.org/mailman/listinfo/python-list
