Code Profiling and Memory Leaks

[macleod1021]

Can I get some recommendations (and pros/cons if you have time) of the code profiling and memory leak test tools you use? I would prefer free (or close to it) because I have to foot the bill for it .

Thanks in advance.

 

[Salem]

What tools do you have to start with?
VC6 professional (for example) comes with a profiler.


--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.

 

[macleod1021]

At the moment, I'm using dependency walker and process monitor heavily. I've been messing around with other little tools within Visual Studio 6...but not enough to say that I "use" them. I've also found a couple on various code boards that seem OK, but again...not a lot of experience with one in particular.

I'm trying to get a couple of recommendations that I should learn so that I'm not spending time learning one and then discovering that this other tool works more efficiently/accurately than the one I learned.

 

[Salem]

Microsoft include a number of memory debugging routines.

http://msdn2.microsoft.com/en-us/library/1666sb98(VS.80).aspx

By enabling this feature, you can run the program then arrange for [tt]_CrtDumpMemoryLeaks()[/tt] to be called at the end. This will contain a record of all the leaks.

From within the debugger, do these things:
Included in this information is an "allocation number", which can be used to initialise a variable ([tt]_crtBreakAlloc[/tt]) with the number of the first leak.

Run the program with exactly the same inputs and it should break on the first block which will leak. You can then track back into your code to see where the pointer is allocated and used, and from that determine who should be responsible for calling free()

Having fixed the first leak, which may fix a whole host of other leaks as well, then re-run your tests to find out the next leak.

As for the profiler in Visual Studio professional, I would suggest you create a small test program (say up to 10 functions) and practice with all the various options it has available. Correctly interpreting what the reports are trying to tell you is a bit of an art, so having some ideas from code you're totally familiar with will help.

> so that I'm not spending time learning one and then discovering that this other tool
> works more efficiently/accurately than the one I learned.
It's like choosing a car, you have to test drive several to really figure out which is best for you.



--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.

 

[macleod1021]

Thanks for the help. I agree with your car analogy, but it's nice to check out "Tek-Tips Reports"