views:

293

answers:

2

Why is an exception being thrown in the "f++" part of the code below ("IndexOutOfRangeException was unhandled by user code"):

for (int f = 0; f < gnf; f++)  
{  
    fieldNames[g] = grid.FieldName(f);  
}

The bug is in the "fieldNames[g] = ..." part of the code, my algorithm should be:

for (int f = 0; f < gnf; f++)  
{  
    fieldNames[f] = grid.FieldName(f);  
}

(This does not crash.) But the debugger is not showing the exception on the "fieldNames[g]..." line when the wrong (top) code runs.

I'm not using threads at this point so I don't see it being one of those "debugging exceptions in a threaded program is suicide" situations.

Why is the debugger showing the exception in the wrong place? Optimizations or something? Has anyone else had the debugger be "wrong" like this before?

+2  A: 

Could be the optimizer. Is your build set to DEBUG or RELEASE?

tvanfosson
My Release build has "Optimize code" set but my Debug build does not. Perhaps I am set to Release mode, which is weird, since I can still to quite extensive debugging!
Jared Updike
You can still debug in a release build.
Judah Himango
Yep, I think that's what's happening. For example, unused variables get optimized away and I can't examine them at runtime...
Jared Updike
+2  A: 

I have experienced similar debugging issue and think such is most usually the debug (pdb) file not being up to date with the code. This may be caused from a number of issues, including

  • The file has been modified, but the compilation of the library did not take place for whatever reason. So the .dll and .pdb file is not up to date with the source code.
  • The .pdb file was out of date because the compilation took place in RELEASE setup
  • The library exists in more than one place on file system, and current solution is somehow set up to look at a different .dll and .pdb file.

This happens ad the debugging information is all stored in .pdb file and if the file is out of date, it will highlight the incorrect line in Visual Studio.

If all projects are in single solution and reference is set up correctly, restarting Visual Studio usually fixes this problem. (For some reason, the compilation may not be taking place correctly and a restart fix this problem - well it appears to be that way to me anyway...)

Samuel Kim