#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: Reported upstream. Developers acknowledge bug. |
Reviewers:
Authors: | Merged
in:
Dependencies: |
Stopgaps:
------------------------------------------------------------------+---------
Comment (by SimonKing):
Replying to [comment:48 nbruin]:
> Replying to [comment:45 SimonKing]:
> > {{{
> > M src/omalloc/omAllocDecl.h
> > M src/omalloc/omAllocFunc.c
> > M src/omalloc/omMallocSystem.h
> > M src/omalloc/omalloc.c
> > M src/omalloc/pmalloc.h
> > }}}
> > So, first question: Is it correct that all three new files are needed
for malloc support?
>
> I didn't make any new files and I only seriously edited things in the
`omalloc` directory.
OK, so, I assume you only edited the five files indicated above, and did
no other changes by yourself.
> I may have done some rough hacking in config files to ensure that the
changes took effect, but I believe that it should be possible to do
without by someone who know how to pass the correct options to configure
etc.
Well, I don't know.
> To make the "spkg" I only did a "make clean" and a command to make the
dir into a spkg.
That means that ''all'' patches from the `patches/` directory are applied
in your code, and if `make clean` is imperfect then it also means that
some auto-generated (machine dependent) files are in your code.
> I disabled the "patch application" in spkg-install because that made it
fail the second time I ran it (which is inconvenient when you're editing
the package!)
Sure, because you started with code that already contains all patches.
> Note that `malloc_usable_size` for glibc has the same function as
`malloc_size` on BSD (OSX), so if there's a convenient config option to
choose between the two you can make the spkg so that it compiles on both.
Hm. I see the following definition
`src/omalloc/dlmalloc.h`
{{{
/* define to -1 if you want that this implementation provides
malloc/calloc/realloc/free funcs */
#ifndef OM_PROVIDE_MALLOC
#define OM_PROVIDE_MALLOC 0
#endif
#ifndef HAVE__USR_INCLUDE_MALLOC_H
#undef HAVE__USR_INCLUDE_MALLOC_H
#endif
#ifdef HAVE__USR_INCLUDE_MALLOC_H
#define HAVE_USR_INCLUDE_MALLOC_H 1
#endif
#define OM_MALLOC_MALLOC mALLOc
#define OM_MALLOC_REALLOC rEALLOc
#define OM_MALLOC_FREE fREe
#define OM_MALLOC_VALLOC vALLOc
#define OM_MALLOC_VFREE(addr, size) OM_MALLOC_FREE(addr)
#define OM_MALLOC_SIZEOF_ADDR(addr) malloc_usable_size(addr)
#define cfree cFREe
}}}
I don't totally understand the comment "define to -1 if you want that this
implementation provides malloc/calloc/realloc/free func". Does that
perhaps mean that `export OM_PROVIDE_MALLOC=-1` is all what one need to
use system malloc?
But I wonder: You say that `malloc_usable_size` is not available on OSX.
Then, the line
{{{
#define OM_MALLOC_SIZEOF_ADDR(addr) malloc_usable_size(addr)
}}}
sounds like a bug to me. I'll ask Hannes.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13731#comment:49>
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.
