On Dec 31, 5:35 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> Yeah, sticking an untrack there certainly seems safe. It looks
> like PyObject_GC_UnTrack is idempotent, so we don't have to track it before
> going up the dealloc stack. If this fixes it, I sense another Cython
> release around the corner...
Not quite ... Quoting from Objects/typeobject.h:1034
Q. Why do we GC-untrack before the trashcan and then
immediately
GC-track again afterward?
A. In the case that the base class is GC-aware, the base class
probably GC-untracks the object. If it does that using
the
UNTRACK macro, this will crash when the object is already
untracked. Because we don't know what the base class does,
the
only safe thing is to make sure the object is tracked when
we
call the base class dealloc. But... The trashcan begin
macro
requires that the object is *untracked* before it is
called. So
the dance becomes:
GC untrack
trashcan begin
GC track
Q. Why did the last question say "immediately GC-track again"?
It's nowhere near immediately.
A. Because the code *used* to re-track immediately. Bad
Idea.
self has a refcount of 0, and if gc ever gets its hands on
it
(which can happen if any weakref callback gets invoked), it
looks like trash to gc too, and gc also tries to delete self
then. But we're already deleting self. Double deallocation
is
a subtle disaster.
Incidentally, it may be worthwhile to read up on this trashcan
mechanism. It looks like something cython objects might want to
participate in as well. It should help in keeping the stack shallow
during recursive deallocation calls.
--
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.
