Erreur potentielle .NET JIT?


404

Le code suivant donne une sortie différente lors de l'exécution de la version dans Visual Studio et de l'exécution de la version en dehors de Visual Studio. J'utilise Visual Studio 2008 et je cible .NET 3.5. J'ai également essayé .NET 3.5 SP1.

Lors de l'exécution en dehors de Visual Studio, le JIT doit démarrer. Soit (a) il se passe quelque chose de subtil avec C # qui me manque ou (b) le JIT est en fait en erreur. Je doute que le JIT puisse mal tourner, mais je suis à court d'autres possibilités ...

Sortie lors de l'exécution dans Visual Studio:

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

Sortie lors de l'exécution d'une version en dehors de Visual Studio:

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

Quelle est la raison?

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
Ouais - que diriez-vous de cela: trouver un bug sérieux dans quelque chose d'aussi essentiel que le .Net JIT - félicitations!
Andras Zoltan

73
Cela semble se reproduire dans ma version du 9 décembre du framework 4.0 sur x86. Je vais le transmettre à l'équipe de gigue. Merci!
Eric Lippert

28
C'est l'une des très rares questions qui méritent en réalité un badge en or.
Mehrdad Afshari

28
Le fait que nous soyons tous intéressés par cette question montre que nous ne nous attendons pas à des bogues dans le .NET JIT, bravo Microsoft.
Ian Ringrose

2
Nous attendons tous avec impatience la réponse de Microsoft .....
Talha

Réponses:


211

Il s'agit d'un bogue d'optimiseur JIT. Il déroule la boucle interne mais ne met pas à jour la valeur oVec.y correctement:

      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 

Le bogue disparaît lorsque vous laissez oVec.y incrémenter à 4, c'est trop d'appels à dérouler.

Une solution de contournement est la suivante:

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

MISE À JOUR: revérifié en août 2012, ce bug a été corrigé dans la gigue de la version 4.0.30319. Mais est toujours présent dans la gigue v2.0.50727. Il semble peu probable qu'ils corrigent ce problème dans l'ancienne version après une longue période.


3
+1, certainement un bug - j'aurais peut-être identifié les conditions de l'erreur (sans dire que nobugz l'a trouvé à cause de moi, cependant!), Mais cela (et le vôtre, Nick, donc +1 pour vous aussi) montre que le JIT est le coupable. intéressant que l'optimisation soit supprimée ou différente lorsque IntVec est déclaré en tant que classe. Même si vous initialisez explicitement les champs struct à 0 avant la boucle, le même comportement est observé. Méchant!
Andras Zoltan

3
@Hans Passant Quel outil avez-vous utilisé pour sortir le code assembleur?

3
@Joan - Just Visual Studio, copiez / collez à partir de la fenêtre de désassemblage du débogueur et ajoutez les commentaires à la main.
Hans Passant

82

Je crois que c'est dans un véritable bug de compilation JIT. Je voudrais le signaler à Microsoft et voir ce qu'ils disent. Fait intéressant, j'ai trouvé que le JIT x64 n'a pas le même problème.

Voici ma lecture du x86 JIT.

// 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     

Cela ressemble à une optimisation qui a mal tourné pour moi ...


23

J'ai copié votre code dans une nouvelle application console.

  • Debug Build
    • Sortie correcte avec débogueur et sans débogueur
  • Passé à Release Build
    • Encore une fois, une sortie correcte les deux fois
  • Création d'une nouvelle configuration x86 (j'utilise X64 Windows 2008 et j'utilisais 'Any CPU')
  • Debug Build
    • A obtenu la sortie correcte à la fois F5 et CTRL + F5
  • Release Build
    • Sortie correcte avec le débogueur attaché
    • Pas de débogueur - obtenu la sortie incorrecte

C'est donc le JIT x86 qui génère incorrectement le code. J'ai supprimé mon texte d'origine sur la réorganisation des boucles, etc. Quelques autres réponses ici ont confirmé que le JIT déroule la boucle de manière incorrecte lorsqu'il est sur x86.

Pour résoudre le problème, vous pouvez modifier la déclaration d'IntVec en classe et cela fonctionne dans toutes les versions.

Pensez que cela doit aller sur MS Connect ....

-1 à Microsoft!


1
Idée intéressante, mais ce n'est sûrement pas "l'optimisation" mais un bug très important dans le compilateur si c'est le cas? Aurait été trouvé maintenant, n'est-ce pas?
David M

Je suis d'accord avec toi. La réorganisation de boucles comme celle-ci peut entraîner des problèmes incalculables. En fait, cela semble encore moins probable, car les boucles for ne peuvent jamais atteindre 2.
Andras Zoltan

2
On dirait un de ces méchants Heisenbugs: P
arul

Tout processeur ne fonctionnera pas si l'OP (ou toute personne utilisant son application) possède une machine x86 32 bits. Le problème est que le JIT x86 avec les optimisations activées génère un code incorrect.
Nick Guerrera
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.