How to debug properly and find causes for crashes?

Question

I dont know what to do anymore... its hopeless. I'm getting tired of guessing whats causing the crashes. Recently i noticed some opengl calls crashes programs randomly on some gfx cards. so i am getting really paranoid what can cause crashes now. The bad thing on this crash is that it crashes only after a long time of using the program, so i can only guess what is the problem.

I cant remember what changes i made to the program that may cause the crashes, its been so long time. But luckily the previous version doesnt crash, so i could just copypaste some code and waste 10 hours to see at which point it starts crashing... i dont think i want to do that yet.

The program crashes after i make it to process the same files about 5 times in a row, each time it uses about 200 megabytes of memory in the process. It crashes at random times while and after the reading process.

I have createn a "safe" free() function, it checks the pointer if its not NULL, and then frees the memory, and then sets the pointer to NULL. Isn't this how it should be done?

I watched the task manager memory usage, and just before it crashed it started to eat 2 times more memory than usual. Also the program loading became exponentially slower every time i loaded the files; first few loads didnt seem much slower from each other, but then it started rapidly doubling the load speeds. What should this tell me about the crash?

Also, do i have to manually free the c++ vectors by using clear() ? Or are they freed after usage automatically, for example if i allocate vector inside a function, will it be freed every time the function has ended ? I am not storing pointers in the vector.

--

Shortly: i want to learn to catch the damn bugs as fast as possible, how do i do that? Using Visual Studio 2008.

Answer 1

A "random" crash that occurs sometime after a complex operation is almost certainly the result of heap corruption. Heap corruption bugs are a bitch, since they usually manifest themselves very far away from the place that actually caused the bug. My suggestion, since you're on Windows, is to use Application Verifier, which can be freely downloaded from MS.

Launch AV, configure it to watch your program, and turn on all of the memory-related options. Then run your program under a debugger. (These two things will make your program run extremely slow.) The extra checks that AV does will hopefully cause your program to crash at a different place than you've been seeing so far, but it will be the location that's the real cause of the bug.

Answer 2

Most likely you are getting memory corruption. You'll want a memory debugger to track this down; you can find recommendations here.

I have createn a "safe" free() function, it checks the pointer if its not NULL, and then frees the memory, and then sets the pointer to NULL.

Checking for NULL is not necessary because a standard conforming free (which VS2008 is) will do that check for you. It's still possible to free a junk pointer which can cause problems.

As for setting the pointer to NULL, that can help but it is not a panacea. First off, you may not be setting the correct pointer to NULL. For example, if you do this:

void myfree(void *ptr)
{
    free(ptr);
    ptr = NULL;
}

all you have done is set the local parameter of myfree to NULL. The caller's copy of pointer is still left untouched.

Answer 3

Like said earlier, this is most probably a memory leak somewhere.

Visual Studio has built-in tools for this

Basically you take two snapshots of the memory and compare them at some time

Answer 4

First question, why are you using free() in C++? Normally you should use new/delete for memory management, or better new combined with smart pointers.

You don't have to manually clear() the vectors. Keep in mind that if you store pointers to objects in the vector (which isn't necessarily good practise, there are better containers for that), you will have to destroy them individually before the vector is destroyed. As you said you're not storing pointers in the vector, the vector will be destroyed when it goes out of scope - ie the containing object is destroyed or the program leaves the scope inside a function.

Random crashes are usually/often memory bugs, I would recommend you outfit yourself with a good memory debugger. On Windows that usually means Rational Purify or Boundschecker. Of course it helps to find out what triggered the crash in the first place - not handling an out of memory condition? Null pointer derefence? Cosmic rays?

Given the response to the comments in your question, here's what I would do:

• Change the VS2008 exception interception such that it'll break on an access violation
• Run your program under the debugger, in debug mode - don't try to debug the release executable
• Try to reproduce the behaviour you're seeing. It'll take longer than in release mode, but you should get there eventually. You'll probably also get a few false positives.
• If you have a good idea which (null) pointer gets dereferenced, assert() the pointer and run the program in the debugger again.

Answer 5

Pay attention to Noah Roberts' and JS Bangs' point - if you're not familiar with a debugger, it sounds like it's time for you to become familiar.

I'd also suggest a valgrind-like tool - see this SO question.

Also, do i have to manually free the c++ vectors by using clear() ?

No.

Answer 6

You really need to learn to use the debugger. Press the play button at the top, or use the remote debugger features if necessary. If you can't track it down that way, then drwtsn32 is an option as well.

Answer 7

"I cant remember what changes i made to the program that may cause the crashes, its been so long time. But luckily the previous version doesnt crash, so i could just copypaste some code and waste 10 hours to see at which point it starts crashing.."

This is why Test-Driven Development (TDD) rocks. Read up on it and see how it can help you avoid these scenarios.