tags:

views:

269

answers:

6

Hello,

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 fundamental level. This is a single threaded application and all im doing is evaluating a boolean.

The boolean equals false, however, the if statement is executing as if it were true...sort of. You'll see what I mean. I've cleaned the solution and rebuilt many times. No idea whats going on.

I'd love some explanations please.

http://www.youtube.com/watch?v=ope9kxEyt4g

+6  A: 

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.

Jon Skeet
I have cleared the bin folder myself, we are talking about a fresh build. I like the idea of putting in debugging statements to see what's going on. I will try this. Thanks Jon.
Vince
Second that. Debugging the ASP.NET application I'm upgrading sometimes throws off debugger a bit. The simplest example is when you insert some code in a method, start debugging and see that those lines are never executed - they are just jumped over. Or when debugger highlight one line but actually executes the following one.Deleting obj/ and bin/ folder always helps me.
Audrius
A: 

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.

Brian
I will try clearing out the obj files and all other temp and generated files when I go back to work on Monday. I will keep you all posted.
Vince
I'm using .NET framework 3.5 and VS2008
Vince
+7  A: 

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.

  • Close all copies of Visual Studio
  • Delete all of your bin and object folders for this project
  • Delete all of your bin and object folders for all .NET projects
  • Delete all the files yo find in "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files"
Jonathan Allen
don't forget to sacrifice a goat (for good measure)!
Mitch Wheat
I've deleted all files in the bin folder, I totally forgot about obj and the temporary asp files. Will give that a shot. I still don't understand why hardcoding a false generates the desired outcome or why putting in an else statement fixes the problem.
Vince
Sorry I had to vote down your answer, however it turns out doing all those things still has not fixed the issue. I've deleted all bin folders, Obj folder, all temporary asp files both x86 and x64 and still the same issues.
Vince
Bummer. Let me know if you find another answer.
Jonathan Allen
A: 

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.

Vasiliy Borovyak
Was the if-block really executed or was it just highlighted by the debugger? In Vince's video it seems the code is not executed (the exception object e is null).
0xA3
Not executed as in video.
Vasiliy Borovyak
+4  A: 

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.

Lasse V. Karlsen
A: 

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.

TonyG
I gave up on this problem. I tried everything, I cleared all DLL's from Temporary internet files, all local files in Bin and even moved the solution to another PC. The problem seems to be in the debugger and not sure why.
Vince