#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: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
---------------------------+------------------------------------------------
Comment (by nbruin):
Replying to [comment:27 SimonKing]:
> The last line printed is `second freeT F,rN`. Hence, F seems to be
corrupted. Here is ho F is created:
> {{{
> int *F=(int *)omAlloc0((rN+1)*sizeof(int));
> int *G=(int *)omAlloc0((rN+1)*sizeof(int));
>
> memcpy(F, F0,(rN+1)*sizeof(int));
> // pExpVectorCopy(F,F0);
> memcpy(G, G0,(rN+1)*sizeof(int));
> // pExpVectorCopy(G,G0);
> F[0]=0; /* important for p_MemAdd */
> G[0]=0;
> }}}
>
> Is it a problem that `omAlloc0` is explicitly called? Or is it just a
macro, and actually defaults to malloc with your spkg?
That all should be safe. (omalloc already had an omEmulateAlloc config
option, but it was missing declarations and therefore Singular failed to
compile. I added those. Part of it was an `omMemDup` routine that takes
only a pointer, so it needs to know how large the block pointed to
actually is. I needed the linux-specific `malloc_usable_size` for this. It
looks into the 8 bytes preceding the block, which makes valgrind complain)
The actual declarations are for the most part near `omalloc.h:777`, which
comes from omAllocDecl.h:280.
{{{
#define omAlloc0(size) omEmulateAlloc0(size)
}}}
which is only defined in `omAllocEmulate.c`:
{{{
void* omEmulateAlloc0(size_t size)
{
void* addr = OM_MALLOC_MALLOC(size);
memset(addr, 0, size);
return addr;
}
}}}
where 'OM_MALLOC_MALLOC' is 'malloc' as far as I can tell (the number of
indirections involved in omalloc probably is very useful but it drove me
to despair). So that looks perfectly safe to me. Furthermore, I didn't
touch that file.
I suppose the corruption happens somewhere lower down. Incidentally, the
valgrind report points to ''exactly'' those two snippets. So valgrind
reporting for these things is really very good.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13731#comment:28>
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.
