Re: [Pyode-user] Regression: collision detection broken in HEAD

[Daniele V. <dan...@gm...>]

On Sun, Jan 10, 2010 at 7:19 PM, Ethan Glasser-Camp <gl...@cs...> wrote:

> whatever). The only thing that strikes me as likely to be different is
> that instead of doing "python setup.py install", I ran:
>
> PYTHONPATH=build/lib.linux-i686-2.5/ python examples/tutorial3.py
>
> (Or whatever -- substitute the correct build directory on your machine.)

Well, I skipped over the details of my setup, but I am using a
virtualenv and putting the python library in a private non-system
directory. For ode I am using instead the /usr/local tree, taking care
to keep a single version of the library at time, cleaning things up
before "make install" of the new one I want to test.

I have done some steps ahead: I've noticed that space.getNumGeoms() =
31 in the working demo runtime (30 boxes and the floor), but in the
buggy one is always 1: this means that boxes geoms are not retained in
the space collection. Further analysis shows that space.getNumGeoms()
goes to 2 just after the addiction to the space (i.e. geom =
ode.GeomBox(space, lengths=body.boxsize)), but when the function ends
and the python "geom" variable goes out of scope, the count goes back
to 1.

As a test I added a global list of geoms appending the box geoms to it
before they go out of scope: with this fix the demo works correctly.

So, it looks like a structures ownership issue: as the head works, as
soon as the python object goes, so it does the wrapped C geom, also
when it is part of other structures (the space). This is a
counterintuitive behaviour from a Python P.o.V., because "well
behaved" python object are kept alive when another structure points to
them (while instead the association space ->geom seems more a weakref
now). Also the different outcome between my box and yours doesn't seem
a sign of robustness.

I already had an experience of writing a Pyrex wrapper around C
structures that could have either lived alone or been part of other
structures: to make everything work without leaks and dangling
pointers, I used an explicit flag on every wrapper, saying if the
wrapper was the "owner" of the structure (and this the structure had
to be deleted together with the python object) or if the wrapper was
just a view of a structure and some other object was in charge to
delete it (e.g. when doing some "foo.bar.baz": the object returned by
the "bar" attribute allowed a temporarily access to the underlying
structure, but the latter is not destroyed with the short-lived
wrapper: it is still "foo" to have its ownership). I don't know much
about the life cycle of the ODE structures (e.g. who is in charge to
free a geom when it is part of a space) but I suspect the bug I am
experimenting is caused by a mismatch with the life cycle imposed by
the pyrex wrappers and the Python runtime.

Cheers


-- Daniele