5.1 Retours sur les résultats obtenus 5.1.1 Résultats de l’évaluation
Dans certains cas, les événements déduits forment une séquence qui n’est pas cohérente avec l’état suivant. Par exemple, lorsque l’on supprime l’événement 13 (un D sur l’objet 3), la correction proposée est la séquence DA, qui correspond bien à une séquence possible d’événements selon la définition de la FSM correspondante, et qui se trouve être la correction la plus probable à partir des fréquences de transitions. Or, l’événement supprimé se trouvait dans cette partie de la trace : CDABC... Donc on voit que la séquence CDAABC n’est pas acceptée par la machine à états, c’est une incohérence.
Cela est dû au fait que l’on ne vérifie pas la cohérence après avoir effectué la phase d’inférence des événements. Pour prendre en compte ces considérations, il faudrait relancer l’analyse de la cohérence. Actuellement, ce serait très coûteux, car l’analyse ne peut se faire que sur une trace en entier. Si de nombreux allers-retours sont nécessaires, l’analyse va être exécutée sur toute la trace un grand nombre de fois.
De plus, de nombreux événements incohérents détectés dans les traces utilisées pour le test de performance correspondent à des événements de sortie d’appel système (syscall_exit) solitaires. Puisqu’on ne peut normalement observer ces événements que lorsque le système est dans l’état suivant, l’observation d’un événement syscall_entry, une incohérence est ajoutée à chaque fois. Néanmoins, il arrive souvent que ces événements arrivent avec du retard, ou qu’ils puissent être déclenchés par un mécanisme particulier sans qu’il y ait eu l’entrée correspondante. Nous ne pouvons pas distinguer ces cas d’une incohérence réelle, donc nous devons marquer ces événements comme potentiellement incohérents.
5.2 Précisions sur la solution proposée
5.2.1 Compléments sur l’inférence du contenu des événements
Comme présenté dans l’article, une fois le type d’événement déduit, il est nécessaire d’exploi- ter le plus d’informations possible afin de déduire son contenu (les champs et leurs valeurs). Pour cela, nous pouvons exploiter les conditions préalables à l’exécution de la transition dé- duite, conditions qui sont nécessairement vérifiées selon la définition d’une transition. Nous
allons revenir plus en détails sur ce mécanisme.
Dans le cas général, lorsque l’on vérifie si une transition s’applique, chaque condition reliée à cette transition est testée. Il existe trois types de conditions XML :
— DATA : une condition qui porte sur des données du système d’états — TIME : une condition qui porte sur le temps
— autre : correspond au cas des conditions composées (or, and, not)
Ce sont les conditions de type DATA qui nous sont utiles, c’est ce que l’on veut récupérer pour extraire des informations. Il n’y a rien d’utile dans une condition de type TIME, car l’estampille de temps ne fait pas partie du contenu d’un événement (éventuellement, ce type de conditions pourrait être utilisé pour déduire l’estampille de temps de l’événement perdu). Quant aux autres conditions, elles vont être décomposées par des appels récursifs à la fonction de test, donc les sous-conditions seront éventuellement utilisées si elles sont de type DATA. Dans certains cas, plusieurs valeurs différents sont possibles pour un même champ d’événe- ment. Par exemple, on peut avoir une condition de la forme suivante :
<condition>
<stateAttribute type="constant" value="Threads" /> <stateAttribute type="eventField" value="tid" /> <stateAttribute type="constant" value="Status" />
<stateValue type="int" value="$PROCESS_STATUS_RUN_USERMODE" /> </condition>
Cette condition signifie que l’on cherche à savoir si le fil d’exécution identifié par tid est dans l’état "exécution en espace utilisateur" ($PROCESS_STATUS_RUN_USERMODE). Dans le contexte de l’inférence du contenu d’événement, on cherche donc à ajouter le champ tid au contenu de l’événement déduit ; ce qui signifie que l’on va sélectionner, comme valeurs possibles, toutes les valeurs de tid pour lesquelles le fil est dans l’état "exécution en espace utilisateur". Si l’on n’a pas de moyen de discriminer entre ces multiples valeurs, nous nous trouvons dans le cas où le champ est multi-valué.
Une possibilité serait de regarder le passé de chaque fil candidat et de s’en servir pour choisir celui qui est le plus probable (par exemple, un fil où il y a beaucoup d’activité pourrait être le plus probable pour être le fil sélectionné par le système d’exploitation lors de l’ordonnan- cement sur le CPU).
De plus, un même champ peut se trouver dans plusieurs conditions pour la même transition. Pour chacune de ces conditions, un ensemble de valeurs va être calculé. Lorsqu’un champ a
plusieurs groupes de valeurs possibles, mais que parmi ces groupes, il y en a un contenant seulement une valeur possible, alors on peut dire que cette valeur est la bonne et la sélectionner automatiquement.
Néanmoins, quand plusieurs choix possibles sont de même probabilité, nous avons décidé de laisser l’utilisateur choisir parmi les différentes possibilités qu’on lui propose. En effet, il est le plus à même de faire un choix éclairé, en fonction de ce qu’il connaît du système, ce qu’il voit sur la trace, donc ce qu’il pense être le plus probable. Ainsi, une fenêtre offre à l’utilisateur un moyen interactif de sélectionner parmi les différentes valeurs possibles pour chaque champ multi-valué (voir en Annexes, la Figure B.1). Chaque choix (fait au fur et à mesure) est affiché sur la vue Global Inference View et la modifie au fur et à mesure. On enregistre les choix dans l’événement déduit, et éventuellement l’utilisateur peut annuler un choix et revenir en arrière.
5.2.2 Trace contenant les événements déduits
Une fois les événements déduits, il faut pouvoir les intégrer à la trace pour laquelle des événements sont manquants. Malheureusement, les mécanismes internes de Trace Compass ne permettent pas d’insérer des événements à une trace déjà analysée.
Nous avons donc développé un nouveau type de trace, appelé Inference Trace. On peut dire que c’est une trace synthétique, car on ne lit et analyse pas une trace réelle. En fait, cette trace enveloppe la trace CTF existante, mais elle possède aussi une référence sur la liste des événements déduits. Ainsi, on peut surcharger la méthode en charge de fournir l’événement suivant d’une trace, afin de celle-ci retourne soit l’événement suivant de la trace réelle, soit l’événement déduit suivant (selon l’itérateur sur ceux-ci) si on a atteint son estampille de temps dans la chronologie. Cette trace nécessite quelques ajustements manuels car ce n’est pas un fonctionnement normalement prévu par Trace Compass, mais elle permet d’effectuer les analyses courantes comme s’il s’agissait d’une trace réelle.