* amaeldoe-master:
Add python runtime test for dynamically added attributes
Attribute of SWIG wrapped classes instances were overwritten on __init__()
Fix SwigPyObject->dict memory leak
Make __dict__ accessible for Python builtin classes
When a SWIG classes instances is initialized, its internal dictionary was
reset to NULL, which result in the loss of any attribute that might have
been set for the instance.
Only initialize the internal dictionary on actual PyObject creation.
class Test(MySwigWrappedClass):
def __init__(self):
self.val = "Random Value"
MySwigWrappedClass.__init__(self)
p = Test()
print hasattr(p, "val") # Should return True, but used to return False
The following patch attempt to fix a memory leak happening when a
random class attribute is set. The internal instance dictionary is
created but never freed.
This fixes the problem for me, although I am not sure the patch
is correct.
<code>
p = MySWIGClass()
p.random_attribute = 0
</code>
Valgrind report:
==18267== 280 bytes in 1 blocks are definitely lost in loss record 1,372 of 1,780
==18267== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18267== by 0x3A90A885DC: PyObject_Malloc (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90B101A8: _PyObject_GC_Malloc (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90B102AC: _PyObject_GC_New (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90A80943: PyDict_New (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90A6E8FC: PyFrame_New (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE1A65: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE088E: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE21DC: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE22E1: PyEval_EvalCode (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AFB71E: ??? (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AFC8DD: PyRun_FileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==18267==
Attribute set within instance of a SWIG Python wrapped class are
stored in SwigPyObject->dict, which tp_dictoffset slot is pointing to.
However, SWIG wrapped classes did not have a __dict__ attribute.
Inheriting subclasses did not get the attribute either because the
SWIG wrapped classes initialize the tp_dictoffset slot:
From http://bugs.python.org/issue16272:
"If a type defines a nonzero tp_dictoffset, that type is responsible for
defining a `__dict__` slot as part of the tp_getset structures. Failure to
do so will result in the dict being inaccessible from Python via
`obj.__dict__` from instances of the type or subtypes."
Provide a SwigPyObject_get___dict__() function to retrieve the dict
attribute or create it when it does not exist yet (it is normally
created when setting attribute set), and a PyGetSetDef entry pointing
to this function.
Default values are no longer generated as Python code by default.
They must be explicitly turned on using the "python:defaultargs" feature.
Closes#294Closes#296
The problems in these two issues when "python:defaultargs" is turned
on still need to be fixed and should be addressed in separate patches.
The important thing is the default code generation is now fixed.
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…
... if available on the version of Python that's in use. This allows
obtaining the original byte string (and potentially trying a fallback
encoding) if the bytes can't be decoded as UTF-8.
Previously, a UnicodeDecodeError would be raised with no way to treat
the data as bytes or try another codec.
- some of the %.clean rules in the test-suite Makefiles were using a single tab
as an empty rule, dangerous! I've replaced these with the safer '@exit 0'.
I managed to trace a very nasty Python interpreter segfault to an
allocation failure here. Adding this after the tp_new call:
if (PyErr_Occurred()) {
PyErr_Print();
}
results in output of 'TypeError: object() takes no parameters', followed
by a segfault that takes down the Python interpeter.
The 'object' constructor doesn't seem to be suitable for instantiating
SWIG shadow instances in this way, so simply use the constructor
function in the PyTypeObject 'tp_new' slot of data->newargs.
The 'if (inst)' check after this doesn't hurt in as much as it prevented
a segfault immediately after this failed allocation, but it doesn't help
much since the null pointer dereference will probably happen sooner or
later anyway.
These typemaps are currently defined for C#, Java and Python only and the
tests are provided only for these languages.
Also add a brief description of the new header to the documentation.
Advantages:
- it avoids the swig user having to jump through hoops to get print to
work as expected when redefining repr/str slots.
- typing the name of a variable on the python prompt now prints the
result of a (possibly redefined) repr, without the swig user having to
do any extra work.
- when redefining repr, the swig user doesn't necessarily have to
redefine str as it will call the redefined repr
- the behaviour is exactly the same as without the -builtin option while
requiring no extra work by the user (aside from adding the
%feature("python:slot...) statements of course)
- the patch simplifies pyrun.swg a tiny bit.
Disadvantage:
- default str() will give different (but clearer?) output on swigged
classes compared to unpatched swig
SF Bug #326
%template for a std::multimap generated uncompilable code unless a
%template for a std::map of the same template types was also coded up.
This patch is needed in conjunction with previous commit - 5f1fff1849Closes#64Closes#65
SF bug #1327
This doesn't have any noticeable effect with the usage of
SWIG_AsWCharPtrAndSize as shipped by SWIG, but could be a problem if a
user is using this function with cptr equal to zero and psize is non-zero
- the length would be incorrectly set due to the call to PyUnicode_GetSize
failing.
