[omniORB] Memory leak resolution in MFC?

[Jeroen.Dobbelaere@MMR.be]

> -----Original Message-----
> From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com]
> Sent: Monday, October 02, 2000 10:23 AM
> To: omniorb-list@uk.research.att.com
> Subject: Re: [omniORB] Memory leak resolution in MFC?
> 
> 
> To call these memory leaks is very misleading. As I have pointed out
> numerous times, these heap allocated memory are for static initialised
> variables or data structures which got initialised *once* on 
> program startup.
> None of these will cause your program to eat away your memory pool. 

Yes, I (and others) know this :
You allocate such data once (using new or malloc), but never free them. So,
strictly spoken,
they _are_ memory leaks (but of a nice kind, they don't grow in time).
(Btw, In the past there happened to be os's where memory was not
automagically passed back to the os when a program ends (Amiga).
On such systems, this behavior would create a real memory leak.)

Some people (me included) happen to like a nice cleanup of a program
(including data assigned to static pointers).
When such data is not freed, some environments (like MSVC6 on NT) will put
your
attention on it. (most people don't like this kind of attention, so,
we try to get rid of it).

> 
> We use purify, on Solaris and NT, to check for real memory leaks
> frequently. If you can find one bug that causes the program size to
> increase indefinitely I would be glad to hear that.
>

Sorry, we didn't found bugs like that ;), if we find one, you'll certainly
hear about it.
 
[..]
 --
Jeroen Dobbelaere
Software Design Engineer
Micro-Matic Research <http://www.mmr.be>