Blog
Last one out turn off the lights.
Date: 8/7/2008
In my travels I've had reason to play with custom memory managers for tracking leaks. My particular flavour outputs a text file on exit with each leak and the stack frame of the allocator, including file and line numbers. Very useful.

Initially I ran the dump code using an atexit handler. This seemed to work well, but then I noticed that some global objects were being destroyed after the dump handler was called AND to top it off the handler would not finish. The process would exit WHILE the dump was mid stream. So you get some of the blocks but not all.

So I've been playing with other methods of calling the dump code in the right place. The best so far that I've come up with is this:
#include <process.h>
#include "MemTrack.h"

int main()
{
    char *buffer = new char[256]; // leak something

    // normal main code..

    #ifdef TRACK_MEMORY
    _cexit();
    MemDumpBlocks("leaks.txt");
    ExitProcess(0);
    #else
    return 0;
    #endif
}
Or something like that. The call to _cexit calls all the global destructors so that their memory is freed before you dump your blocks to disk. Then the ExitProcess is the neatest way to end the process right now without any more cleanup code being called. I played with _exit, but it didn't really exit right now... it wanted to call all the global destructors again. Not cool.

Anyway there you have it, an insight into calling code after all the global objects have been cleaned up.
 
Reply
From:
Email (optional): (Will be HTML encoded to evade harvesting)
Message:
 
Remember username and/or email in a cookie.
Notify me of new posts in this thread via email.
BBcode:
[q]text[/q]
[url=link]description[/url]
[img]url_to_image[/img]
[pre]some_code[/pre]
[b]bold_text[/b]