delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/03/30/12:06:07

From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9803301452.AA14808@clio.rice.edu>
Subject: Re: djgpp malloc and freeing memory on exit
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Mon, 30 Mar 1998 08:52:43 -0600 (CST)
Cc: eldredge AT ap DOT net, edc AT arches DOT uga DOT edu, djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.980330140958.19525I-100000@is> from "Eli Zaretskii" at Mar 30, 98 02:10:24 pm

1) free() does not actually free memory - but just returns it to malloc()'s
   internal pool.  malloc() gets that pool from sbrk().  sbrk() gets it's
   memory from dpmi.  Some dpmi providers do not free memory on image 
   exit if there is any nesting taking place.  DJGPP has special code to
   free all the DPMI memory it requested to avoid this problem.
   
   In any case, calling free() when you know you are exiting is not needed.
   If you manually allocated any dpmi memory you should free it if your
   program may be called from another program.

2) Some dpmi providers do not free selectors when nesting.  DJGPP has 
   special code to try and free as many as it can on exiting.  It cannot
   free them all (it's current CS/SS for example).  DJGPP leaks selectors
   (about 4 per nested image) when running under those DPMI providers.
   This limits the number of times you can call a nested image to about
   2000 times.
   
   If you manually allocate any DPMI selectors for any purpose you should
   free them if your program may be called from another program.

In summary, all the selector/memory cleanup issues are only needed when
one DPMI application calls another.  But since make/gcc/cc1 are common
examples of nesting, it needs to be handled.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019