#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 SimonKing):

 Replying to [comment:92 nbruin]:
 > I haven't looked into what happens here exactly, but `r->PolyBin` does
 get passed around. It might not be deref problem, though, but:
 > `omalloc/omalloc.h:142` (xalloc really)
 > {{{
 > #define omTypeAllocBin(T,P,B)    P=(T)omAlloc(sizeof(B))
 > #define omTypeAlloc(T,P,S)       P=(T)omAlloc(S)
 > #define omTypeAlloc0Bin(T,P,B)   P=(T)omAlloc0(B)
 > }}}
 > looks suspicious to me. The two allocbin routines look incompatible to
 me. I think they are supposed to have the same interface type.

 Could very well be. The "sizeof(...)" was my addition - without it, the
 compiler would complain, and indeed looking into the code it seems that a
 size was expected. Perhaps I should add the "sizeof" to the other two
 macros as well, even though the compiler did not complain about them.

 Or, yet another possibility: If I am not mistaken, the bins don't really
 matter when omalloc is ripped out. Hence, one could perhaps simply do
 ''nothing'' instead?

 Alternatively, one could think of defining `typedef size_t* omBin;` rather
 than the current `typedef size_t omBin`, so that at least we have a
 pointer which we can allocate memory for.

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