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
