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

[Michael K. <neg...@ea...>]

----- Original Message -----
From: Eero Pajarre <epa...@ko...>
To: <pli...@li...>
Sent: Sunday, April 30, 2000 11:39 PM
Subject: Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall


> A memory block is live, if there is a valid pointer
> pointing to it. A pointer is valid if it
> is a local or global variable or if it is in a valid block.
> So a whole tree becomes leaked, if you lose its
> root pointer.
>

Ok, that almost makes no sense.

A pointer to a local variable is valid only within the local scope of code.
A pointer to a global variable is valid anywhere in the program. A pointer
to any block of memory not within a programs memory is only valid when it
has been assigned through the systems memory management routines, typically
through malloc or new.

A valid ('live') memory block is created through malloc/new, and is no
longer valid when a free/delete is called on it. A problem that I have seen
before is with two pointers pointing to a block of allocated memory. A
routine frees the block and clears one pointer, but the other pointer
remains but it is no longer valid because the system now thinks the block of
ram can be reassigned to another malloc/new call.

Also, a pointer may accidentially point to what can be concidered a "live"
block of ram - one that you have write access to - but that does not mean it
is a valid block of ram that you should be writing to, in all likelyhood
you'll be overwriting part of your program or data.

This is especially a problem with Windows because it doesn't protect any of
the system ram at all, and applications are free to walk all over each
other.

-Michael Kurth