kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

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