C++ : Overloading Global new/delete
Author
Well, yesterday I overloaded the global operators new and delete to track memory leaks. I had the (displeasing) surprise of finding out that if you overload them in one location, they become overloaded *everywhere*, no matter if you include the declaration or not. I decided this was still viable, if I changed my design a bit... However...
Today, I did some experiments with G++. I overloaded new and delete, along with new[] and delete[]. I made them print to std::cout when allocations and deallocations are performed, and well, something weird is happening.
I created an std::vector<float> object, and pushed a float in it. When I do this, it outputs "allocating". However, when the vector goes out of scope, or even if I explicitly call clear() on it, *nothing* happens. It never outputs "deallocating". The only way it will output deallocating is if I explicitly call resize(0). This is kind of weird. I guess the G++ implementation of the STL must perform some kind of memory polling... But if I can't keep track of when the memory is being released (if at all), how am I possibly going to implement a working memory leak tracker...
It would have to deallocate the memory at some point, right?
If you are just trying to catch memory leaks, you don't have to worry about when stuff is allocated/deallocated, just that it is. Just do something that checks that no memory is allocated at the end of the program, and if there is, examine the tracking info (your info that you tagged on in new?) of the allocated blocks.
Alternatively, you could look into the CRT debugging functions.
Author
Hm. Well. I guess an option would be to use a specialized new that tags information, and to ignore other allocations and deallocations that refer to untagged blocks...
The thing is, it doesn't seem to be deallocating memory... And well, even though it does overload operator new everywhere, my macro to tag information along with it doesn't get replaced everywhere... But then you apparently can't explicitly call an overloaded delete to tag deletion parameters, which gets very annoying... Oh well...
The thing is, it doesn't seem to be deallocating memory... And well, even though it does overload operator new everywhere, my macro to tag information along with it doesn't get replaced everywhere... But then you apparently can't explicitly call an overloaded delete to tag deletion parameters, which gets very annoying... Oh well...
Does std::vector explicitly call delete to deallocate itself?
(note that it might very well use free, which wouldn't be cought by your tests)
(note that it might very well use free, which wouldn't be cought by your tests)
Regarding the CRT memory functions: I'm not entirely sure, but when you set the _CRTDBG_LEAK_CHECK_DF flag, some memory blocks may be printed at the program end which are freed later, for example the memory allocated by global objects, which is freed in the object's destructor. The problem is that the CRT memory dump function is called prior to the global object's destructor. So they may not be well suited to search for memory leaks, at least in C++.
Hm.. sounds like scoping issues. I wish I could help you more, but I've never overloaded a global operator, and I'm not quite sure what's going on.
Oh, and why would you want to track just part of the program? Seems that you would want to track the whole program if you are looking for memory leaks.
Quote:Original post by sphinx23
Regarding the CRT memory functions: I'm not entirely sure, but when you set the _CRTDBG_LEAK_CHECK_DF flag, some memory blocks may be printed at the program end which are freed later, for example the memory allocated by global objects, which is freed in the object's destructor. So they may not be well suited to search for memory leaks, at least in C++.
Actually, that's the point of that flag. Instead of just calling _CrtDumpMemoryLeaks() at the end of your program, you can set that flag to tell it to call the function as the very last step of the program, even after global objects have been deallocated.
At least it worked in my case. I had a couple global objects that would show up as leaks if I printed them at the end of the program, but when setting that flag it said I had no leaks.
OT: okonomiyaki: Well, it didn't work in my case ;). The list was printed, an then the destructors were called, which i had verified by putting breakpoints in them. The CRT said there was memory leaked whereas in reality this memory was freed...
Author
Okay. So I assume that function to dump memory leaks might work for me. Although I am in a special case (many dynamically linked DLLs). It should still be able to find all that was allocated and deallocated in the process I presume.
But how does it work? What does it do? Does it generate a log file of some sort? And when it reports memory leaks, does it tell you where in the code those things were allocated?
But how does it work? What does it do? Does it generate a log file of some sort? And when it reports memory leaks, does it tell you where in the code those things were allocated?
MSDN . It uses the debugging output to print the leaks. It also provides some mechanism to track down the memory leaks as it associates an ID to every memory allocation which is also printed out. This ID can be used to identify where the memory was allocated. All in all its a bit long winded i think ;), but it should work.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
