#13901: Fix cython's deep C-stacks upon deallocation
-------------------------------------------------------+--------------------
Reporter: nbruin | Owner: rlm
Type: defect | Status: new
Priority: major | Milestone:
sage-5.6
Component: memleak | Resolution:
Keywords: | Work issues:
Report Upstream: Reported upstream. No feedback yet. | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-------------------------------------------------------+--------------------
Comment (by jpflori):
Replying to [comment:5 nbruin]:
> Replying to [comment:3 jpflori]:
>
> > But shouldn't we just ignore such extensions? i.e. if we detect we are
in the Cython world and giving hand to another Cython deallocator, we
should not trick the trashcan magic by reincrementing
_Py_Trash_delete_nesting until we hit a non Cython type.
>
> The problem there is that if the type gets trashcanned halfway up the
tower, the pointer would be added to the trashcan we'd be returning all
the way up to the leaf class dealloc instance. That would decref and free
the memory block. Once the trashcan gets emptied, the pointer (now
masquerading as an
I think I meant the other way around, that is emulating for Cython classes
what subtype_dealloc does to skip the subtype themselves using
subtype_dealloc.
This would ensure that a tower of Cython classes gets deallocated at once,
even though the objects pointed to (which typically could lead to stack
blow up) can be trashcan, just as is the case with a tower of CPython
types using subtype_dealloc.
Of course implementing that will be more complicated than in the
subtype_dealloc, because we have to know we are at the top and the kind of
types above us.
And at each level we have some specific action to take (what is not the
case with subtype_dealloc).
Not sure in fact now that the esaiest way is not to first check the depth
of the type tower and use exactly the same trick as CPython but with that
depth instead of 1 when decr/incrementing artificially the trashcan depth
counter...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13901#comment:6>
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.
