Forest for the trees – Don’t forget the compiler

Recovered from DotNetJunkies blog -- Originally Posted: Wednesday, June 6, 2007

Back in school my teacher was not much on the formal aspects of the course he was teaching.He was instead, as I describe him, the kind of guy you could imagine living in his room with his PC, hacking away, his mom pushing crackers under the door and begging "You really should go out and get some friends dear." Perhaps because of that we spent less time in the text book and more time digging into just what the IDE, along with COM and MTS at the time, were doing underneath the hood to be "helpful". He often said that memorizing the text book would help you pass but that knowing what was really happening based on your code would give you a better ability to figure things out when debugging "weirdness". For some reason I thought of him just today. :-)

The "weirdness" in this case was that my IDE was doing strange stuff in debug mode, or so I thought at the time. I was trying to see why my property based on a config setting was never getting populated with the correct value. So I did the natural thing, I set a break point on the property get and fired it up. The basic code of the getter was this

Get
     Dim prop As Boolean = False
     Dim configVal As String = System.Configuration.ConfigurationSettings.AppSettings.Item("MyConfigKey")
If Not configval Is Nothing Then
          prop = CBool(configVal)
     End If
     Return prop
End Get

Nothing fancy, but when debugging I found that the If statement never seemed to evaluate to true, and the if block never executed. The debugger would always jump to End If no matter what I set the value of configVal to in the command window. Somebody wiser than me once said something along the lines of "always look for the stupidest solution first", however with this "weirdness" I immediately launched into the "weirdness countermeasures". These included restarting the IDE, rebuilding the solution, bleaching the temp files in case I was somehow stuck with an old version of the file from a previous life, rebooting, rinse repeat. All of the maneuvers that have served well in the past when bizarre things happen in the IDE. No dice, still same issue every time.

Now it's time for last resort "I have no idea, but I'll try this" measures. In the past I have had lines of code that would not compile with no apparent error and only way to resolve the issue was to retype the line, visually identical to the "bad" line, and all-of-a-sudden the IDE was happy again and we moved on. Whatever! So I figured I would give that a try. As I was re-typing the code I found a bug, seemed stupid and meaningless at first, but it then hit me that it had been the issue all along. In my getter the actual code looked like this

Get
     Dim prop As Boolean = False
     Dim configVal As String = System.Configuration.ConfigurationSettings.AppSettings.Item("MyConfigKey")
     If Not configval Is Nothing Then
          prop = CBool(prop)
     End If
     Return prop
End Get

I was setting the prop variable to the result of CBool(prop) as boolean of itself, which would always mean no change to the variable. Then the lights in my dark and scary brain started to go on! The compiler was helping me! I compiled the code again and looked at the disassembly, first with the bug

If Not configval Is Nothing Then
00000036 test ebx,ebx
00000038 je 0000003A
End If

and then without

If Not configval Is Nothing Then
00000036 test esi,esi
00000038 je 0000004E
prop = CBool(configVal)
0000003a mov ecx,esi
0000003c call FFB91FD0
00000041 movzx edi,al
00000044 mov eax,edi
00000046 and eax,0FFh
0000004b mov dword ptr [ebp-8],eax
End If

The compile decided that the stupid line of code was irrelevant and simply removed it. So in debugging, since we are actually stepping through the debug symbols, not the code, there was no line of code to hit in that If block. So the supposed "weirdness" just turned out to be a bad cut and paste. Doh! If the compiler had left it in I would have seen the line execute with no change to the value of prop and found the bug right away. Instead I get all commando.

Anyway, I just had to share my brain cramp. When things seem "weird" don't forget:

a) the "always look for the stupidest solution first" rule still applies

b) don't forget what might be trying to "help" you under the hood.

 

© Copyright 2009 - Andreas Zenker