On Monday, December 31, 2012 4:29:18 PM UTC+1, Nils Bruin wrote: > > On Dec 31, 12:58 am, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > > But then I had a look at the C code Cython generated and thought it was > > the same... > > So we should look back at the C code, or ask a Python/Cython guru. > > The __delitem__ compiles as an ordinary method lookup and call, > whereas the "del A[..]" compiles as a straight call to PyDict_DelItem > (or whatever the name of the appropriate routine is). The preparation > of the parameter to either call seems to be the same. I agree it's > hard to argue that there's a fundamental difference between the two. > The "del ..." definitely seems preferable since it saves a method > lookup. > Yup and it's not yet clear to me how __delitem__ is resolved. In particular, in the dict objects definition, you have a nice correspondence set up for __getitem__ but nothing for __delitem__ (see mapp_methods in dictobjects.c), so this might in fact do complicated things.
> > I have only been successful reproducing this bug on sage-5.6b0 on > fedora 16 (x86_64). I have tried advanced debugging tools on 5.6b1 but > failed to reproduce the behaviour there. Hence the efforts with plain > gdb. > > So, the scenario we're seeing: > > - We have an object o that's being deallocated > - Its deallocation triggers a weakref callback to an instance of > TripleDictEraser > - TripleDictEraser removes a key of the form (h1,h2,h3) from a > dictionary _refcache, where h1,h2,h3 are IDs of objects k1,k2,k3 (one > of which is o) > - Somehow this removal triggers another deallocate of o > > Since h1,h2,h3 are just PyInt, their deletion can't possibly trigger > anything else, so the trigger must come from the value stored in the > dictionary. This value is (r1,r2,r3), where ri is a weakref (KeyedRef > to be precise) to ki (if possible). Python is a sane language, so I > trust that deleting a weakref will not trigger deletion of whatever > was pointed to. > > However, when ki is not weakreffable the ri is taken to be ki. Our > object o is obviously weakreffable (that's how we got the callback in > the first place), However, if one of k1,k2,k3 is not weakreffable > (tuples and lists aren't ...) but contains a reference to o then we > would get exactly such a trigger. > > Of course, the existence of a strong reference in _refcache to o would > preclude the collection of o ... unless they're all in the same cyclic > garbage. Then they could still end up being cleaned. > > So my conclusion is: TripleDictEraser should NOT decref any ri that is > not a weakref, because that could lead to deallocation of objects that > are already scheduled for deallocation. Do we need a list, "deathrow", > where we can move such references? Should we just try harder to store > a weakref to potentially dangerous ki? (we could store them in a > container class instance) > > I am not sure that this is exactly the issue we're running into, but > it seems plausible (it certainly needs a very brittle confluence of > circumstances to become apparent). Furthermore, I think it is a > scenario that does need addressing, because TripleDictEraser doesn't > seem to guard against this. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
