Bug only occurring when compile optimization enabled

Question

I came across a bug in code that is only reproduced when the code is built with optimizations enabled. I\'ve made a console app that replicates the logic for testing (code

Answer 1

This bug seems to have been fixed in .NET 4 (beta 2). Here's the optimized x86 disassembly for the bit nobugz highlighted, above:

                    Console.WriteLine("Post-check Value is: " + value);
00000056  mov         ecx,dword ptr ds:[033C2090h] 
0000005c  mov         edx,dword ptr [ebp-8] 
0000005f  call        65D8FE10

The program also displays the expected output in both optimized and unoptimized modes.

Answer 2

Certainly looks like a bug, does it reproduce when you swap the operator operands like this?

if (false == (null == value || new string[0] == value))

Answer 3

Yes, your expression fatally confuses the JIT optimizer. The generated machine code looks like this:

                if ((value == null || value == new string[0]) == false)
00000027  test        esi,esi               ; value == null?
00000029  je          00000075 
0000002b  xor         edx,edx               ; new string[0]
0000002d  mov         ecx,6D913BD2h 
00000032  call        FFD20BC8 
00000037  cmp         eax,esi               ; (value == new string[0]) == false?
00000039  je          00000075 
                {
                    Console.WriteLine("Post-check Value is: " + value);
0000003b  mov         ecx,dword ptr ds:[03532090h]  ; "Post-check value is: "
00000041  xor         edx,edx               ; BUGBUG not null!
00000043  call        6D70B7E8              ; String.Concat()
00000048  mov         esi,eax               ; 
0000004a  call        6D72BE08              ; get Console.Out
0000004f  mov         ecx,eax 
00000051  mov         edx,esi 
00000053  mov         eax,dword ptr [ecx] 
00000055  call        dword ptr [eax+000000D8h]     ; Console.WriteLine()

The bug occurs at address 41, the optimizer has concluded that value will always be null so it directly passes a null to String.Concat().

For comparison, this is the code that's generated when JIT optimization is turned off:

                    Console.WriteLine("Post-check Value is: " + value);
00000056  mov         ecx,dword ptr ds:[03342090h] 
0000005c  mov         edx,dword ptr [ebp-8] 
0000005f  call        6D77B790 

The code got moved, but do note that at address 5c it now uses the local variable (value) instead of null.

You can report this bug at connect.microsoft.com. The workaround is simple:

  if (value != null)
  {
    Console.WriteLine("Post-check Value is: " + value);
    new PrintManager().Print("blah", value);
  }

Answer 4

value == new string[0]

The above looks like a weird statement to me. You are comparing two string arrays with an equals statement. That will only result in true if they both point to the same array, which is quite unlikely. This doesn't explain yet why this code behaves differently in an optimized version.

Answer 5

I'm on x64 and couldn't reproduce the problem at first. Then I specified the target as x86, and it happened to me. Back to x64, and it went away. Not sure what this means, exactly, but I've gone back and forth a few times now.