#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:40 SimonKing]:
 > Replying to [comment:35 jpflori]:
 > > Maybe we are just f***ing up with Python debug memory api.
 > >
 > > What Python rants about is that the first bytes before the actual
 object ONE, which should have been allocated in PyObject_DebugMallocAPI
 and set to FORBIDDENBYTE are in fact worth CLEANBYTE, which is what the
 debug memory api sets for the space reserved for the object itself...
 >
 > What is the problem with it? Can we prevent it? Does it make sense to
 prevent it when we are not in debug mode?
 It is not a problem outside of debug mode I guess.

 In debug mode the problem is that it seems that the object has been
 malloced/created without these surrounding FORBIDDENBYTE (and some
 additional info including the size allocated, and what API was used), but
 when it is deallocaed (what happened because a Py_INCREF was removed in
 #12615, and ONE was not cdefed), the dealloc functions look for these
 bytes (that's the OUCH part), and then try to reach something based on the
 size allocated which should be stored next to these bytes.
 Unfortunately this additional info is not present (not written when
 alloced? overwritten later? I don't know...) so the dealloc function gets
 a random size (look at "18302628885633695743 bytes originally requested"
 in your first comment) and it leads to a segfault.

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14059#comment:41>
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.


Reply via email to