what to do if debug runs fine, but release crashes

Question

I have an application that runs just fine in the debug build, but when I start it in the release build, I get a

unhandled Exception at 0x0043b134 in myapp.exe: 0xC0000005:
Access violation while reading at position 0x004bd96c

If I click on 'break' it tells me that there are no symbols loaded and the source code can't be displayed.

What can I do in such a situation to track down the problem?

Answer 1

Track down the problem inserting log output here and there right from the beginning of the main function.

Answer 2

If it is not a memory issue, then you have to enable asserts in the release. For memory issues, I hope you got good unit tests. You can easily catch such problems with valgrind.

btw why are people disabling asserts in the release version? In 99% cases they do not cause performance problems, and are good in detecting errors.

Answer 3

I had this problem, release/debug worked fine inside visual studio, debug work stand alone, but release crashed stand alone. Debugging was not particularly accurate for me, my solution was:

Comment out most of the code, then build, test, uncomment, repeat, until you find the section that causes the crash.

In my case it was passing a pointer to an array that was too small to a function.

Answer 4

Two steps:

a) Build release build with debug symbols (possible with VS at least)

b) Build release build without optimization

If the problem still happens, it is very good and easy to fix. It is almsot as if the problem is in debug build.

If the problem happens with optimization settings on, then it is really tough and has to be handled in situation specific manner.

Answer 5

Take a crash dump using Microsoft debugdiag on windows(it's free) and analyze the dump using the same. It gives a nice call stack for the function where it crashes. Although, if it keeps crashing all over the place, it could be an issue of heap corruption. You then need to use global flags(or gflags which is a part of microsoft tools for debugging suite which is free) in conjunction with debugdiag. Gflags would give you the location where the heap is actually getting corrupted. Hope that helps.

Answer 6

This kind of problem is often due to unitialized variables. I'd start there looking for your problem.

Debug mode is more forgiving because it is often configured to initialize variables that have not been explicitly initialized.

Perhaps you're deleting an unitialized pointer. In debug mode it works because pointer was nulled and delete ptr will be ok on NULL. On release it's some rubbish, then delete ptr will actually cause a problem.