clone 416031 -1 reassign -1 epiphany-browser severity -1 important thanks On Sat, Mar 24, 2007 at 09:51:18AM +0100, Mike Hommey <[EMAIL PROTECTED]> wrote: > Package: python-xpcom > Version: 1.8.0.10-3 > Severity: critical > Justification: breaks unrelated software > > When python-xpcom is installed, epiphany crashes whenever a python > extension for epiphany is used.
So, I dug a bit into this issue and found out the problem seems to be on epiphany's end. I'll however put a conflict in next xulrunner upload, which was already planned, that will avoid an upload of epiphany to add this conflict for etch. I'll leave the conflict until the clone bug is fixed in ephy. Now, as for my investigations: The backtrace appears as follows: #0 0xb719e42a in PySys_GetObject (name=0xb71cf0ca "path") at ../Python/sysmodule.c:52 #1 0xb719fd5e in PySys_SetArgv (argc=1, argv=0xbfe4b09c) at ../Python/sysmodule.c:1182 #2 0x0811cf5e in ephy_python_init () ../Python/sysmodule.c:52 is: PyObject *sd = tstate->interp->sysdict for which it appears that tstate, set on ../Python/sysmodule.c:51, is NULL. ../Python/sysmodule.c:51 is: PyThreadState *tstate = PyThreadState_GET(); where PyThreadState_GET is a macro for _PyThreadState_Current. Now, looking into what python xpcom does, it appears it releases the python thread state when it is done with python work, in which case _PyThreadState_Current is set to NULL. And it makes sure the python thread state is correcly set when it needs to use python. These are done with PyGILState_Ensure and PyGILState_Release functions. This means that by the time epiphany gets into python initialization, _PyThreadState_Current is NULL... It seems like the Ensure/Release cycles are necessary in cases like this one, where the python interpreter is used in several places in the same address space. Adding PyGILState_STATE state; state = PyGILState_Ensure(); PyGILState_Release(state); into the correct places in ephy_python_init() did indeed make the crash disappear from ephy_python_init(), and happen later. But I actually wonder if it should not be necessary to create a new thread state. In which case, it should be necessary to do the same in pyxpcom, because it doesn't create its own thread state. But maybe I'm just saying crap, I don't know much about the python API... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
