#13896: Fix cython's gc_track and gc_untrack
------------------------------------------------------------------+---------
Reporter: nbruin |
Owner: rlm
Type: defect |
Status: new
Priority: blocker |
Milestone: sage-5.6
Component: memleak |
Resolution:
Keywords: | Work
issues:
Report Upstream: Reported upstream. Developers acknowledge bug. |
Reviewers:
Authors: | Merged
in:
Dependencies: |
Stopgaps:
------------------------------------------------------------------+---------
Comment (by nbruin):
Replying to [comment:17 robertwb]:
> The base tp_free looks at the actual type's flags (which will have
GC_FLAG set) to determine what gc (un)tracking to do. Any intermediate
superclasses will either leave this alone or do the untrack/track dance.
... so suppose we have a superclass that doesn't do the untrack/track
dance (so this must be a non-container superclass of a container class.
We're entering rather hypothetical territory here). We'll be entering its
dealloc with tracking SET. I guess the actual memory free happens by our
class, so I guess the list of GC-tracked objects will be properly amended
eventually. Can we prove that no GC or trashcan-shelving of this
intermediate object will happen in between? I guess it's unlikely because
non-container types should be easy to GC ... unless some callous person
writes an extension class that does hold references to other objects but
is convinced that those will never lead to cycles and hence makes it non-
GC-tracked. Some weakref callbacks and a GC could then find a partially
torn down object tracked by the GC. Multithreaded stuff could make this
even worse, but I guess we're protected by the GIL here.
It should probably be mandated that ''any'' container type ''has to''
participate in GC. For a non-container type it's hard to see how a dealloc
could ever be interrupted or interleaved by a GC. So this note is probably
more a request for clarification (addition to documentation somewhere?)
why this is not a problem than a diagnosis of a bug.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13896#comment:19>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
