Un peu plus tôt cette semaine, des ingénieurs ont découvert une faille dans le compilateur RyuJIT embarqué dans de l’environnement d’exécution .NET 4.6 qui affecte le modèle d’appel Tail Call Optimization. « Les méthodes que vous appelez peuvent prendre des paramètres avec des valeurs différentes de celles que vous avez passées », a expliqué Nick Craver, développeur logiciel sur Stack Overflow, l’un des sites web du réseau Stack Exchange qui propose des questions et réponses sur un large choix de thèmes concernant la programmation informatique. Il a travaillé en coordination avec un autre développeur logiciel de la même plateforme appelé Marc Gravell.Un bug qui a été difficile à repérer parce qu’il ne se produit que lorsque les optimisations sont activées. Cela signifie que vous pouvez développer votre application, l'exécuter dans Visual Studio et tout fonctionnera parfaitement bien. Ce n’est que lorsque vous compilerez une build de production que le problème va se produire. Craver explique qu’arrêter le débogueur change le comportement et cache souvent le problème. Ce dernier a été remarqué à Stack Overflow parce que son code de mise en cache HTTP ne fonctionnait pas avec le nouvel environnement d'exécution, conduisant à l’obtention de résultats imprévisibles. Jetez plutôt un œil sur le code ci-dessous qui met en exergue le problème.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | void Set<T>(string key, T val, int? durationSecs, bool sliding, bool broadcastRemoveFromCache = false)
{
SetWithPriority<T>(key, val, durationSecs, sliding, CacheItemPriority.Default);
}
void SetWithPriority<T>(string key, T val, int? durationSecs, bool isSliding, CacheItemPriority priority)
{
key = KeyInContext(key);
RawSet(key, val, durationSecs, isSliding, priority);
}
void RawSet(string cacheKey, object val, int? durationSecs, bool isSliding, CacheItemPriority priority)
{
var absolute = !isSliding && durationSecs.HasValue
? DateTime.UtcNow.AddSeconds(durationSecs.Value)
: Cache.NoAbsoluteExpiration;
var sliding = isSliding && durationSecs.HasValue
? TimeSpan.FromSeconds(durationSecs.Value)
: Cache.NoSlidingExpiration;
HttpRuntime.Cache.Insert(cacheKey, val, null, absolute, sliding, priority, null);
} |
Ils ont exhorté la communauté à désactiver RyuJIT en production en attendant qu’un correctif soit disponible et ont contacté Microsoft pour lui faire part du problème.
Par le biais de Rich Lander, un développeur faisant partie de l’une de ses équipes, Microsoft a reconnu le problème, avançant que l’équipe responsable de RyuJIT a résolu le problème et travaille déjà sur un correctif qui sera disponible en téléchargement. « Ce problème est de nature étriquée dans le sens où votre code doit utiliser des types de données spécifiques, les transmettre de manière spécifique puis exécuter des opérations spécifiques. Très peu de programmes sauront satisfaire l'ensemble de ces caractéristiques qui s’avèrent nécessaires pour déclencher ce bug de génération de code. Nous avons examiné ce problème pour déterminer s’il est exploitable. Nous n’avons pas identifié d’exploit, mais nous lançons les modifications dans notre processus au même rythme que nous l’aurions fait s’il s’agissait d’un exploit ».
Il a expliqué que l’équipe .NET a fourni une analyse détaillée suite à des dizaines de milliers de tests dont les statistiques suggèrent que la majorité des développeurs .NET ne feront pas l’expérience de ce problème. « Nous avons de nombreux tests intensifs sur les bibliothèques de notre .NET Framework (par exemple System.Xml). Nous n’avons pas été en mesure de trouver un seul cas où s’est manifesté ce problème sur de grandes portions de code. Du point de vue de la production, less propriétés Web importantes de Microsoft ont été exécutés sur des préversions du .NET Framework 4.6 pendant des mois sans que ce problème ne soit déclenché ».
Microsoft a tenu à remercier l’équipe des développeurs qui lui ont communiqué le problème.
Source : blog Nick Craver, blog MSDN
!
Envoyé par Uther
