Sometimes the GC just won't run the finalizers, so we output a warning
instead of throwing an error, so now the test-suite will pass but with a
warning if the number of objects is not as expected.
Was notably failing on RHEL6 using OpenSUSE build testing with openjdk-1.6
* python-builtin-test-suite:
Add Python -builtin Travis testing
Bypass Python exmples not supported by -builtin
Remove Python swigrun example
Display testname when running the import_packages Python examples
Fix Python 3 import_packages/relativeimport2 example clean
Fixes when using python -builtin and STL container wrappers.
Bypass Python tests not supported by -builtin
Bypass Python tests not supported by -builtin
Bypass Python tests not supported by -builtin
Bypass Python tests not supported by -builtin
Bypass Python tests failing with -builtin
Bypass Python tests throwing base classes as exceptions for -builtin
Add some more Python -builtin tests that don't work
Disable test not relevant for Python -builtin
Conflicts:
CHANGES.current
By default it doesn't work as it does not call the CEO's __del__ method
as indicated in the comments. __del__ is called with -builtin but
then the base class's __del__ is not available and so it errors out.
Python 3 and -builtin goes into an endless loop. So removing as
hopelessly broken.
Also fixes li_std_vector_enum testcase when run with -threads.
Patch supplied on swig-devel mailing list on 12 Sep with details...
==============================================
I just wanted to mention that I found a crash issue in bug..
I am using SWIG 2.0.11 with python and have –threads enabled. I have a C++ std::vector that I instantiate in SWIG with %template. I also have a method in a class that returns this vector. I also include std_vector.i, btw..
When I iterate like so:
children = Action.getActionList()
for child in children:
pass
Everything is fine..
When I iterate like this:
for child in Action.getActionList()
pass
Product crashes.
The problem is the following. This code gets called first:
SWIGINTERN PyObject *_wrap_delete_SwigPyIterator(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
PyObject *resultobj = 0;
swig::SwigPyIterator *arg1 = (swig::SwigPyIterator *) 0 ;
void *argp1 = 0 ;
int res1 = 0 ;
PyObject * obj0 = 0 ;
if(!PyArg_UnpackTuple(args,(char *)"delete_SwigPyIterator",1,1,&obj0)) SWIG_fail;
res1 = SWIG_ConvertPtr(obj0, &argp1,SWIGTYPE_p_swig__SwigPyIterator, SWIG_POINTER_DISOWN | 0 );
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "delete_SwigPyIterator" "', argument " "1"" of type '" "swig::SwigPyIterator *""'");
}
arg1 = reinterpret_cast< swig::SwigPyIterator * >(argp1);
{
SWIG_PYTHON_THREAD_BEGIN_ALLOW;
delete arg1;
SWIG_PYTHON_THREAD_END_ALLOW;
}
resultobj = SWIG_Py_Void();
return resultobj;
fail:
return NULL;
}
Note the SWIG_PYTHON_THREAD_BEGIN_ALLOW/END_ALLOW. In between those two statements, we delete arg1. That in turn will eventually end up in this code:
namespace swig {
class SwigPtr_PyObject {
protected:
PyObject *_obj;
public:
… snip! …
~SwigPtr_PyObject()
{
Py_XDECREF(_obj);
}
Uh-oh! We call Py_XDECREF when we aren’t supposed to because we are in a SWIG_PYTHON_THREAD_BEGIN_ALLOW/END_ALLOW section!
This takes care of the issue:
namespace swig {
class SwigPtr_PyObject {
protected:
PyObject *_obj;
public:
… snip! …
~SwigPtr_PyObject()
{
SWIG_PYTHON_THREAD_BEGIN_BLOCK;
Py_XDECREF(_obj);
SWIG_PYTHON_THREAD_END_BLOCK;
}
There are several other methods in this class that use the Python API, but don’t have the BEGIN/END block defined. I’m not sure if they are required for all of them, but I believe they are..
I have attached a modified pyclasses.swg with what I believe are the correct changes. This code is from 2.0.11, but as far as I can tell, it’s the same as what is in 3.0.2…
Apologies for not doing more here (making/running tests, getting it in the code repository, etc..), but I’m under some pressure to get some unrelated things done…
director method - PHP NULL gets returned by the subclassed method
in this case, so the directorout typemap needs to allow that (at
least if an exception is active).
-- The commit propagates the package option to the newly create
module node so it is recognized by SWIG
-- Added a relativeimport test for this combination
(in lack of py3 I was not able to test it with py3 but it
"should just work")
