kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

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 <miguelangel@xxxxxxx> 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 <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.
>> 
>> 
>> <kicad-scripting-windows-footprint-working.jpg><pcbnew_scripting_windows.diff>_______________________________________________
>> 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
>