By the way, the object that is allocated in the block that eventually gets freed twice is:
Set of Morphisms from <type 'sage.modules.module.Module'> to <type 'sage.modules.module.Module'> in Category of modules over Integer Ring Note that the first dealloc above is part of a TripleDictEraser call, that gets triggered by a PyObject_ClearWeakRefs as part of the dealloc of that same object! Since that code reads: struct ... *p = (struct ... *)o; if (p->__weakref__) PyObject_ClearWeakRefs(o); Py_CLEAR(p->_generators); Py_CLEAR(p->_category); ... this is already a problem: o and p point at the same location, so the call to ClearWeakRefs should definitely not lead to deallocation of its argument! TripleDicts have weakrefs on their keys, so the object *p above must appear as a key ... probably twice! So a reasonable assumption is that there are 2 weakrefs to *p. The first one triggers the call to TripleDictEraser. This cleans up the second weakref too. But if that code does not know that *p is already in the process of being torn down, it could decide that *p can be deleted and do that as well. What python *SHOULD* do for cleaning the weakrefs is: - collect all callbacks - null out all weakrefs to the objects - call the callbacks that way there wouldn't be any weakref links left that could lead to multiple "eligible for deletion" discoveries in processing the callbacks. I haven't checked but I really hope Python does do this. Another source of deletion triggers would be if we (still?) cast stored object IDs to <object>, in which case they'd be increffed and decreffed (leading to possible deletions!) However, when I inspected TripleDictEraser I thought it was safe for that. -- 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.
