Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I was looking into Valgrind to help improve my C coding/debugging when I discovered it is only for Linux - I have no other need or interest in moving my OS to Linux so I was wondering if there is a equally good program for Windows.
As jakobengblom2 pointed out, valgrind has a suit of tools. Depending which one you are talking about there are different windows counter parts. I will only mention OSS or free tools here.
1. MemCheck:
Dr. Memory. It is a relatively new tool, works very well on Windows 7. My favorite feature is that it groups the same leaks' allocation stacks in the report.
http://code.google.com/p/drmemory/
I have also used UMDH( http://support.microsoft.com/kb/268343 ) and found it quiet useful and easy to setup. It works from Win2000 to Win7.
AppVerifier is a must have swissknife for windows native code developers, its "memory" checker does similar job
http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx
2. Callgrind:
My favorite is verysleepy ( http://www.codersnotes.com/sleepy ) It is tiny but very useful and easy to use.
If you need more features, AMD CodeAnalyst™ Performance Analyzer is free:
http://developer.amd.com/documentation/videos/pages/introductiontoamdcodeanalystperformanceanalyzer.aspx
Windows Performance Analysis tools is free from Microsoft, not very easy to use but can get the job done if you are willing to spend the time. http://blogs.microsoft.co.il/blogs/sasha/archive/2008/03/15/xperf-windows-performance-toolkit.aspx
Download:
http://msdn.microsoft.com/en-us/performance/cc752957
3. Massif:
Similar(not quite exact match) free tools on windows are:
VMMap from sysinternals : http://technet.microsoft.com/en-us/sysinternals/dd535533
!heap command in windbg : http://hacksoflife.blogspot.com/2009/06/heap-debugging-memoryresource-leak-with.html
4. Cachegrind:
Above mentioned Windows Performance Tools has certain level of L2 cache miss profiling capability but not quite as good and easy to use as Cachegrind.
5. DRD:
Haven't found anything free and as powerful on Windows yet, the only free tool for windows I can find that is slightly close is the "lock" checker in
AppVerifier:
http://msdn.microsoft.com/en-us/library/dd371695%28v=vs.85%29.aspx
Why not use Valgrind + Wine to debug your Windows app? See
http://wiki.winehq.org/Wine_and_Valgrind
(Chromium uses this to check the Windows version for memory errors; see
build.chromium.org
and look at the experimental or memory waterfalls, and search for wine.)
There's also Dr. Memory, see
dynamorio.org/drmemory.html
Some more good commercial tools:
Purify
Insure++
For Visual C++, try Visual Leak Detector. When I used it, it detected a memory leak from a new call and returned the actual line in source code of the leak. The latest release can be found at http://vld.codeplex.com/.
Development environment for Windows you are using may contain its own tools. Visual Studio, for example, lets you detect and isolate memory leaks in your programs
i would like to list some tool , hope will be useful
read this article for more detail
Purify
Bounds Checker
Coverity (basically its a code analyzer but, it will catch memory leak in static )
Glow Code
dmalloc
ccmalloc
NJAMD
YAMD
Valgrind
mpatrol
Insure++
Try DUMA
There is Pageheap.exe part of the debugging tools for Windows. It's free and is basically a custom memory allocator/deallocator.
See http://support.microsoft.com/kb/286470
In combination with Visual Studio I generally use Visual Leak Detector or simply _CrtDumpMemoryLeaks() which is a win32 api call. Both are nothing fancy but they get the job done.
I had the chance to use Compuware DevPartner Studio in the past and that was really good, but it's quite expensive.
A cheaper solution could be GlowCode, i just worked with a 5.x version and, despite some problems in attaching to a process i needed to debug, it worked quite well.
I've been loving Memory Validator, from a company called Software Verification.
Viusual Studio can help detecting memory leaks itself. See Microsoft Visual C++ Tips and Tricks -> "Memory Leaks" section.
See also this post in SO
Although real tracing is only possible with the Team Edtion of Visual Studio.
See the "Source Test Tools" link on the Software QA Testing and Test Tool Resources page for a list of similar tools.
I've used BoundsChecker,DevPartner Studio and Intel V-Tune in the past for profiling. I liked V-Tune the best; you could emulate various Intel chipsets and it would give you hints on how to optimize for that platform.
Does Jochen Kalmbach's Memory Leak Detector qualify?
PS: The URL to the latest version is buried somewhere in the article's comment thread.
LeakDiag, UMDH, App Verifier, DebugDiag, are all useful tools to improve robustness of code and find memory leaks.
The Boost Test library can detect memory leaks.
How about the Purify?
Try Intel's Inspector XE product which can help you detect both memory and threading issues: http://software.intel.com/en-us/articles/intel-inspector-xe/
Perhaps CodeSnitch would be something you're after? http://www.entrek.com/codesnitch.html
If you are developing with Borland/CodeGear/Embarcadero C++ Builder, you could use CodeGuard.
More or less all Profilers include checking for memory leaks and show you the stack when the memory was allocated.
I can recommend Intels Parallel Inspector. Simple to use and no recompilation needed. The trial version runs for 30 days.
GlowCode and AtromatedQA also include such capabilites. They all offer free trials.
Compuware DevPartner (aka BoundsChecker) in Contrast needs a slowed down "instrumentation" recompile and the application also runs slower when checking for errors. And BoundsChecker can not work with 64 Bit evsrions at all. We gave up on that tool.
The best tool I ever used is DevPartner BoundsChecker - it's not free but it has an evaluation period.
Another memory tool for your list: Memory Validator.
Not free, but nowhere near as expensive as Purify or Boundschecker.
If you're not afraid of mingw, here are some links (some might work with MSVC)...
http://betterlogic.com/roger/?p=1140
We are just completing a Memory Safety checking tool for Windows, that handles GCC and Micrsoft Visual C (not C++ yet), and are looking for Beta testers.
EDIT June 12, 2011: Not Beta anymore, now production for GCC and Microsoft Visual Studio C.
I found this SF project today:
http://sourceforge.net/p/valgrind4win/wiki/Home/
They are porting valgrind to Windows. Probably in several years we will have a reliable valgrind on windows.
Check out this question: Is there a good Valgrind substitute for Windows? . Though general substitute for valgrind is asked, it mainly discusses memory leak detectors and not race conditions detections.
I used Insure++ which does excellent job in finding c++ memory leaks/corruptions and many other bugs like uninitialized variables, pointer errors, strings etc., It also does visual "Code coverage" and run time memory usage etc.. which give more confident on your code.. You can try it for trail version..
You might want to read what Mozilla is doing regarding memory leaks. One tool in their toolbox is the Hans Boehm garbage collector used as memory leak detector.
You can give a try to RuntimeChecker trial ot to IBM Purify trial..
A free solution would be to use the following code in Visual Studio:
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Just write this in the top of all your cpp files.
This will detect memory leaks of your application whenc stopping debug run and list them in the output window. Double clicking on a memory leaks line will higlight you the line where memory is allocated and never released. This may help you : http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
How to debug mingw built binaries to detect heap errors? I see there are several questions on the topic, but they are general and it's hard to find the tool that would work well with MinGW. I spent much time on finding the solution, I hope the combined topic will be helpful.
Such a tool becomes necessary when for example someone reports a bug in your library while running it under Visual Studio debugger, which stops with a "Heap Error".
There is a tool provided by Microsoft called Application Verifier. It is a gui tool that changes system settings to run selected applications in a controlled environment. This makes it possible to crash your program if it causes detectable memory errors. This is a controlled crash that can be debugged.
Fortunately it is obtainable from Microsoft as a separate download. Another way to get it is to have Windows SDK installed with checked Application Verifier checkbox. SDK offers also an option Application Verifier redistributable.
After you configure Application Verifier to have an eye for your app, you need to debug it. Debugging under MinGW is a more common subject, already explained on stackoverflow. [mingw] [debugging] query on stackoverflow gives interesting articles. One of them is How do I use the MinGW gdb debugger to debug a C++ program in Windows?. Gdb is the one I used.
The general questions How to debug heap corruption errors? and Heap corruption detection tool for C++ were helpful to find this tool, but I wasn't sure if it is compatible with MinGW. It is.
After Google the issue i found that it was reported already but nothing useful yet from MS. I wonder if any one found a work around it?
Another option is to use windbg. You'll have to do a lot of commands by hand, but it's the best debugger out there. It handles mixed mode without any major issues. It has a bit of a learning curve, but it's very versatile.
Visual Studio's debugger is really not reliable when debugging mixed mode applications. Taken from my answer here #5965771:
If you're trying to debug a piece of native code try to use a native project as the debugger start-up application. Under the project settings, "Debugging" tab set the "Debugger Type" to "Mixed", for us this helped sometimes (the native project can be a DLL for example, simply set your main Exe as debugging target in the project settings);
OR, as already mentioned in another answer: Use WinDbg! With it you can debug both managed/unmanaged mixed code applications much more reliably.
use a different debugger, or don't use the debugger at all, just trace to a file or insert breakpoints in the code with inline assembly language.
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
I've just gotten an application to compile and run by telling my VS 2008 project to ignore libc.lib in the linker->input section off the project properties menu. Before I did this VS gave me the old "fatal error LNK1104: cannot open file 'LIBC.lib'" message.
I'm not sure how this app compiles if I'm ignoring the crt, but that's obviously my ignorance speaking.
I checked the C/C++ project settings and the runtime library setting reads multithreaded debug dll (/MDd flag)-- so I must be linking to a VC80*.dll somewhere.
I'm not sure how though. I've always been confused about the crt settings in visual studio, static or debug, multithreaded or not. From reading this site and google I have a rough improvement in my understanding now-- if you use the dlls you don't have as much code bloat, things link when the program needs them, crt updates can be applied by overwriting the dll. The usual reasons for using a dll in other words.
But what's with the multi-vs-single threaded versions? If I happen to link with a static version I can't use win threads or pthreads, is that what that means?
One other thing which I've heard about but never quite followed-- there are problems in allocating an object in one dll and deallocating it from another, or something like that, to do with cross-allocation. I'm not explaining that well (because I don't understand it) but I hope you get my point and can explain what's going on there. Does it mean that in my program I can't call new ObjectX() on a class that lives in a dll? Can't mean that, can it?
Thanks everyone!
But what's with the multi-vs-single threaded versions? If I happen to link with a static version I can't use win threads or pthreads, is that what that means?
There is no (native) pthreads in Windows - so it's more Windows Threading, but that's the basic idea. However, VS 2008 doesn't support the single-threaded versions - they have been dropped, so if you're using VC++ 2008, you'll always use the multi-threaded VC++ runtime libraries.
One other thing which I've heard about but never quite followed-- there are problems in allocating an object in one dll and deallocating it from another, or something like that, to do with cross-allocation. I'm not explaining that well (because I don't understand it) but I hope you get my point and can explain what's going on there. Does it mean that in my program I can't call new ObjectX() on a class that lives in a dll? Can't mean that, can it?
This is more of an issue with allocating objects in a DLL which was compiled with a different VC++ runtime than the calling project. If you compile a DLL with VS2005, then try to do "new MyClass();" within a VC 2008 project, you can run into problems.
This is due to changes that are made between VC++ runtime versions. Different versions are free to manage memory allocations and deallocations in their own way. Trying to allocate or delete across a "runtime library" boundary tends to cause bad things to happen - quite often, you get crashes.