4

I've been trying to debug a subtle memory problem in a large project. It's been weeks and I still haven't been able to find it. My program crashes randomly after running for a certain amount of time. As a result, I've been trying to obtain a memory debugger of sorts. Here are the options I have considered/tried:

  • IBM Purify - successfully detects memory leak but asks for me to pay money to find out where it is
  • Valgrind - I've heard good things about this program but it's for Linux and I'd have to port my entire project over
  • MPatrol - again it's mainly for linux. The windows version is for MingGW and I'm using Visual Studio. I found binaries for VC++ online and followed the instructions there but the program refused to output any log files.
  • Application Verifier - throws a random break point at start, asks for a nonexistent source file (sdk.cpp) in Visual Studio, and then gives this error every time, no matter what exe I attach it to: "First chance access violation for current stack trace"
  • WinDbg - I don't even know if this program does what I think it does. Always gives "ERROR: Symbol file could not be found." And it doesn't seem to do anything when I run my exe.

I've searched for all these errors on Google for hours to no avail. The respective documentation on these packages don't seem to have info on my particular issues. Is there any debugger out there that works? Do I really have to port my program over to Linux? Can anyone point me in the direction of good documentation regarding memory debugging? Any help would be greatly appreciated. Thanks in advance!

Edit:

Thanks for all the replies. I realize that the crashing problem is probably not a memory leak. After running for a while, it just freezes. There's no error message. Usually it happens while writing to cout. So thus I figured it was memory corruption of some sort. I guess I'll look into more in-depth features of visual studio. Actually using the trial of Purify I found a few bugs but I don't want to cough up $1600 for the full version. Worst case scenario I'll port it to Linux. Thanks again for the help.

Edit 2:

After some more testing with Purify, it appears that my program doesn't have any more memory errors. I noticed that the program freezes when I click on it, as in the command prompt itself. Thus I'm going to assume that it's not a problem with my code, but rather the way it interacts with having text selected. (Edit 2a: selection is supposed to do that facepalm) Thanks again for all the help.

For future reference, where do I go to learn about more sophisticated debugging? I've used breakpoints and watch expressions but at school they only teach the language itself. Do I need to learn x86 assembly?

JDC
  • 89
  • 2
  • 5
  • There are a few tools, such as the executable flagging one (for checking page/heap use and whatnot) in the WinDDK that are pretty much the most powerful debuggers on any system. Even WinDbg certainly does work, and is one of the better ones wrt features/power (I'd put IDA pro above it, perhaps OllyDbg next). It's not easy to work with, though; symbol files usually refer to either your code's debug symbols or ones from system libraries you don't have. Well worth going through the DDK for some of the non-debugger memory debugging tools. – ssube Nov 04 '11 at 05:31
  • see http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows/6580332#6580332 – rve Nov 04 '11 at 07:30
  • You forgot to mention the size of IBM Rational PurifyPlus. It is 201Mb for Windows. I find it relatively large comparing to Visual Studio itself. – SChepurin Nov 04 '11 at 09:11
  • Hmm I'll have to look into WinDDK. As for Purify, I don't mind the file size so long as it works. – JDC Nov 06 '11 at 00:41
  • If all else fails, you can always start playing hide-and-seek with the bug... #ifdef out a part of the program, see if the bug goes away... if it does, then the bug might be in the commented code; if not, it's probably somewhere else. Repeat until you find the bug or go insane :) – Jeremy Friesner Nov 06 '11 at 02:12
  • I've been trying that, but the problem is that the bug is not consistent. It can run for 4 hours without freezing, or 30 seconds. I never know when it will happen. – JDC Nov 06 '11 at 03:32
  • I used quite successfully both WinDbg and AppVerifier. Both should work just fine even if you don't supply them with the symbols file (.pdb) nor source code files, but, of course, it's hard to debug without symbols and source code. You should tell exactly what you did and observed, step by step (screenshots will help even more) for others to be able to help you. The reason why you may not hit the crash when running the app in a debugger is simple... The app has a different memory configuration (addresses) and memory contents when it starts. It may be a case of Heisenbug. – Alexey Frunze Nov 06 '11 at 07:33

4 Answers4

3

Visual Studio includes memory leak detection in the debug version of the C libraries. See this page on MSDN for information.

But you don't seem to be sure that the crash is due to a memory leak. In fact, memory leaks won't typically cause crashes (unless the crash occurs because the system runs completely out of memory). You may very well have leaks, but those could be unrelated to the crash.

Have you tried looking at the crash with the VS debugger? Many times that will give you an idea of what kind of problem you are facing. If you get crashes I suspect you are more likely to be corrupting memory, for example by writing past the end of an allocated memory block, or by using memory after it was released.

This article has some ideas on how to approach memory problems, and this page lists some free and commercial memory debuggers, some of which are not in your list.

Good luck.

Miguel Grinberg
  • 65,299
  • 14
  • 133
  • 152
1

I use Visual leak detector. It detects memory leaks and gives you the call stack for them. It works with visual studio, and is pretty reliable. You can take it from here - http://vld.codeplex.com/
I don't know if this is exactly what you are looking for, but it's useful.

Jan S
  • 1,831
  • 15
  • 21
  • 3
    Leaks don't cause crashes (well, unless it's OOM-related, I guess). Memory corruption does. – Cat Plus Plus Nov 04 '11 at 05:18
  • 1
    OTOH tracking down any memory leaks might give you a clue as to where the memory corruption is coming from... the same bug can often cause both symptoms. – Jeremy Friesner Nov 06 '11 at 02:19
1

OllyDbg is not on your list and is great

edit: deep into search shows something free that lets you monitor heap of process in a simpler way than a traditional debugger on windows based systems.

Joe McGrath
  • 1,481
  • 10
  • 26
  • 1
    he already has the Visual Studio debugger. What would be the benefit of using Olly? Neither is specifically tailored to finding memory problems. – Miguel Grinberg Nov 04 '11 at 05:33
1

Perhaps Gdb and Valgrind have been ported to Windows?

And if your application is not specific to windows, or uses libraries (like e.g. Qt) which have been ported on both Windows and Linux, you might consider debugging it on Linux.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • I've searched for a windows Valgrind port and haven't found anything. I know about and have used the windows version of GDB but not in a lot of depth. I'll have to check it out thanks. – JDC Nov 06 '11 at 00:40