Errore potenziale .NET JIT?


404

Il codice seguente fornisce un output diverso quando si esegue la versione all'interno di Visual Studio e si esegue la versione all'esterno di Visual Studio. Sto usando Visual Studio 2008 e ho come target .NET 3.5. Ho anche provato .NET 3.5 SP1.

Quando si esegue al di fuori di Visual Studio, JIT dovrebbe attivarsi. O (a) c'è qualcosa di sottile in C # che mi manca o (b) JIT è effettivamente in errore. Sono dubbioso che la SIC possa sbagliare, ma sto esaurendo altre possibilità ...

Output durante l'esecuzione in Visual Studio:

    0 0,
    0 1,
    1 0,
    1 1,

Output durante l'esecuzione della versione all'esterno di Visual Studio:

    0 2,
    0 2,
    1 2,
    1 2,

Qual è la ragione?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Test
{
    struct IntVec
    {
        public int x;
        public int y;
    }

    interface IDoSomething
    {
        void Do(IntVec o);
    }

    class DoSomething : IDoSomething
    {
        public void Do(IntVec o)
        {
            Console.WriteLine(o.x.ToString() + " " + o.y.ToString()+",");
        }
    }

    class Program
    {
        static void Test(IDoSomething oDoesSomething)
        {
            IntVec oVec = new IntVec();
            for (oVec.x = 0; oVec.x < 2; oVec.x++)
            {
                for (oVec.y = 0; oVec.y < 2; oVec.y++)
                {
                    oDoesSomething.Do(oVec);
                }
            }
        }

        static void Main(string[] args)
        {
            Test(new DoSomething());
            Console.ReadLine();
        }
    }
}

8
Sì, che ne dici: trovare un bug serio in qualcosa di essenziale come il .Net JIT - congratulazioni!
Andras Zoltan,

73
Questo sembra riproporre nella mia build del 9 dicembre del framework 4.0 su x86. Lo passerò alla squadra jitter. Grazie!
Eric Lippert,

28
Questa è una delle pochissime domande che meritano davvero un badge d'oro.
Mehrdad Afshari,

28
Il fatto che tutti noi siamo interessati a questa domanda dimostra che non ci aspettiamo bug in .NET JIT, ben fatto Microsoft.
Ian Ringrose,

2
Aspettiamo tutti che Microsoft risponda con ansia .....
Talha,

Risposte:


211

È un bug dell'ottimizzatore JIT. Sta srotolando il ciclo interno ma non aggiorna correttamente il valore oVec.y:

      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
0000000a  xor         esi,esi                         ; oVec.x = 0
        for (oVec.y = 0; oVec.y < 2; oVec.y++) {
0000000c  mov         edi,2                           ; oVec.y = 2, WRONG!
          oDoesSomething.Do(oVec);
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[00170210h]        ; first unrolled call
0000001b  push        edi                             ; WRONG! does not increment oVec.y
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[00170210h]        ; second unrolled call
      for (oVec.x = 0; oVec.x < 2; oVec.x++) {
00000025  inc         esi  
00000026  cmp         esi,2 
00000029  jl          0000000C 

Il bug scompare quando si lascia oVec.y incrementare a 4, ovvero troppe chiamate da srotolare.

Una soluzione alternativa è questa:

  for (int x = 0; x < 2; x++) {
    for (int y = 0; y < 2; y++) {
      oDoesSomething.Do(new IntVec(x, y));
    }
  }

AGGIORNAMENTO: ricontrollato nell'agosto 2012, questo errore è stato corretto nel jitter versione 4.0.30319. Ma è ancora presente nel jitter v2.0.50727. Sembra improbabile che lo risolveranno nella vecchia versione dopo così tanto tempo.


3
+1, sicuramente un bug - avrei potuto identificare le condizioni per l'errore (non dire che Nobugz l'ha trovato a causa mia, però!), Ma questo (e il tuo, Nick, quindi +1 anche per te) mostra che JIT è il colpevole. interessante notare che l'ottimizzazione viene rimossa o diversa quando IntVec viene dichiarato come classe. Anche se si inizializzano esplicitamente i campi della struttura su 0 prima del ciclo, si vede lo stesso comportamento. Cattiva!
Andras Zoltan,

3
@Hans Passant Quale strumento hai usato per generare il codice assembly?

3
@Joan - Solo Visual Studio, copia / incolla dalla finestra Disassembly del debugger e commenti aggiunti a mano.
Hans Passant,

82

Credo che questo sia in un vero bug di compilazione JIT. Vorrei segnalarlo a Microsoft e vedere cosa dicono. È interessante notare che ho scoperto che x64 JIT non ha lo stesso problema.

Ecco la mia lettura del JIT x86.

// save context
00000000  push        ebp  
00000001  mov         ebp,esp 
00000003  push        edi  
00000004  push        esi  
00000005  push        ebx  

// put oDoesSomething pointer in ebx
00000006  mov         ebx,ecx 

// zero out edi, this will store oVec.y
00000008  xor         edi,edi 

// zero out esi, this will store oVec.x
0000000a  xor         esi,esi 

// NOTE: the inner loop is unrolled here.
// set oVec.y to 2
0000000c  mov         edi,2 

// call oDoesSomething.Do(oVec) -- y is always 2!?!
00000011  push        edi  
00000012  push        esi  
00000013  mov         ecx,ebx 
00000015  call        dword ptr ds:[002F0010h] 

// call oDoesSomething.Do(oVec) -- y is always 2?!?!
0000001b  push        edi  
0000001c  push        esi  
0000001d  mov         ecx,ebx 
0000001f  call        dword ptr ds:[002F0010h] 

// increment oVec.x
00000025  inc         esi  

// loop back to 0000000C if oVec.x < 2
00000026  cmp         esi,2 
00000029  jl          0000000C 

// restore context and return
0000002b  pop         ebx  
0000002c  pop         esi  
0000002d  pop         edi  
0000002e  pop         ebp  
0000002f  ret     

Sembra un'ottimizzazione andata male per me ...


23

Ho copiato il tuo codice in una nuova app console.

  • Build di debug
    • Output corretto con debugger e nessun debugger
  • Passato a Release Build
    • Ancora una volta, correggere l'output entrambe le volte
  • Creata una nuova configurazione x86 (sto usando X64 Windows 2008 e stavo usando 'Any CPU')
  • Build di debug
    • Ottenuto l'output corretto sia F5 che CTRL + F5
  • Rilascio build
    • Output corretto con Debugger collegato
    • Nessun debugger: l'output è errato

Quindi è il JIT x86 che genera erroneamente il codice. Ho eliminato il mio testo originale sul riordino dei loop ecc. Alcune altre risposte qui hanno confermato che JIT sta svolgendo il loop in modo errato quando su x86.

Per risolvere il problema è possibile modificare la dichiarazione di IntVec in una classe e funziona in tutti i modi.

Pensa che questo debba andare su MS Connect ....

-1 a Microsoft!


1
Un'idea interessante, ma sicuramente questa non è "ottimizzazione" ma un bug molto importante nel compilatore, se è così? Ormai sarebbe stato trovato, no?
David M,

Sono d'accordo con te. Il riordino di cicli come questo potrebbe causare problemi non raccontati. In realtà questo sembra ancora meno probabile, perché i loop for non possono mai raggiungere 2.
Andras Zoltan,

2
Sembra uno di questi brutti Heisenbugs: P
arul

Qualsiasi CPU non funzionerà se l'OP (o chiunque utilizzi la sua applicazione) abbia una macchina x86 a 32 bit. Il problema è che il JIT x86 con ottimizzazioni abilitate genera codice errato.
Nick Guerrera,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.