Detecting Problematic Execution Patterns Through Automatic Kernel Trace Analysis

Les processeurs multicoeurs, les systèmes distribués et la virtualisation deviennent de plus en plus répandus, rendant ainsi le débogage des systèmes en production plus difficile, surtout quand les problèmes rencontrés ne sont pas facilement reproductibles. Cette complexité architecturale a introduit une nouvelle gamme de problèmes potentiels qu'on devrait pouvoir détecter à l'aide de nouvelles méthodologies efficaces et extensibles. En effet, en traçant le noyau d'un système d'exploitation, on est capable d'identifier les goulots d'étranglement, les failles de sécurité, les bogues de programmation ainsi que d'autres genres de comportements indésirables. Le traçage consiste à collecter les événements pertinents se produisant sur un système en production, tout en ayant un impact minimal sur la performance ainsi que sur le flot normal d'exécution. La trace générée est typiquement inspectée en différé, n'introduisant aucun impact sur le système tracé. Ce travail présente une nouvelle approche basée sur les automates pour la modélisation de patrons de comportements problématiques sous forme d'une ou plusieurs machines à états finis exécutables. Ces patrons sont ensuite introduits dans un analyseur qui vérifie leur existence simultanément et efficacement dans des traces de plusieurs giga-octets. L'analyseur fournit une interface de programmation offrant des services essentiels aux automates. Les patrons implémentés touchent à différents domaines incluant la sécurité, le test de logiciels et l'analyse de performance. Les résultats de l'analyse fournissent suffisamment d'information pour identifier précisément la source du problème ce qui nous a permis d'identifier une séquence de code dans le noyau Linux pouvant générer un inter-blocage. La performance de l'analyseur est linéaire par rapport à la taille de la trace. Les autres facteurs affectant sa performance sont discutés. En outre, la comparaison entre la performance de l'analyseur par rapport à celle d'une approche dédiée, suggère que le surcoût de l'utilisation des machines à états pour l'exécution et non seulement pour la modélisavi tion, est acceptable surtout lors d'une analyse différée. La solution implémentée est facilement parallélisable et pourrait bien s'appliquer à des analyses en-ligne. Le mémoire se conclut par une liste de suggestions d'optimisations possibles pouvant encore améliorer la performance de l'analyseur.