On Friday 13 June 2008 10:54:47 am Arve Knudsen wrote: > Hi > > I'm still having problems with SIP's exception handling support, using > SIP snapshot 20080612). When an exception from my wrapped C++ code is > caught, SIP triggers an error in the Python API (PyEval_SaveThread: > NULL tstate), The relevant backtrace looks as follows: > > #3 0xb6854968 in Py_FatalError () from /usr/lib/libpython2.5.so.1.0 > #4 0xb682cad5 in PyEval_SaveThread () from /usr/lib/libpython2.5.so.1.0 > #5 0xb2627b69 in release_QString (sipCppV=0x825e3c0) at > sipQtCorepart1.cpp:16116 > #6 0xb279c2db in release (addr=0x825e3c0, td=0xb27813a0, state=1) at > siplib.c:5651 > #7 0xb279c299 in sip_api_release_instance (cpp=0x825e3c0, > type=0x8495354, state=1) at siplib.c:5633 > #8 0xb2503186 in meth_BuildProject2_loadProject (sipArgs=0x854f9cc) > at sip_wrapperBuildProject2.cpp:669 > > AFAICT the problem is that outside the try block there is a call to > Py_BEGIN_ALLOW_THREADS, which releases the GIL? Then, first thing > after the exception is caught, an QString is released (a parameter to > the wrapped method). As part of releasing the QString, in > release_QString, Py_BEGIN_ALLOW_THREADS is called again, which is not > allowed since the GIL is not being held, right?
Can you send me the generated code so that I can see the logic. > >From what I understand there is a simpler alternative to > > Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in the API: > PyGILState_Ensure/PyGILState_Release. Could SIP make use of these > functions instead? They are not alternatives. One pair frees the GIL for a period, the other acquires the GIL for a period. Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
