#14059: Fix refcount/deallocation of integers
------------------------------+---------------------------------------------
Reporter: SimonKing | Owner: rlm
Type: defect | Status: needs_review
Priority: blocker | Milestone: sage-5.7
Component: memleak | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Simon King | Merged in:
Dependencies: | Stopgaps:
------------------------------+---------------------------------------------
Comment (by jpflori):
Replying to [comment:38 SimonKing]:
> Replying to [comment:33 jpflori]:
> > I don't really think your solution is right.
> > As I mentioned these small integers won't be deallocated anyway as
they are cdefed, so we don't care.
>
> Anyway. I believe it should be cleaner to avoid integers being created
in one way and then deleted in a different way.
I agree.
>
> > And I'm not really sure that doing anything after the global dummy is
created rather than after the hook is in place.
>
> I can't parse that phrase. Do you say: There should be no code
whatsoever between the creation of the global dummy and the creation of
the hook?
I meant that following what you posted you should have tried to create the
integers different from the dummy one just after the dummy one and not
after the hooks are in place.
But as stated above, I agree that it is cleaner to create everything after
the hooks are in place, except for dummy of course cos its not possible.
And anyway these integers are cdefed so wont be garbage collected
automatically, although you can trigger their deletion by calling del on
them.
>
> > For further investigation, the Py_INCREF of the global dummy in
sage/misc/allocator.pyx seems useless as well now as it is cdefed and
won't be collected.
>
> I removed the Py_INCREF, and Sage starts and quits without problem. But
would it hurt to have the incref?
I don't think having code no one understands is a good thing.
And it would make a small slowdown to keep this incref :)
And prevent a proper deallocation of ONE when Sage quits, if we ever want
or manage to do that.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14059#comment:39>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
