#12313: Fix yet another memory leak caused by caching of coercion data
--------------------------------------------------+-------------------------
Reporter: SimonKing | Owner:
Type: defect | Status:
needs_review
Priority: major | Milestone: sage-5.3
Component: memleak | Resolution:
Keywords: coercion weak dictionary | Work issues:
Report Upstream: N/A | Reviewers: Simon King,
Jean-Pierre Flori, John Perry
Authors: Simon King, Jean-Pierre Flori | Merged in:
Dependencies: #11521, #11599, #12969, #12215 | Stopgaps:
--------------------------------------------------+-------------------------
Comment (by nbruin):
> As much as I see, what needs to be fixed (or just needs to be reviewed,
because it already is in the patches): After testing equality of memory
addresses, test whether the weak reference is still valid. If it isn't
then delete the weak reference, in order to avoid its callback being
active.
I've seen complete doctest successes for #715 + #11521 + #12313, but the
last thing I saw, some bots were persistent about error that they didn't
report for other patches, which makes me think they may be real issues
that are hard to trigger. The problems I currently see:
#715,#11521:
- `TripleDict` set method is not dangling callback safe
- `TripleDict` __delitem__ method doesn't raise an error when deleting a
dead entry (don't think that's much of an issue and arguable whether it
should do that anyway. In fact, with `TripleDictEraser` using it, it
can't)
- `TripleDictIter` isn't safe wrt to dangling weakrefs. That one's a real
segfault waiting to happen, because it instantiates object references by
pointer cast!
- `TripleDictEraser` hold a strong reference to the TripleDict. I suspect
that should be weak, although that adds to deletion costs...
- You're importing `ConstantFunction` but you don't use it.
If you have a reliable way of generating the segfaults, it might be worth
trying with #13387. The iterator there should be safe. There might be
other issues, though.
I have a preference to getting #715 + #11521 in mergeable state, because
I think that enhances our chances of actually making progress (in terms of
getting stuff merged). Making #13387 one huge patch bomb is probably hard
to review. This code really needs to be read for review.
#12215: Bot is reporting a SIGABRT somewhere, which is probably an
"assert" failing in C code. Smells like memory corruption, so it would be
really useful to get a report on. Code in the patches is really simple, so
I'm suspecting a nasty interaction with #715,#11521 that now gets
triggered because now things are actually getting collected.
#12313: Bot reports a SIGSEGV somewhere, Same story as above.
#13370: Bot reports a SIGSEGV
Most likely explanation is that our MonoDict and TripleDict
implementations corrupt memory in rare cases and that the other tickets
trigger that by changing other things so that they get exercised more.
Can we get access to the bot or equivalent configuration to recreate the
circumstances? Or can we get someone involved who can (one is called
volker-desktop ...).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12313#comment:182>
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.
