Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Wolfram K. <w_...@rz...>]

Steve wrote:

>I think what you are talking about in MSVC is the issue of memory
>that the application allocated but did not free when the program
>exited.  This (if true) is a M$ peculiarity. "Proper" operating
>systems know what memory an application used during it's run and
>automagically reclaim it.

Yes, Windo$ NT does it.

>What's more interesting is memory allocated at one program milestone
>and not given back by some other.  

Yes. Under Windo$, there are functions to set up and use Checkpoints:

You set a Checkpoint via

void _CrtMemCheckpoint( _CrtMemState *state );

and then Dump all the objects that were allocated since a Checkpoint,
but not freed via:

void _CrtMemDumpAllObjectsSince( const _CrtMemState *state );
  
But I have to "admit" that looking for memory leaks I almost always
use _CrtDumpMemoryLeaks, which lists ALL used memory.
(For Windo$ users: _CRTDBG_ALLOC_MEM_DF works for me 
only sometimes).

I think there are not too many used memory blocks of 
the unproblematic kind. Of course, from the blocks I found now
(just starting and stoping the program) half or more might be
unproblematic.

But it is normally quite easy to put in deletes for these since there
is only one place where to free the block. Once I have done that
all the unused blocks I find then (for example when I do
start PPE - load 3D object - close 3D object - close PPE)
are problems.

Then you dont have to think about where to put the checkpoints
and whether all operations can be "checkpointed".

Thinking about it now, it might still well be that using
checkpoints is faster.

BTW, I looked up the link to Mr Boehm that
Eero gave me and he has an additional argument,
he writes about "fixing" the unproblematic "leaks":

"a potentially useless activity that often
triggers large amounts of paging. "

>Anyway, what I've done in the past was to overload the 'operator new'
>and 'operator delete' 

Yes, thats what I try just now.

>Alongside each record, I remember the
>value of a simple global variable.  

Just out of curiosity: Why dont you remember filename and linenumber
of the allocation?

>It's quite easy then to discover that the allocation happened (say)
>after the global was set to 1234 but before it was again set to 9876.
>You can use a 'binary chop' technique [...]

Yes, it sounds easy, but tedious.

>> At the moment I can only say that a lot of memory blocks are leaked if
>> I just start PPE and close it right away.
>
>I don't consider that a bug though...(although maybe Windoze finds
>it serious and we have to fix it anyway).

I think its a bug under Win 95.
Also, I think "fixing" these "leaks" will make it easyer finding real
leaks later on.

Well, lets see. One of the reasons I am looking into mem leaks in PPE
is that maybe I can learn something I will use  in work.

Bye bye,
Wolfram.