I'm starting to remember, yes, scripting/python_scripting.h:#define PY_BLOCK_THREADS(name) wxPyBlock_t name = wxPyBeginBlockThreads() scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)
We needed that blocking, because, when using wxpython, If I'm not wrong (and I use to be more often than I like), when using wxpython, the event loop is handled from python itself, that means that at any time we call most probably we're making a concurrent call to python's VM. I think that you not only fixed a bug for windows, but for a broader audience, only that other audiences where not "lucky" enough to get the into the concurrence problems, I misplaced the wxPyBeginBlockThreads, that also needed to protect other calls to python runtimes…. but ok, that's a start, I must re-investigate how that wxPython thing worked…. thanks again Brian!! :) Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On 11/03/2013, at 00:26, Miguel Angel Ajo Pelayo <[email protected]> wrote: > Awesome!, > > Brian, I'm sorry that I left that gift for you to debug. I really don't > understand the situation yet, It's supposed that > one must block the python VM thread before launching any new call into it. > All the call methods should be > surrounded by the lock, because python VM always run in a single thread, even > if you launch a thread inside, they > won't even run in parallel as the VM can't (one of biggest python failures) > > It clearly seems that also building values, or even using the Py_DECREF to > dereference a created > value needs to be locked too. > > Thanks brian, I must finish something for a deadline tomorrow (taking > longer than expected, and spent more > time on Kicad that I should have spent) but I really want to discover the > underlying reason. > > Miguel Angel Ajo > http://www.nbee.es > +34911407752 > skype: ajoajoajo > > On 10/03/2013, at 23:52, Brian Sidebotham <[email protected]> wrote: > >> Hi Guys, >> >> I have "fixed" the final issue with python scripting on Windows. I've >> attached a patch which fixes the sigsegv problem I see on Windows. >> >> I'd like to discuss it so that I can fully understand why this fixes the >> issue, or if this is simply a kludge that's putting a plaster on a bone >> break. >> >> The issue boiled down to the following code in pcbnew_footprint_wizards.cpp: >> >> /* Time to call the callback */ >> arglist = Py_BuildValue( "(i)", aPage ); >> result = CallMethod( "GetParameterPageName", arglist ); >> Py_DECREF( arglist ); >> >> There was a SIGSEGV in Py_DECREF( arglist ). In Py_DECREF() the code was >> breaking in tupledealloc() (in Objects/tupleobject.c). >> >> The specific issue was in the macro Py_TRASHCAN_SAFE_BEGIN(op) where >> PyThreadState_GET() returns NULL. The next line would SIGSEV. >> >> The PY_BLOCK_THREADS( ) and PY_UNBLOCK_THREADS( ) macro's surrounding the >> python calls appear to fix the thread state issue. >> >> I haven't had a chance to look into wxPyBeginBlockThreads() yet to see >> what's going on. >> >> The trouble is that I don't really understand what is going on. I could do >> with someone versed in python extensions explaining the use of the GIL and >> the PY_BLOCK_THREADS and PY_UNBLOCK_THREADS macros for me so I can >> understand some more. >> >> I've also attached a quick image of the footprint wizard working okay. It >> generates footprints successfully with this patch in place. So at least >> that's something positive! :D >> >> I'm interested to understand what is wrong here. Why does Linux (and >> presumably MAC) work okay without doing this? >> >> Perhaps the Windows build is broken in some other way that shouldn't be >> fixed like this? >> >> At least there is progress. >> >> Best Regards, Brian. >> >> >> <kicad-scripting-windows-footprint-working.jpg><pcbnew_scripting_windows.diff>_______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
