#13447: Make libsingular multivariate polynomial rings collectable
-------------------------------------------------------+--------------------
Reporter: nbruin | Owner: rlm
Type: defect | Status:
needs_info
Priority: major | Milestone:
sage-5.4
Component: memleak | Resolution:
Keywords: | Work issues: Input
from libsingular experts
Report Upstream: Reported upstream. No feedback yet. | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-------------------------------------------------------+--------------------
Comment (by nbruin):
> Or is it a nasty race condition? Namely:
>
> * A polynomial p in a polynomial ring R is about to be garbage
collected.
> * All python stuff is deleted first. In particular, p's reference to
its parent R is gone.
> * Incidentally, because the reference from p to R is gone, R can now be
collected as well.
> * When R gets deleted, its underlying libsingular ring is deallocated.
> * Now, `p.__dealloc__` is finally called, and tries to access the
underlying libsingular ring - but it is too late.
>
> Question: If a polynomial is created, will the reference counter to the
underlying libsingular ring be incremented?
From what I understand, `__dealloc__` methods cannot assume that python
attributes are still valid. They fundamentally cannot, because otherwise
it wouldn't be possible to clean up cyclic garbage (`__del__` methods are
run when all attributes are valid and hence if they are present in cyclic
garbage, it is not cleared).
So, I think that if the libsingular ring pointer is necessary during
deallocation of a polynomial, then it should store it in a c-variable.
Then it would indeed need to increase the reference counter.
You'd initially think that you could store a "c level" pointer to the
python polynomial ring and manually increase the refcount. That would
ensure that the python polynomial ring is still alive when `__alloc__`
gets called. However, it would also mean that there is an extra refcount
that the cyclic garbage detector wouldn't be able to explain, so
polynomial rings would always appear to have an "external" reference and
hence never be eligible for garbage collection. Since rings tend to cache
0 and 1, such references would always be present and all you work would be
for naught: Polynomial rings would exist forever.
So I think you have to bite the bullet and ensure that get_cparent doesn't
access any python attributes or that you can avoid calling it in a
`__dealloc__`.
I'm afraid you will end up rewriting essentially all of sage, but people
will be grateful. Of course, I could be wrong.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13447#comment:27>
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.
