Hey there!
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 symboles loaded and the sourcecode can't be displayed.
What can I do in such a situation to track down the problem?
thanks!
It could be two things:
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.
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.
Track down the problem inserting log output here and there right from the beginning of the main function.
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.
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.
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. i.e., 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.
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.