#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):
> 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.
About what you pointed out in #13896 and I've reproduced here where it now
belongs,
I agree we can not use such a trick.
But I don't feel really confortable with this trick anyway.
It seems to me the trashcan macros where designed to avoid the situation
you produced here, that is objects pointing to objects pointing to...
which could eventually blow up the stack.
But then it also includes the fact that a given type can extend another
one and so they had to use that trick to fool the trashcan mecanism.
This seems indeed necessary because it could surely lead to strange
situation if the type specific action where happening between the trashcan
macro and the super class action outside of it, especially if this super
class doesn't use the trashcan macros.
And hopefully the trick is enough because I guess that at runtime through
the Python interpreter all you create use the subtype_dealloc function
which is skipping through all the inheritance till it reaches some class
with another allocator which will hopefully be a base type not extending
anything else or not using the trashcan macros.
The problem to deal with here is that each layer of Cython type will have
its own dealloc and without any knowledge on the depth of the type tower
we cannot so easily trick the trashcan macros indeed...
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.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13901#comment:3>
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.
