By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,652 Members | 1,473 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,652 IT Pros & Developers. It's quick & easy.

memory allocation logging for leak detection - problem with globals

P: n/a
Hi all,

I implemented a memory allocation/deallocation class that logs all
new/delete calls (overloaded) and remembers for each allocated
block where it was allocated from (using a macro that passes __FILE__
and __LINE__). On destruction, it reports all undeleted blocks
(memory leaks).

The class is implemented in a separate .h/.cpp pair, and should be
linked to
code when I want to use it (plus a #define should be set and the
header should be included).

It works nicely, except for one problem - global objects. There is
one global instance of the logging class in the .cpp file, and it
catches all memory leaks from inside main() just fine. It misbehaves
with global objects - reporting many false alarms.

I'm aware of the fact that the order of construction/destruction of
global objects (in different files) is not specified by the standard.
However, I still wonder whether it's possible to implement this
somehow portably ? Non-portably (after all, checking for memory leaks
on one platform should be enough, I think...) ?

If not, it would be another good reason to never use globals B-)

Thanks in advance
Eli
Jul 22 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
In article <99**************************@posting.google.com >,
sp******@yahoo.com (Spur) wrote:
Hi all,

I implemented a memory allocation/deallocation class that logs all
new/delete calls (overloaded) and remembers for each allocated
block where it was allocated from (using a macro that passes __FILE__
and __LINE__). On destruction, it reports all undeleted blocks
(memory leaks).

The class is implemented in a separate .h/.cpp pair, and should be
linked to
code when I want to use it (plus a #define should be set and the
header should be included).

It works nicely, except for one problem - global objects. There is
one global instance of the logging class in the .cpp file, and it
catches all memory leaks from inside main() just fine. It misbehaves
with global objects - reporting many false alarms.

I'm aware of the fact that the order of construction/destruction of
global objects (in different files) is not specified by the standard.
However, I still wonder whether it's possible to implement this
somehow portably ? Non-portably (after all, checking for memory leaks
on one platform should be enough, I think...) ?

If not, it would be another good reason to never use globals B-)


I've coded similar tools:

http://home.twcny.rr.com/hinnant/MemoryManager/

The approach I took was to implement my global memory allocator with a
simplistic singleton pattern (a function local static accessbile via a
returned reference). This isn't perfect, but it tends to work well in a
wide variety of circumstances. When a global constructor fires (before
main), and tries to allocate some memory, it will trigger the
construction of the global memory allocator before its own constructor
completes. At program termination, leak checking is done in the
destructor of the global memory allocator. With luck your allocator's
destructor will run after there is any more legitimate heap activity
occurring.

Note that there are situations where this design fails, most notably if
a global constructor runs before the memory allocator gets constructed
and does not allocate memory at that time, but then allocates memory
later in its lifetime. Its destructor will run after the allocator's
destructor has run, and thus will be freeing memory to an already
destructed allocator which has already flagged that memory as leaked.

So it's not perfect, but it tends to work fairly well in practice. In a
problem situation you could have the global "preflight" the debugging
allocator by allocating some memory in its constructor even though it
didn't need to.

There may also be an implementation defined way of ordering your global
constructors. I used to use this technique with my debugging allocator.
However after using that technique for a few years I finally changed to
the local static design because it was less of a pain in the rear to use
for the type of code I needed to monitor.

-Howard
Jul 22 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.