450 erreurs logiques détectées dans des bases de données populaires
Les bases de données doivent être de plus en plus performantes. La fiabilité semble toutefois en souffrir. Des informaticiens de l'ETH ont désormais développé un outil qui détecte automatiquement les erreurs logiques dans les systèmes de base de données à l'aide de trois méthodes différentes. Jusqu'à présent, plus de 450 bugs ont ainsi pu être trouvés et corrigés.
(Actualisé : )
![Écran d'ordinateur avec les lettres S Q L](/de/news-und-veranstaltungen/eth-news/news/2020/11/fehler-in-datenbanken/_jcr_content/news_content/fullwidthimage/image.imageformat.930.304912492.jpg)
Lorsqu'une adresse est enregistrée dans le smartphone, nous partons tout naturellement du principe que nous la trouverons en effectuant la bonne requête. De même qu'avec les termes appropriés, tous les articles correspondants sont listés dans la boutique en ligne. Mais ce n'est pas aussi évident que nous le pensons. Une erreur logique dans le système de gestion de base de données (DBMS), dans lequel les informations enregistrées sont gérées, peut renvoyer des réponses erronées sans même que nous nous rendions compte de l'erreur.
Un nombre surprenant de bugs dans tous les systèmes
Et c'est précisément ce genre d'erreurs logiques qui sont étonnamment fréquentes. Ou plutôt, elles l'étaient jusqu'à récemment. Des chercheurs de l'Advanced Software Technologies Lab de l'ETH Zurich viennent en effet de développer un outil qui détecte automatiquement les erreurs logiques dans les logiciels de base de données. Plus de 450 erreurs de programmation ont déjà pu être trouvées et corrigées dans des bases de données très répandues.
"Nous avons nous-mêmes été surpris par le nombre d'erreurs contenues dans les systèmes courants de gestion de bases de données", explique Manuel Rigger : "Grâce à nos méthodes, nous avons par exemple découvert plus de 150 erreurs de programme dans la base de données SQLite fonctionnant sur presque tous les smartphones et également dans de nombreux navigateurs web. Et ce n'est pas un cas extrême. Le taux est similaire dans tous les systèmes que nous avons examinés jusqu'à présent".
Programmes complexes et bugs difficilement identifiables
Si les informaticiens de l'ETH trouvent autant de bugs, c'est pour deux raisons principales. D'une part, les bases de données actuelles sont très complexes et peuvent contenir plusieurs millions de lignes de code. Il est donc pratiquement inévitable que des contradictions apparaissent et que des erreurs de programmation se produisent. D'autre part, les erreurs logiques ne sont pas si faciles à trouver. Contrairement aux bugs qui font planter le système, elles ne s'expriment que rarement de manière évidente. En règle générale, une comparaison avec le bon résultat est nécessaire pour les remarquer. Jusqu'à présent, cela n'était possible qu'au prix de gros efforts.
La seule méthode de test automatisée utilisée à ce jour dans la pratique a été conçue il y a plus de 20 ans déjà. Elle repose sur la comparaison de requêtes avec différents systèmes de base de données. Comme chaque fabricant procède à des extensions et des adaptations spécifiques du standard d'interrogation SQL (Structured Query Language), la formulation de questions clairement comparables est entre-temps limitée à un petit domaine central des systèmes. En effet, les langages d'interrogation des fabricants diffèrent parfois considérablement, comme les dialectes d'une langue humaine.
Deux semaines de travail perdues
Personnellement, Rigger soupçonne également une troisième raison pour laquelle les erreurs n'ont pas été traitées avec plus de détermination jusqu'à présent : Dans le domaine des bases de données, les activités se concentrent actuellement sur l'amélioration de la performance des systèmes à l'aide de méthodes d'intelligence artificielle comme l'apprentissage automatique. Par ailleurs, la recherche d'erreurs semble naturellement peu attrayante.
Rigger lui-même a ses racines dans le test de logiciels et dans le développement de compilateurs permettant de traduire entre eux différents langages de programmation et langages machine. Il a été sensibilisé à la problématique des erreurs dans le domaine des bases de données à la suite de sa propre expérience fâcheuse, lorsqu'une erreur dans le système de gestion de la base de données lui a fait perdre deux semaines de travail.
Trois méthodes pour trois types d'erreurs
Par la suite, le spécialiste des tests s'est attaqué au problème en collaboration avec le directeur de l'Advanced Software Technologies Lab, Zhendong Su. Leur solution consiste en trois méthodes différentes qui permettent de trouver des requêtes de comparaison fiables. Le "Query Partitioning" consiste à découper automatiquement les requêtes en plusieurs parties, puis à vérifier si le tout et la somme des parties sont identiques.
La deuxième méthode permet de détecter de manière ciblée les erreurs provoquées par des mécanismes d'optimisation dans les bases de données. Pour ce faire, les requêtes de comparaison sont modifiées de manière à ce que le mécanisme d'optimisation ne puisse plus fonctionner.
Contrairement aux deux premières méthodes, qui peuvent être exécutées de manière automatisée sans connaissances détaillées de la base de données en question, la troisième exige des connaissances spécifiques de la base de données et une mise en œuvre individuelle de la comparaison. Dans la méthode dite "Pivoted Query Synthesis", toute une série est sélectionnée au hasard dans la table de la base de données relationnelle. Ensuite, il faut créer une requête qui a pour résultat la série choisie. Les erreurs logiques peuvent ainsi être identifiées de manière beaucoup plus efficace que si, comme jusqu'à présent, les différentes entrées devaient être analysées manuellement.
L'outil est déjà utilisé par des fabricants
Avec leurs méthodes et l'outil SQLancer dans lequel elles ont été automatisées, les informaticiens de l'ETH ont manifestement réveillé des esprits endormis. L'intérêt des fabricants de bases de données est particulièrement grand. Bien que les trois méthodes n'aient été communiquées jusqu'à présent que de manière informelle sous forme de préprints et via les médias sociaux, et qu'elles ne soient présentées officiellement que ces jours-ci lors de conférences spécialisées, plusieurs fabricants ont déjà commencé à tester leurs logiciels avec ces méthodes. "Divers fabricants ont déjà trouvé de nombreux bugs dans leurs systèmes et ont intégré le SQLancer de manière fixe dans leur testing", sait Rigger grâce à de nombreux contacts directs : "Certains ont également contribué au code de programmation de notre projet publié en open source ou ont adapté et étendu l'outil à leurs besoins spécifiques".
La "Pivoted Query Synthesis" a été présentée à la communauté des chercheurs le 5 novembre lors de la journée des logiciels de systèmes. page externeOSDI (Operating Systems Design and Implementation) a été présentée. La méthode des erreurs d'optimisation sera présentée le 13 novembre dans le cadre du 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (page externeESEC/FSE), et le "Query Partitioning" le 18 novembre à la conférence sur les langages de programmation. page externeOOPLSA (Programmation orientée objet, systèmes, langages et applications).
![](/bin/ethz/components/previewImage/youtube/Np46NQ6lqP8.jpg)
Références bibliographiques
Rigger M, Su Z : Finding bugs in database systems via query partitioning. Proceedings of the ACM on Programming LanguagesNovembre 2020 Article No : 211. doi : page externehttps://doi.org/10.1145/3428279
Rigger M, Su Z : Détection de bugs d'optimisation dans les moteurs de base de données via une construction non optimale du moteur de référence. Actes de la 28e édition de la conférencethACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2020). 6 - 16 novembre 2020. doi : page externehttps://dl.acm.org/doi/10.1145/3368089.3409710.
Rigger M, Su Z : Testing Database Engines via Pivoted Query Synthesis. Conception et mise en œuvre des systèmes d'exploitation (OSDI). 4 - 6 novembre 2020. Official paper : page externehttps://www.usenix.org/conference/osdi20/presentation/rigger.