Mail Archives: djgpp/1996/11/14/07:03:42
Eli Zaretskii wrote:
>
> On Fri, 8 Nov 1996, Elliott Oti wrote:
>
> > The output showed that the malloc'ed memory was *not* freed, despite the
> > call to free().
> >
> > The Borland C equivalent using coreleft() instead of _go32_dpmi_remaining_
> > physical_memory does return the correct amounts.
> >
> > What's happening? Did I miss something somewhere?
>
> You have missed section 15.2 in the DJGPP FAQ list (v2/faq202b.zip from
> the same place you get DJGPP). It explains that memory that is `free'ed
> is not returned to the DPMI server, and so `..._remaining_physical_memory'
> doesn't see it returned. It is just added to the pool of the free memory
> that `malloc' maintains.
I know, I've read it.
The problem is, after freeing reserved memory,malloc'ing new memory
still leads eventually to memory shortage errors in my program.
My program mallocs an amount of memory each loop and frees it
at the end. Only it *isn't* freed; the program runs fine for
a while and then starts excessively paging to the HD; then
it crashes with a SIGSEV.
It doesn't have this problem under Borland C ( it's compilable
on both compilers).
I've replaced malloc()/free() with a custom heap manager
( I was planning to do so anyway ) and it works fine,
but I find the behaviour of free() disturbing.
I'm not saying free() is buggy but my use of it is extremely
simple: malloc() once, free() once per loop. On BC/C++ it
runs flawlessly; on djgpp it crashes after about 10,000
iterations due to a paging exception, when it never
should have had to use virtual memory in the first place.
( the real-mode version runs in 640K).
Thanks anyway for your reply.
Elliott
- Raw text -