Mail Archives: djgpp/1996/02/06/04:53:39
>
> >
> >
> > On 5 Feb 1996, John Beale wrote:
> >
> > > I am guessing that the many malloc/free operations fragments the memory
> > > store analgous to hard disk filesystem fragmentation with many saves and
> > > deletes, such that a contiguous memory segment for a large malloc() can no
> > > longer be found. Is there a malloc_unfragment() command or equivalent? How
> > > do other people handle this problem?
>
> I had to fight a similar problem these days and have been pointed to
> PD (though uniox based but maybe easily portable) diagnose tool, called
x
Following my own message I must correct myself WRT 'leak'.
I tested it and it does by far not what I expected. It also isn't
portable (uses unix dbm routines - which don't exist under DOS/djgpp afaik)
It does no boundary checking. It just gives you statistics where
allocs, reallocs and frees happened in your program by including the
following leak.h into your sources:
#define malloc(s) \
(_ptr = malloc(s), _dbinsert(_ptr, s, __FILE__, __LINE__, DBM_INSERT), _ptr)
> 'leak' (comp.os.unix.sources/volume00/leak - try archie leak).
>
> I have not tested it yet but it may do what I want - diagnosing
> my code or others code for memory leaks, too short allocates etc.
>
>
> There are also various alternative allocators. BTW, FreeBSD has now
> a nice diagnosing allocator which can be activated/strength increasable
> by an environment variable. You may obtain FreeBSD from somewhere
> and test your code there.
>
>
> >
> > This is a problem with many implementations of `malloc', the one from
> > DJGPP library included. The usual method of solving such problems in
> > programs that allocate and free many small arrays, is to allocate a large
> > buffer of memory and use parts of it as needed instead of calling
> > `malloc' and `free'.
> >
> > One piece of knowledge that might help you: the DJGPP `malloc' always
> > allocates blocks whose sizes are an integer power of 2; if you ask for
> > 32KB, you get 64KB (because of the 4-byte overhead of `malloc' itself).
> > So you might make your problems easier if you never get too close to sizes
> > of the form 2^n for any integer n.
> >
> > Another possibility, in the case that your allocations only last as long
> > as the function which allocated them, is to use `alloca' instead (which
> > allocates the memory from the stack). This way, you don't have the
> > fragmentation problem, and also are spared the need to call `free'.
> >
>
> --Chris Christoph P. U. Kukulies kuku AT gil DOT physik DOT rwth-aachen DOT de
>
--Chris Christoph P. U. Kukulies kuku AT gil DOT physik DOT rwth-aachen DOT de
- Raw text -