CppCheck – leak tool

[Anonymous]

http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page

putting this through its paces at the moment. So far, so good.

B.

[Anonymous]

Nice… Been using _CrtDumpMemoryLeaks() myself for ages but I guess that’s not an option if you’re not using VC++.

[Anonymous]

VLD is pretty good little library for finding heap leaks also.

One include file, one lib, and your good to go. Outputs leaks to the console window in the IDE.

http://dmoulding.googlepages.com/vld

Free too.

B.

[Anonymous]

+1 for the Visual C++ CRT leak detection routines; though I’d suggest

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)

at the start of the program rather than

_CrtDumpMemoryLeaks()

at the end, since globals/statics/etc will be torn down after main returns/atexit routines run and will appear as leaks. Couple of hours of hair pulling saved there hopefully :)

[Anonymous]

+1 for the Visual C++ CRT leak detection routines; though I’d suggest

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)

at the start of the program rather than

_CrtDumpMemoryLeaks()

at the end, since globals/statics/etc will be torn down after main returns/atexit routines run and will appear as leaks. Couple of hours of hair pulling saved there hopefully :)[/quote:5cde6b562d]

Good point. I only found this out myself for the first time after stepping through the assembly prior to main(). :)

Unfortunately however, there’s another ‘gotcha’ in store even if you use this method. I’ve noticed certain STL containers (in their VC++ incarnations at least) will hold onto memory even after they have been cleared and even after reserve(0); has been called etc.. This will cause a leak detection since the amount of memory allocated for the container at shutdown will be greater than at startup. AFAIK I had this problem with std::vector, std::map and std::string seemed to be ok. I don’t think i’ve ever had global std::list objects so I don’t know what the situation is with those..

My dirty/hack way around this is to forceably delete and recreate the object using place new and delete. So for instance:

std::vector<int> my_vector; // a global vector; constructed before main() by vc-runtime

void cleanup_vector()
{
my_vector.~vector(); // call destructor directly. force cleanup of memory
new (&my_vector) std::vector<int>(); // recreate in case it is used again
}

If you do the above then you can force std::vector to cleanup after itself and release all memory it has pre-allocated. It aint pretty and the OO code police won’t like it, but it does the job; the most important consideration in my book. :P

[Anonymous]

Haha!

Actually those shouldn’t be reported as leaks with CrtSetDbgFlag; that was exactly the problem I was tracking down (this with Visual C++ 2008)- std containers at global level (and also boost shared pointers at global level). All of the destruction has already happened by the time the CRT prints the leak report (I also did exactly the same thing: trying to force all stl containers to free before calling CrtDumpMemoryLeaks, but it doesn’t work for std::list since that always allocates, even if the list is empty- I don’t know what exactly, since I’m not bothered to crack open the book; possibly a head node or something like that). Also: it’s a huge pain in the ass.

The "correct" way (it says something about the stl that something obscure is the correct way) to force an stl container to release allocated memory is to swap() it with an empty version of itself. Like I said, doesn’t work for list though.

[Anonymous]

guys,

I dont have a compiler on hand at the moment, but I’d recommend trying that same problem with VLD and see if that helps.

B.

[Anonymous]

Sorry: I get wordy and it can be unclear what I’m saying.

The efficacy of the Visual C++ CRT leak detector is not in question as far as I’ve seen; the problem mentioned above is the result of using it wrong. Storage allocated for STL containers at global scope is freed after main returns and atexit functions have run; therefore an explicit call to CrtDumpMemoryLeaks in either of those places will see that memory as still allocated and report a leak. If you place a call to CrtSetDbgFlag (with the aforementioned flags) at the start of your program and don’t make any explicit call to CrtDumpMemoryLeaks, then the CRT will dump leaks automagically at the appropriate point AFTER global STL container allocations have been freed; so no leaks are erroneously reported.

I can imagine situations where the extra information provided by VLD could be useful; but you don’t need it to address this issue.

[Anonymous]

Haha!

Actually those shouldn’t be reported as leaks with CrtSetDbgFlag; that was exactly the problem I was tracking down (this with Visual C++ 2008)- std containers at global level (and also boost shared pointers at global level). All of the destruction has already happened by the time the CRT prints the leak report (I also did exactly the same thing: trying to force all stl containers to free before calling CrtDumpMemoryLeaks, but it doesn’t work for std::list since that always allocates, even if the list is empty- I don’t know what exactly, since I’m not bothered to crack open the book; possibly a head node or something like that). Also: it’s a huge pain in the ass.

The "correct" way (it says something about the stl that something obscure is the correct way) to force an stl container to release allocated memory is to swap() it with an empty version of itself. Like I said, doesn’t work for list though.[/quote:a066807a54]

Ah.. I stand corrected. Cheers for the info.

guys,

I dont have a compiler on hand at the moment, but I’d recommend trying that same problem with VLD and see if that helps.

B.[/quote:a066807a54]

Gonna give this a go tonight with VLD and see what happens in this situation.

[Anonymous]

Been meaning to post this for a while, in the spirit of "sharing is caring."

[code:1:d23ff058bc]
//
// File Name : LeakDetector.h
//

#if !defined(_LEAK_DETECTOR_H__)
#define _LEAK_DETECTOR_H__

// Library Includes
#include <crtdbg.h>

//
//
//
class CLeakDetector
{
// Members
public:
//

protected:
//

private:
_CrtMemState m_checkpoint;

// Methods
public:
CLeakDetector();
~CLeakDetector();

protected:
//

private:
CLeakDetector(CLeakDetector& _rhs);
bool operator=(CLeakDetector& _rhs);
};

#endif // _LEAK_DETECTOR_H__
[/code:1:d23ff058bc]

and

[code:1:d23ff058bc]
//
// File Name : LeakDetector.cpp
//

// Library Includes
#include <Windows.h>

// This Include
#include "LeakDetector.h"

/**
*
* Default constructor which populates the CrtMemState struct
*
* @author B.B.
*
*/
CLeakDetector::CLeakDetector()
{
_CrtMemCheckpoint(&m_checkpoint);
}

/**
*
* Destructor, which displays the Crt difference
*
* @author B.B.
*
*/
CLeakDetector::~CLeakDetector()
{
_CrtMemState checkpoint;
_CrtMemCheckpoint(&checkpoint);

_CrtMemState diff;
_CrtMemDifference(&diff, &m_checkpoint, &checkpoint);

OutputDebugStr("\n*****************************************");
OutputDebugStr("\n**********| MEM LEAK DETECTOR |**********");
OutputDebugStr("\n*****************************************");

_CrtMemDumpStatistics(&diff);
_CrtMemDumpAllObjectsSince(&diff);
}
[/code:1:d23ff058bc]

and then this:

[code:1:d23ff058bc]
//
// File Name : main.cpp
//

// Library Includes
#include <iostream>

// Local Include
#include "LeakDetector.h"

// Static Variables
static CLeakDetector g_sLeakDetector;

// entry point
int
main(int _argc, char* _argv[])
{
std::cout << "Before the alloc.\n";

int* pInt = new int;
float* pFloat = new float;
char* pChar = new char;

std::cout << "After the alloc.\n";

// pInt should be deleted here.

delete pFloat;
pFloat = 0;

delete pChar;
pChar = 0;

return (0);
}
[/code:1:d23ff058bc]

B.

[Author]

Posts