0

I am working with a program that crashes, but only with the release build.

If I use the Local Windows Debugger with the release build, I manage to get a message like this one :

Unhandled exception at 0x0001305FA3B0 in program.exe: 0xC0000094: Integer division by zero.

Is there a way to find what is the instruction at the memory location 0x0001305FA3B0 and more importantly what source file is it located in ?

I also wonder why an integer division by zero would not crash in debug build (if you have an explaination for this one).

Norgannon
  • 487
  • 4
  • 16
  • 1
    If you have a linker mapfile you can at least get near to the code lines. – πάντα ῥεῖ Nov 05 '18 at 13:57
  • 1
    Regarding the division by zero issue, perhaps you have an uninitialized local variable, and in a release build it will happen to be initialized to zero. In reality its value is really *indeterminate* and in your debug builds happen to have a non-zero value. You need to look over all your divisions (direct *and indirect*) and make sure all local variables are properly initialized before used. – Some programmer dude Nov 05 '18 at 14:00
  • I am looking on how to use a mapfile. It looks like it will be helpfull. And about the uninitialized variable, wouldn't the exception be different if it were the case ? But I concur that it is often uninitialized variables that causes issues in release only builds with VC++. – Norgannon Nov 05 '18 at 14:09
  • You should build release build with full debug info. (that is with .pdb file) – user7860670 Nov 05 '18 at 14:29
  • 2
    The default setup on windows (even with release builds) is full debugging information. That means when the application breaks into the debugger it will show exactly what the callstack is and close enough* to the line of code which is at fault. What part of that doesn't already work for you? (*close enough as with optimisations enabled its sometimes hard for the debugger to map back exactly, but it'll be pretty close) – Mike Vine Nov 05 '18 at 14:33
  • I don't think I have a default setup because I cannot even see the call stack. All I can see are memory adresses. – Norgannon Nov 05 '18 at 14:37
  • I found how to enable "Generate Debug Info", I now can see the call stack in release mode ! :D It may sound odd, but I didn't even know we could enable them in a release build until now. – Norgannon Nov 05 '18 at 14:45
  • @Someprogrammerdude I can't seem to find exactly which division fails in my code, but now that I have some more debug abilities on the release build, I see that I am using an object which has many uninitialized variables so I would say that your theory was probably right in the end. Even though the exception is about the division, it would seem that it was an uninitialized variable causing the issue. – Norgannon Nov 05 '18 at 15:20
  • 1
    @Norgannon: While Visual Studio debug builds have the nice property of setting uninitialized variables to recognizable non-zero patterns such as `0xcdcdcdcd`, it does tend to hide divide-by-uninitialized bugs. – MSalters Nov 05 '18 at 15:22
  • @MSalters Is it possible to change this behavior of Visual Studio so that it would also fail in a debug build (preventing a possible issue to go unnoticed for too long) ? – Norgannon Nov 05 '18 at 15:24
  • 1
    @Norgannon: Not directly. Remember, not only should `1/x` fail, but also `1/(x+1)`. Uninitialized variables have _no_ value, logically. However, there's the `/RTCu` (Run Time Check - Uninitialized) build option. It's not perfect, but it does catch quite a few of these errors. – MSalters Nov 05 '18 at 15:39

0 Answers0