#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues: Detect and fix
public/ticket/10963 | Heisenbugs
Dependencies: #11224, #8327, | Commit:
#10193, #12895, #14516, #14722, | 5ccf253b17c151d8e773037ac634a64f84f03075
#13589, #14471, #15069, #15094, | Stopgaps:
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:238 SimonKing]:
> AFAIK, #15506 contains all fixes to the "recursion depth exceeded"
problem that Nils came up with.
Well, we observed the error, came up with an example that produced the
same error, and made sure that error didn't occur any more. It may be
we're looking at a different cause here (for one thing, it's hard to
imagine that doctests produce such deeply nested structures that even the
naive deletion code would trigger a recursion depth error). Another
hypothesis is that there is a dealloc somewhere that is genuinely
recursing on itself, perhaps creating a new parent upon deletion, that
then immediately becomes available for deallocation as well. It could be
that the first "deeper" call in those cases is always an eraser. In that
case, it's just that we're forcing the eraser to work with increasingly
smaller (python) stack headroom, in a way that apparently even the
trashcan can't avoid.
I'd say the most promising debugging technique is to set a breakpoint on
this RuntimeError (or patch python to throw a segfault or something like
it) so that we get to see the stack backtrace for when this problem
arises. I'd hope that seeing which routines are involved (I expect it not
to be just dictionaries) will show where the real problem may lie.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:239>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
