From: Chris B. <chr...@gm...> - 2007-06-18 12:59:57
|
On 15/06/07, Chris Spencer <chr...@gm...> wrote: > On 6/15/07, Chris Bainbridge <chr...@gm...> wrote: > > > > The problem is that the destructor order is essentially random when gc > > is used. ODE (not pyode) doesn't have any ownership rules for objects, > > and objects point to each other, so deallocating objects causes memory > > protection faults. This is also a problem with C++ ODE code, python > > with gc just aggravates the problem. In my Simulator.__del__ function > > I have something like: > [snip] > > Thanks for the tips. I tried implementing a similar __del__ for my > top-level object, but I still encounter the problem. Are you sure your __del__ function is being called first? You might need to rename it and manually call it from your shutdown function before python starts garbage collecting. > Since it looks like this problem isn't going to be fixed anytime soon, > is there anyway to work around the issue? With my usage, the fault > only happens when the Python process is terminating, but it's stopping > a new process from being spawned. Is there any way to recover from it, > or is this problem fatal? You can ignore the return code? Not very elegant though. You could stop using gc. Python has reference counting anyway, so the only effect is that you need to manually remove cyclic links between your objects from __del__ methods. It's quite easy with the gc module to dump the number of objects of each type and see which ones aren't being destroyed. |