Search ProofOfProgress Blog

Thursday, February 11, 2016

Memory Leak Detection, pooling out of scope.



Decided that in my memory leak detection code, I should not try to support
LIVE and IDLE object pools for every single class.
That link together the instances using a linked-list base class.

Why:
1. Could get very complicated very quickly.
2. With inheritence, does the base class, or the superclass get to own the object
and have it within it's static linked list?
3. OUT OF SCOPE. This is memory management. We only want to do memory leak detection.

New approach:
All objects inherit from a linked list base class.
There is a MASTER two-way linked list in the C++ project when in debug mode.
If an object from my project exists, it is part of this linked list.

(Only if they are classes, structs do not follow this rule)

Between:
1. Using object_ids and parent_ids to confirm object has only one owner.
2. Using MyClass::kill( *instance) methods to manage deletion
3. Using kill_hash checksums to confirm the objects you think were destroyed were destroyed.
4. Using one master linked-list so we can check for orphaned pointers.

I say we have pretty good measures to prevent memory leaks.
Just need to make sure that, when memory leaks are found, we can control the situation.

AKA: I'd rather not find my memory leak by accessing a null pointer.
I'd like to find it by having my memory leak detection code find out about it's existence
in a less hazardous way.

No comments:

Post a Comment