#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:7 jpflori]:
> I saw and read about this additional steps in addition to the macro, but
I was not sure it was also needed here.
In fact, I think the precautions taken are ''not enough'' for general
cython classes. With the little
{{{
++_PyTrash_delete_nesting;
Py_TRASHCAN_SAFE_BEGIN(self);
--_PyTrash_delete_nesting;
...
++_PyTrash_delete_nesting;
Py_TRASHCAN_SAFE_END(self);
--_PyTrash_delete_nesting;
}}}
dance they are making sure there is room for ''one'' extra trashcan
nesting ''provided that that call doesn't use the same trick''. However, a
cython class could have a whole inheritance hierarchy going here (that
would all use this trick too!), so I'm pretty sure that the exact scenario
they describe could still happen. You'd need to know the depth of the
inheritance line (for deallocs, multiple inheritance can't happen, right?)
and ensure there's enough room for all those.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13896#comment:8>
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.
