#1370 Not safe to use SwigPyIterator while using the 'threads' option

[jicks]

While following the example in the SWIG documentation to access the STL/C++ Library from Python (with the multi-threading activated), I've had weird segfaults.

Attached is the reduced testcase that trigger the issue.

The problem arises when the destructor of SwigPyIterator is called: its wrapper releases the GIL and store the current thread state (SWIG_PYTHON_THREAD_BEGIN_ALLOW) before actually deleting the object. As it has a SwigPtr_PyObject member, the destruction of this member calls the Python GC.
However, since we don't hold the GIL nor have a valid thread state, calling Py_DECREF fails.

We currently have found a way to bypass this: we manually (the patch is attached) force the destruction of the SwigPtr_PyObject after asking for the GIL (SWIG_PYTHON_THREAD_BEGIN_BLOCK).

I've reproduced this bug on SWIG 2.0.3 and 3.0.0 on Fedora14 and Mac OS X (10.9.2).

Attachements:

• swig.patch contains the patch we currently apply to avoid this issue;
• test.i contains the reduced testcase;
• real_test.py is a small Python script that triggers the issue.

[Olly Betts]

Looks like this was fixed in SWIG 3.0.3 - from CHANGES:

2014-09-23: wsfulton
            [Python] Add patch from Thomas Maslach to fix crash in wrappers when using -threads in
            the STL iterators (SwigPyIterator destructor).

Closing. If you still get problems, please open a new issue in the github tracker with details.