#715: Parents probably not reclaimed due to too much caching
-------------------------------------------------------------------+--------
Reporter: robertwb |
Owner: somebody
Type: defect |
Status: needs_review
Priority: major |
Milestone: sage-5.4
Component: coercion |
Resolution:
Keywords: weak cache coercion Cernay2012 | Work
issues:
Report Upstream: N/A |
Reviewers: Jean-Pierre Flori, Simon King, Nils Bruin
Authors: Simon King, Jean-Pierre Flori | Merged
in:
Dependencies: #9138, #11900, #11599, to be merged with #11521 |
Stopgaps:
-------------------------------------------------------------------+--------
Comment (by nbruin):
Replying to [comment:292 SimonKing]:
> Do you really say: ''Any''? I ask, because the "classical" application
of `TripleDict` in sage.structure.coerce would either have `None` (for
coercion maps) or an operation (for actions) as third key item.
> Hence, if a strong reference to the third key items of `TripleDict`
suffices to fix the problem, then I reckon the "non-classical" use of
`TripleDict` in #11521 is involved in the segfault: The cache for Homsets,
which has categories as third key items.
Not quite. Good suggestion! I tried to only the strongrefs that are either
a Category or not, and in either case I prevented the segfault. There's a
large overlap between the other keys between different entries, and if a
deletion is to blame somewhere, ANY reference to that object would prevent
the segfault. I concentrated on the classical use, because that involves
few 3rd keys. I found the following possible non-category third keys (not
looking at those that are present after sage initialization already):
{{{
set([False, True, <built-in function div>, <built-in function mul>,
None, <built-in function eq>, <built-in function add>,
<built-in function iadd>])
}}}
I tried only storing entries with one third key, for each of the above.
Only `<built-in function mul>` prevents segfaulting. This doesn't say with
absolute certainty that it's one of those key triples whose deletion
causes the problem. It could also be that a subtle change in memory layout
prevents the segfault. Anyway, the key triples in question are (only the
ones added after sage init):
{{{
(Rational Field, <type 'int'>, <built-in function mul>)
(Univariate Polynomial Ring in x over Rational Field, Integer Ring,
<built-in function mul>)
(Rational Field, Rational Field, <built-in function mul>)
(Rational Field, Complex Lazy Field, <built-in function mul>)
(Number Field in I with defining polynomial x^2 + 1, <type 'int'>, <built-
in function mul>)
(Integer Ring, Symbolic Ring, <built-in function mul>)
(<type 'int'>, Symbolic Ring, <built-in function mul>)
(Integer Ring, Rational Field, <built-in function mul>)
(Symbolic Ring, <type 'int'>, <built-in function mul>)
(<type 'float'>, Symbolic Ring, <built-in function mul>)
(Real Field with 53 bits of precision, Rational Field, <built-in function
mul>)
(<type 'list'>, Integer Ring, <built-in function mul>)
(Rational Field, Real Interval Field with 64 bits of precision, <built-in
function mul>)
(Real Interval Field with 64 bits of precision, <type 'int'>, <built-in
function mul>)
(Number Field in I with defining polynomial x^2 + 1, Rational Field,
<built-in function mul>)
(Rational Field, Complex Interval Field with 64 bits of precision, <built-
in function mul>)
(Multivariate Polynomial Ring in a, b, c, d over Rational Field, Rational
Field, <built-in function mul>)
(Multivariate Polynomial Ring in x, y, z over Rational Field, Rational
Field, <built-in function mul>)
(<type 'int'>, Rational Field, <built-in function mul>)
(Ambient space of the Root system of type ['A', 3], Rational Field,
<built-in function mul>)
(Rational Field, Ambient space of the Root system of type ['A', 3],
<built-in function mul>)
(Rational Field, Root space over the Rational Field of the Root system of
type ['A', 3, 1], <built-in function mul>)
(<type 'int'>, Full MatrixSpace of 4 by 4 sparse matrices over Integer
Ring, <built-in function mul>)
(Full MatrixSpace of 4 by 4 sparse matrices over Integer Ring, Integer
Ring, <built-in function mul>)
(Integer Ring, Coroot lattice of the Root system of type ['A', 3, 1],
<built-in function mul>)
(Rational Field, Weight space over the Rational Field of the Root system
of type ['A', 3, 1], <built-in function mul>)
(Integer Ring, Weight space over the Rational Field of the Root system of
type ['A', 3, 1], <built-in function mul>)
(Rational Field, Integer Ring, <built-in function mul>)
(Full MatrixSpace of 4 by 4 dense matrices over Rational Field, Vector
space of dimension 4 over Rational Field, <built-in function mul>)
(Vector space of dimension 4 over Rational Field, Rational Field, <built-
in function mul>)
(Integer Ring, Full MatrixSpace of 130 by 390 sparse matrices over Integer
Ring, <built-in function mul>)
(Integer Ring, Full MatrixSpace of 130 by 390 sparse matrices over
Rational Field, <built-in function mul>)
(<type 'long'>, Integer Ring, <built-in function mul>)
}}}
By the way, I've checked that the segfault really happens during `P =
Q['a, b, c, d']` in example 27, not in getting the generators.
Again, it's only ''likely'' that one of these objects is involved, since
not strong reffing them allows a segfault to happen. Unlikely, but not
impossible, is that the mere presence of one of these objects in memory
changes the location of an otherwise unrelated memory corruption. I think
it's unlikely because the other tests show you can change quite a bit
about what you store or not and still get a segfault.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:294>
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.
