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

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.

Answer 2

It could be two things:

• One or more of your assertions does necessary work apart from the check itself
• Something else

To rule out the former, try redefining assert as an empty operation in the debug build. If the absence of some assertion causes the crash, you will see it. Otherwise, it's something else.

Also, I assume you have version control. Did this just start happening? You can analyze the code changes from last week.

Finally, even in the absence of a crash in debug mode, running a memory checker tool may be useful to spot incorrect memory access.

Answer 3

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 4

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 5

Are you sure that both releases use the same .dll ? I spend an hour wondering why my program did compile in debug mode but not in release mode and I just forgot to update the dll's in the release folder.

Answer 6

从main功能的开头一直跟踪到此插入日志输出的问题。

Answer 7

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 8

For me, the problem was that a constructor was initializing 2 member variables in the wrong order. ie not the same order that they were declared in.
I'm surprised that initialization order actually makes any difference.

Answer 9

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 10

Without looking at the code, it is hard to tell what is bad. All the above suggestions are good and helpful but what I have found most helpful fixing this kind of things is to run certain parts of program in chunks. ie, comment out a lot of code/functionality and then run the program and see if it crashes. If it doesn't, the uncomment some functionality and then re-run again and so on. This way you will be able to narrow down the problem to the exact code that is causing this.

In most of the cases this happens due to some Buffer overruns which Debug builds can guard against.