kicad-developers team mailing list archive
Mailing list archive
Re: Scripting on Windows Fix
I'm starting to remember, yes,
scripting/python_scripting.h:#define PY_BLOCK_THREADS(name) wxPyBlock_t name = wxPyBeginBlockThreads()
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
On 11/03/2013, at 00:26, Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx> wrote:
> 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
> skype: ajoajoajo
> On 10/03/2013, at 23:52, Brian Sidebotham <brian.sidebotham@xxxxxxxxx> 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.
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp