none
CLR Bug (x64) RRS feed

  • Question

  • Hello, i'm pretty sure having found a bug in the CLR (x64):

    using System;
    
    class Program
    {
        static void f(int c, int d, int e)
        {
            Console.WriteLine("c={0}, d={1}, e={2}", c, d, e);
        }
    
        static void Main()
        {
            int d = 0;
            int i = 3;
    
            for (int e = 0; e < 2; e++)
            {
                while (true)
                {
                    int c = 3 - d++;
                    f(c, d, e); //  c == 3-d+1 !
                    if (--i < 1) break;
                }
            }
        }
    }
    
    

    Obviously the inner loop decreases d and therefore c is increased in every iteration.
    If you compile that with:

    csc /optimize+ source.cs

    and run this program on an 64-Bit operating system (Windows 7) you see that c does not increase the way one would expect.
    If you compile this without '/optimize+' or supply an additional '/platform:x86' everything is ok.
    I looked at the ILDASM output and it seems that both the optimized and non optimized IL-Code is correct.

    Is this a known issue. Is there any way to verify this by inspecting the nativ code?
    Friday, January 22, 2010 8:43 AM

Answers

  • This is indeed a bug in JIT64 (pobably in loop recognizer), we started tracking it.

    There are 2 possible work arounds (if this is blocking you):
    1) Add NoOptimization custom attribute to the method with such loop.
    2) Add some dummy code outside the while-loop, for example:

    for (int e = 0; e < 2; e++)
    {
        int j = e + 1; j++; // This is the ‘work-around’.
        // The JIT will completely remove this dead code, 
        // but it lives long enough to work-around the bug.
    
        while (true)
        {
            int c = 3 - d++;
            f(c, d, e); //  c == 3-d+1 !
            if (--i < 1) break;
        }
    }


    Thank you for your report.
    BTW: Please use Microsoft Connect for future bug reports.
    -Karel

    Wednesday, January 27, 2010 8:16 PM
    Moderator

All replies

  • The place to check if this is a known issue - and where to report it if not - is Microsoft Connect.

    http://connect.microsoft.com/

           -Steve
    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ

    Microsoft Certified Professional Developer
    Friday, January 22, 2010 1:50 PM
  • Hmmm, that's interesting behavior. File a bug, post link here, I will ask JIT64 devs meanwhile.

    Output for CLR 2.0.50727.1873 (2.0 SP1 GDR) and 2.0.50727.3603 (3.5 SP1 GDR = 2.0 SP2 GDR):
    x64 /optimize+
        c=3, d=1, e=0
        c=3, d=2, e=0
        c=3, d=3, e=0
        c=2, d=4, e=1

    x86 /optimize+ & x64 /debug+
        c=3, d=1, e=0
        c=2, d=2, e=0
        c=1, d=3, e=0
        c=0, d=4, e=1

    BTW: Thanks for the nice small repro! That makes it so much easier to investigate.

    -Karel

    Friday, January 22, 2010 8:23 PM
    Moderator
  • I didn't know about this either; good info.

    Looking around - I found a blog post that seems to explain exactly what's happening to the T:
    http://blogs.msdn.com/davbr/archive/2007/06/20/enter-leave-tailcall-hooks-part-2-tall-tales-of-tail-calls.aspx
    Friday, January 22, 2010 9:07 PM
  • This is indeed a bug in JIT64 (pobably in loop recognizer), we started tracking it.

    There are 2 possible work arounds (if this is blocking you):
    1) Add NoOptimization custom attribute to the method with such loop.
    2) Add some dummy code outside the while-loop, for example:

    for (int e = 0; e < 2; e++)
    {
        int j = e + 1; j++; // This is the ‘work-around’.
        // The JIT will completely remove this dead code, 
        // but it lives long enough to work-around the bug.
    
        while (true)
        {
            int c = 3 - d++;
            f(c, d, e); //  c == 3-d+1 !
            if (--i < 1) break;
        }
    }


    Thank you for your report.
    BTW: Please use Microsoft Connect for future bug reports.
    -Karel

    Wednesday, January 27, 2010 8:16 PM
    Moderator