Closed GoogleCodeExporter closed 8 years ago
I'm at a loss on how to fix this one. Help, anyone?
Original comment by sir...@gmail.com
on 5 Sep 2008 at 1:42
As I understand, reference is increased here:
self.body.SetUserData( self )
and here:
self.shape.SetUserData( self )
I tried commenting the second SetUserData, and still the destructor wasn't
called.
So I commented the first too, and it was called.
I think the problem here is not because of the "twice reference increasing",
but
because you are setting "self" as the parameter for SetUserData. This creates
some
kind of "circular" reference, and the object can never be destroyed.
Original comment by msiegwarth@gmail.com
on 27 Oct 2008 at 11:49
I can confirm that this bug works even if you set the userdata in the def as
well.
I belive the problem is that clearing the userdata (SetUserData(None)) doesn't
decrease the reference counter.
Original comment by paul.d.bergeron@gmail.com
on 21 Jan 2009 at 8:19
I don't know how to code it, or much about SWIG, but I can point out what needs
to
happen:
Box2D.i between lines 173-197 on r147.
You must test is the value passed to the userdata is None. If so, call
Py_XDECREF
(PyObject *o) on the current userdata.
Original comment by paul.d.bergeron@gmail.com
on 21 Jan 2009 at 8:32
Ironically, this project started about a year ago attempting to get userData
working
so that Python could access the void* userData, and it's one of the things that
has
yet to be perfected.
Paul, thanks for your comment. Your fix, though not an all-around one, will
take care
of this a bit. It will still require setting the userData to None before
destroying
the object itself. I'll restructure the GetUserData/SetUserData again soon and
at
least get this example working with an additional a.destroy().
Original comment by sir...@gmail.com
on 21 Jan 2009 at 10:57
[deleted comment]
[deleted comment]
As of r153, I believe that this issue is fixed.
Output of test (modified with Box2D2 -> Box2D, and adding an additional
argument to
Step):
% issue6.py
c.__init__
c.__del__
Original comment by sir...@gmail.com
on 25 Jan 2009 at 1:16
Original issue reported on code.google.com by
sir...@gmail.com
on 19 Jul 2008 at 11:30