Vérification dynamique dans SimGrid

SimGridMC est un model checker permeant la vérification dynamique de systèmes distribués exprimés sous forme de programmes pour le simulateur SimGrid. Cela permet d’éviter la construction d’un modèle du programme compatible avec un model checker classique, étape souvent difficile et fastidieuse. Il s’agit donc en quelque sorte d’un model eer sans modèle, ou plutôt où le modèle n’est pas connu explicitement. Cee ap-proche souffre cependant de certaines limitations par rapport au model checking clas-sique, comme le fait qu’elle ne permet que de vérifier des systèmes finis alors que l’étude classique des systèmes distribués se fait au travers de systèmes comptant une infinité de transitions. Notre approche reste justifiée dans le cadre d’une utilisation en tant que de-bugguer. Nous considérons en effet qu’une séance de vérification dynamique est fructueuse

si nous trouvons un contre-exemple pour les propriétés annoncées.

D’un point de vue conceptuel, SimGridMC prend en entrée un programme SimGrid classique, avec des assertions ajoutées dans le code pour exprimer les propriétés de sûreté. Il mène alors une exploration exhaustive de l’espace d’état pour vérifier le respect des assertions dans tous les cas. Au regard de l’architecture de SimGrid, le model checker vient se placer en remplacement du module SURF, habituellement en charge du noyau de simulation. Les autres modules (SIMIX et les interfaces utilisateurs) restent inchangés. Le travail de refactoring introduit dans le chapitre 2 simplifie grandement cee inté-gration technique puisque l’environnement comprend déjà l’infrastructure pour influer sur l’ordonnancement des processus et pour intercepter les communications modifiant l’état partagé. La difficulté majeure consiste alors à générer tous les ordonnancements d’événements possibles au lieu de déterminer par simulation celui qui aura lieu sur la plate-forme utilisée.

Le modèle. Comme explicité dans l’introduction, notre modèle se composes d’entités

autonomes interagissant par échange de messages uniquement (pas d’état global, ni d’horloge globale). L’état du système est donné par l’état local de chaque processus et l’état du réseau. Le comportement du modèle peut être décrit par un graphe d’états où les nœuds représentent différents états et les arrêtes représentent des transitions d’un état vers un autre. Dans notre cas, ces transitions correspondent aux échanges de messages entre processus.

Dans SimGrid, l’état de chaque processus est donné par ses registres sur le processeur, sa pile d’exécution et la mémoire allouée dans le tas. L’état du réseau contient les mes-sages en transit ainsi que les requêtes de communication postées dans les boîtes aux leres existantes. Seules les requêtes de communications influant sur l’état partagé du système, ce sont les seuls transitions considérées par notre model checker, et les change-ments locaux ne sont donc pas considérés. Au lieu de cela, ces changechange-ments locaux sont agrégés à la transition globale à laquelle ils répondent. On considère donc comme tran-sition un échange de message et les réactions locales des processus impliqués. L’espace d’état est généré en calculant tous les ordonnancements possibles de transitions des pro-cessus. Cet espace est souvent infini, même pour un nombre fini de processus, à cause des libertés offertes par la gestion de la mémoire et par le traitement des processus. La figure3.2(page86) présente l’architecture de SimGridMC, qui intercepte toutes les inter-actions processus avec le réseau au travers de l’interface de communication. Les zones en bleu représentent l’état de système étudié tandis que les zones en rouge représentent

l’état du model checker, qui contient principalement la pile d’exploration.

Les propriétés. Elles décrivent le comportement aendu du système. À l’heure actuelle,

SimGridMC ne gère que les propriétés de sûreté locales, sous forme d’assertions insérées dans le code du programme. Il y a donc deux limitations majeures aux propriétés qu’il est possible d’exprimer dans SimGridMC. D’une part, il n’est pas possible d’exprimer de propriétés de vivacité qui merait en relation diverses étapes de l’histoire du sys-tème. D’autre part, il n’est pas possible d’exprimer d’assertion liant l’état de plusieurs processus. Ces deux limitations sont nécessaires pour assurer le bon fonctionnement de l’algorithme de réduction de l’espace d’état présenté à la section3.7. Il est cependant pos-sible de contourner en partie ces limitations en pratique, et la vérification d’absence de situation d’interblocage est par exemple possible dans ce cadre.

