kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

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.

Attachment: kicad-scripting-windows-footprint-working.jpg
Description: JPEG image

Attachment: pcbnew_scripting_windows.diff
Description: Binary data