From: Daniele V. <dan...@gm...> - 2010-01-10 23:06:04
|
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 |