Exploration explicite. L’état global du système est extrêmement complexe à analyser

dans notre cas, car il contient la pile d’exécution des processus (dont l’analyse devrait se faire au niveau système et assembleur) et car les transitions sont exprimées sous forme d’un code C arbitraire à exécuter. Le fait que le modèle soit ainsi implicite rend son étude symbolique quasi impossible. Au lieu de cela, SimGridMC mène une exploration explicite de ce modèle en exécutant le code des transitions.

Lors de cee exploration, le model checker construit une pile dont chaque entrée représente un ensemble de processus dont il faut tester tous les ordonnancements, un ensemble de processus dont les ordonnancements ont déjà été testés, et la transition effec-tuée pour quier cet état. L’exploration est alors menée en profondeur d’abord, en sélec-tionnant une transition possible à chaque étape, puis en revenant au début de l’histoire pour explorer une autre branche lorsqu’un état final est accepté. Comme l’histoire du système peut être infinie, le processus est borné à une profondeur maximale déterminée par l’utilisateur. Cela signifie naturellement que SimGridMC ne peut détecter les er-reurs ayant lieu après la limite de la recherche, mais il assure une exploration exhaustive jusqu’à ce niveau.

La figure3.3(page87) illustre le principe de l’exploration de SimGridMC. Le model checker commence par une phase d’initialisation où il exécute tous les processus jusqu’à leur première action de communication (exclue). Dans l’exemple, il s’agit des flèches de-scendantes vertes a et b. L’état résultant S₀ est l’état initial du système, et donc poussé sur la pile d’exploration avec deux transitions possibles a et b. De plus, une sauvegarde par snapshot système est réalisée afin de pouvoir restaurer cet état du système étudié

par la suite.

Une fois cee initialisation réalisée, le model checker sélectionne et exécute l’une des transitions possibles (dans l’exemple, a). Il effectue les changements à l’état global demandés par a puis ordonnance l’exécution du processus correspondant jusqu’à leur première action de communication, exclue (ici, c). Cee exécution correspond à une transition telle que considérée par le model checker. Ensuite, le mécanisme est itéré par l’exécution de l’une des transitions possibles en S1(ici, b). Ce mécanisme est itéré jusqu’à ce que la limite de profondeur de l’exploration soit aeinte ou bien jusqu’à ce qu’il n’y ait plus de transition à explorer. Cee dernière situation correspond soit à une terminaison du programme ou à une situation d’interblocage.

Sauvegarde et restauration d’états. Lorsque l’exploration aeint la fin de l’histoire du

système, il est nécessaire de revenir à un état antérieur du système afin d’explorer une autre branche d’exécution. Une solution serait de sauvegarder tous les états rencontrés, mais il est probable qu’elle s’avèrerait trop coûteuse en temps et en espace dans notre cas. Au lieu de cela, nous avons choisi l’approche state-less introduite par Veriso [26]. Elle consiste à ne sauvegarder que l’état initial, et à retourner dans un état quelconque du système en revenant à cet état initial puis en re-exécutant la trajectoire menant à l’état auquel on souhaite se ramener. Cee approche évite la consommation mémoire due au stockage de tous les états rencontrés, mais en contrepartie, elle ne permet pas la détection des cycles, et peut donc mener à réexplorer des sections de l’histoire qui avaient déjà été explorés. Cee limitation n’est pas critique dans notre contexte puisque nous menons une exploration bornée pour vérifier des propriétés de sûreté, mais elle s’avèrerait critique pour la vérification de propriétés de vivacité où la prise en compte des cycles est primordiale.