this could benefit from advice of a CPython hacker :) On 17/04/13 09:33, Stephan Bergmann wrote: > On 04/15/2013 03:34 PM, Michael Stahl wrote: >> with commit f14f7a2e4568e3e85a0c8860beebd0376c5a8b51 MSVC builds will >> link everything against the debug runtimes (MSVCRTD etc.), which enables >> debug STL and other things. > [...] >> the MSVC one is tested on MSVC 2008 only, where "make check" passes >> successfully; it's possible that i've overlooked something in the >> makefiles where different MSVC versions use different rules, so it needs >> somebody to try it out in an --enable-dbgutil build with 2010 and 2012. > > You probably did that "make check" on a build without any bundled Python > extensions, right? In my heavily --enable-ext-* configured build, > starting soffice instantly fails with > >> Fatal Python error: Invalid thread state for this thread >> >> Current thread 0x00000260: >> >> Thread 0x00000260:
after enabling some Python extensions (i was actually unaware that my MSVC build was without dictionaries since they started defaulting to disabled...), i can reproduce the problem. [ the Py_FatalError function calls abort() which then causes your other assertion/dialog from operator delete (somehow). ] the "invalid thread state" is apparently caused by the PyThreadAttach / PyThreadDetach classes in PyUno, which are both RAII style guard classes. the PyThreadAttach will create a new PyThreadState with PyThreadState_New and call PyEval_AcquireThread in its ctor, and PyEval_ReleaseThread and PyThreadState_Delete in its dtor. PyThreadDetach does the inverse, calling PyEval_ReleaseThread in the ctor and PyEval_AcquireThread in the dtor. now it may happen that a single OS thread does multiple independent calls into PyUno, for example a call into a Python UNO component, which calls a C++ UNO component, which in turn calls a Python UNO component. in this case we get multiple PyThreadState for the same OS thread, because multiple PyThreadAttach objects are on the C stack (with PyThreadDetach between them). this is apparently what the assertion in PyThreadState_Swap that is triggered here complains about: it checks that the value of PyGILState_GetThisThreadState(), which essentially is a thread-local variable holding the last PyThreadState that was used on the current OS thread, is the same as the PyThreadState that is passed in. now i think we could ensure that this is the case in PyUno, by storing the PyThreadState in a thread-local variable in PyThreadAttach so that one OS thread only uses one PyThreadState. but i have doubts that this actually makes sense - this PyThreadState apparently contains things like pending exceptions, and i'm concerned that if the "inner" Python evaluation would use these that they could confuse the "outer" Python evaluation when control returns to it. the other alternative that i see is to simply patch out the check in PyThreadState_Swap; the _other_ checks in PyEval_*Thread functions and RAII nature of the guard classes should hopefully prevent ~all of the potential errors. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
