#13731: Fix libsingular memory management
--------------------------------------------------------------+-------------
       Reporter:  nbruin                                      |         Owner:  
rlm     
           Type:  defect                                      |        Status:  
new     
       Priority:  major                                       |     Milestone:  
sage-5.6
      Component:  memleak                                     |    Resolution:  
        
       Keywords:                                              |   Work issues:  
        
Report Upstream:  Fixed upstream, in a later stable release.  |     Reviewers:  
        
        Authors:  Nils Bruin, Simon King                      |     Merged in:  
        
   Dependencies:                                              |      Stopgaps:  
        
--------------------------------------------------------------+-------------

Comment (by nbruin):

 Well, `pNext(q)` (soon to be `q`) gets allocated. It's a `poly` which is a
 pointer to ultimately
 {{{
 struct  spolyrec
 {
   poly      next;           // next needs to be the first field
   number    coef;           // and coef the second --- do not change this
 !!!
   unsigned long exp[VARS];  // make sure that exp is aligned
 };
 }}}
 so whatever you allocate, it had better have enough room for that.

 As far as I understand, a "bin" is a (collection of) page(s) that gets
 used for allocation of same-sized memory blocks. So I'd expect an alloc
 that uses a bin reference to get the size to alocate from the bin rather
 than as a parameter. Here, things get allocated from the "poly" bin. So
 perhaps you don't need bins per se, but I think you do need to keep enough
 of the bin to know what size memory blocks are associated with it. The
 above code doesn't seem to do that (none of it).

 I would think `(T)omAlloc(sizeof(*T))` or something like that would be
 closer to what's required.
 At least (assuming T is a pointer type) it would allocate a block that's
 big enough to let a T type point to. But I may well be misreading the
 code.

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

Reply via email to