views:

841

answers:

9

I just ran into one of the most mind boggling errors ever. false == true What information would you guys need to confirm/debug this behavior? I've never seen anything like it.

http://imgurl.filetac.com/img/39400910.png

  • VS2008 sp1
  • Debug Mode | Any Cpu
  • IIS 7.5

Edit: I did a clean->rebuild and still the same.

Here's the assembly and registers. I don't know how to read this, but maybe it could help someone else.

http://imgurl.filetac.com/img/39411230.png http://imgurl.filetac.com/img/39411230.png

+19  A: 

I suppose your PDB files are not in phase and you have differences in what's really executed and what Visual Studio sees as a line number. Try rebuilding. We all know that it is impossible to have true = false, or the world as we know it may change :-)

Darin Dimitrov
The cosmological constant is fluctuating on his wkstn...
Charles Bretana
Back in VB6 I actually had `true = false`. During that same debug session, all error handling failed, execution passed through every possible branch of every `if` statement, and the sky went dark as angels fell from the heavens... Had to reinstall VB 3 times that day; never did figure out what caused it... Ah, the good ol' days...
Rory
« or the world as we know it may change » → Maybe someone found the Question ?! :o
Pikrass
@Rory - Remember how much fun VARIANT_BOOL was from the C++ side?
dkackman
+4  A: 

Probably the source does not correspond to the running version or there's a bug in the debugger.

Mehrdad Afshari
+2  A: 

Are you sure that's the exception being thrown? My hunch is that your method isContextSignatureValid is actually throwing an exception, but the Visual Studio debugger can get ahead of itself sometimes and highlight a line that is not actually throwing the exception.

womp
+5  A: 

Does it actually throw the error? The debugger can often highlight the wrong lines if you feed it the wrong pdb, so this could be a false lead. It is also trivial to reproduce using the "immediate" pane to change the value after the test.

If result was a field or a captured variable, it could also be set by external code (perhaps on another thread).

If result wasn't a bool but your own custom type, you could just override ==, or provide a custom true/false operator.

Marc Gravell
You're right that it doesn't throw the exception on the next line. So it seems that the debugger is reading a different pdb.
Arron
+3  A: 

Part of the problem is that you're assuming the debugger is 100% correct. It in fact is not and is subject to a number of situations where values can have incorrect or misleading displays. The most common causes of this are ...

  • Mismatched PDB files. This will usually lead to at least a warning dialog in the debugger about mismatched source files but not always
  • Simple data inspection or display error by the underlying expression evaluator. Not likely in this case as it's a simple local and a primitive type.
  • Optimizations causing the data to be displayed incorrectly.

But it in fact is almost certainly not false. The easiest way to verify this is to use a Debug.WriteLine call to print the value out to the output window.

JaredPar
+1  A: 

Just to add a little suggestion:

If you ever get confusing results from the debugger, stick a Console.WriteLine() in there and get the code itself to tell you what is going on. This can often clear up confusion.

(You can also get an effect like this when debugging release code, but you said it was a debug build which eliminates that suspect)

Jason Williams
+1  A: 

Maybe you moved the current instruction pointer (yellow arrow) with your mouse inadvertently while in break mode... It happened to me once and I flipped out. :-)

CesarGon
A: 

I've seen this sort of thing before. A co-worker was convinced he'd uncovered a bug in the .Net Framework or CLR. In the end it was just an old assembly or pdb synch problem.

forgot my open id login
A: 

Bit like: MS == 'good' && OSS == 'bad' WGAF :-\

gb