I\'ve come across a problem so strange, that I\'ve recorded my session because I didn\'t think anyone would belive me.
I came across a bug that seems to be at very f
I think this looks like a case where the debug stepping ranges are just off. You can't always trust the yellow highlight in the debugger. You're not actually stepping in. In earlier Betas of F# we had lots of bugs like this where the yellow highlight would jump around like crazy. The debugger highlighting is mostly at the mercy of whatever the compiler writes into the .pdb file as the 'source range' that corresponds to a particular compiled set of instructions.
What version of VS/C# is this?
EDIT Having seen other's answers, indeed a likely cause is that your .pdb file is out of sync with your .dll.
I had exactly the same problem week ago. Also have VS2008, latest SP. WinForms application. The value was false but if
body was always executed. I was doing same investigations as in your video. Here is my piece of code:
if (CurrentFileFormatVersion > int.Parse(metaInfo.SimulationFileVersion))
throw new SimulationFormatException(ws, ss);
Running without debugger compiled as 'Release' was fine. Try it.
I suppose there is a bug in VS2008 debugger. Somehow reproducible with 'if' and 'throw' keywords.
EDIT: the 'executed' word above is wrong one of course. 'Stepped in but not executed' must be used instead.
I have seen that many times in the past. Basically what is happening is that the code you are debugging doesn't match the code you are seeing.
I don't know what causes this and the solution follows cargo-cult guidelines.
I've seen a similar case a long time ago, in Delphi, so my question is this: Are you compiling for Release or Debug, with or without optimizations?
The reason I'm asking is that once, during a debug session, I discovered a small procedure that consisted of 4-5 lines of code that, according to the debugger, appeared to be executing in reverse.
Basically, with the following type of code:
procedure Test;
begin
Line1;
Line2;
Line3;
line4;
end;
The execution order, according to the debugger, was this:
procedure Test;
begin start -+
Line1; | +-> here -+
Line2; | +-> here -+ |
Line3; | +-> here -+ |
line4; +-> here -+ |
end; +-> end
The reason was that the lines was side-effect free in between themselves, so the compiler "optimized" the code by rewriting it, in effect rearranging the code to appear to execute fully in reverse.
So, do you have a throw statement further down that is actually the one getting executed, but the compiler shows this as the one you have problems with, because, due to rearranging the code, two throw-statements are actually only emitted once as executable code?
Note: I do not have any reason to know that this is what Visual Studio is doing, but this was what came to my mind when seeing your video.
My guess is that something odd is happening at deployment, so the pdb is out of sync with the actual code. If you use logging instead of the debugger to work out what's going on, I suspect you'll see more sensible behaviour. I doubt that it's the CLR itself behaving weirdly with an "if" - it's much more likely to be a debugger/runtime inconsistency.
Just adding a "me too" here on funky highlighting of code. I'm running VS2008 with C#. I have a Windows Forms project referencing a class library in another project and I'm debugging both line by line. "At some point" the yellow highlight in debug was anywhere from 14 to 20 lines off from the actual line being executed.
I closed VS, opened the directories for both projects, deleted everything from bin/Debug and obj/Debug in both directories, then restarted VS. On recompile and stepping through debug, everything was fine again.
I don't know if the issue was in a .manifest, .pdb, or perhaps a .Cache file. It doesn't matter. Blow um all away and it'll be fine.
FWIW, Googling was nearly useless except that it returned this SO thread. All other hits were about issues with VC++ templates and VS2005, where a SP fixed that problem. This is not the same issue.