Lire dans d'autres langues : Anglais Português 中文

Il existe de nombreux didacticiels de débogueur qui vous apprennent à définir des points d'arrêt de ligne, à enregistrer des valeurs ou à évaluer des expressions. Bien que ces connaissances vous donnent à elles seules de nombreux outils pour déboguer votre application, les scénarios du monde réel peuvent être un peu plus compliqués et nécessiter une approche plus avancée.

Dans cet article, nous apprendrons comment localiser le code qui provoque un crash de l'interface utilisateur sans grande connaissance préalable du projet et réparer le code cassé à la volée.

Le problème

Si vous souhaitez suivre l'exemple, commencez par cloner ce référentiel : https://github.com/flounder4130/debugger-example

Supposons que vous ayez une application complexe qui se bloque lorsque vous effectuez une action. Vous savez comment reproduire l'erreur, mais la difficulté est que vous ne savez pas quelle partie du code est responsable de cette fonctionnalité.

Dans notre exemple d'application, le crash se produit lorsque vous cliquez sur le Bouton N. Cependant, il n'est pas si simple de trouver le code responsable de cette action :

Voyons comment utiliser le débogueur pour le trouver.

Points d'arrêt de la méthode

L'avantage des points d'arrêt de méthode par rapport aux points d'arrêt de ligne est qu'ils peuvent être utilisés dans des hiérarchies entières de classes. En quoi est-ce utile dans notre cas ?

Si vous regardez l'exemple de projet, vous verrez que toutes les classes d'actions sont dérivées de l'interface Action avec une seule méthode : perform().

La définition d'un point d'arrêt de méthode sur cette méthode d'interface suspendra l'application à chaque fois qu'une des méthodes dérivées est appelée. Pour définir un point d'arrêt de méthode, cliquez sur la ligne qui déclare la méthode.

Démarrez la session de débogage et cliquez sur le Bouton N. L'application est suspendue sur ActionImpl14. Nous savons désormais où se trouve le code correspondant à ce bouton.

Bien que dans cet article nous nous concentrions sur la recherche du bug, cette technique peut également vous faire gagner beaucoup de temps lorsque vous souhaitez comprendre comment quelque chose fonctionne dans une grande base de code.

Suspendre la candidature

L'approche avec les points d'arrêt de méthode fonctionne bien, mais elle repose sur l'hypothèse que nous connaissons quelque chose sur l'interface parent. Que se passe-t-il si cette hypothèse est fausse ou si nous ne pouvons pas utiliser cette approche pour une autre raison ?

Eh bien, nous pouvons même le faire sans points d'arrêt. Cliquez sur le bouton N et pendant que l'application se bloque, accédez à IntelliJ IDEA. Dans le menu principal, sélectionnez Exécuter | Actions de débogage | Pause du programme.

L'application se suspendra, nous permettant d'examiner l'état actuel des threads dans l'onglet Threads & Variables. Cela nous donne une idée de ce que fait l'application à ce moment-là. Puisqu'il est bloqué, nous pouvons identifier la méthode à l'origine du blocage et la retracer jusqu'au site d'appel.

Cette approche présente certains avantages par rapport à un thread dump plus traditionnel, que nous aborderons sous peu. Par exemple, il vous fournit des informations sur les variables sous une forme pratique et vous permet de contrôler l'exécution ultérieure du programme.

Astuce : pour plus de trucs et astuces avec Pause du programme, consultez Débogage sans points d'arrêt et Debugger.godMode()

Dumps de threads

Enfin, nous pouvons utiliser un thread dump, qui n'est pas strictement une fonctionnalité du débogueur. Il est disponible que vous utilisiez ou non le débogueur.

Cliquez sur le bouton N. Pendant que l'application plante, accédez à IntelliJ IDEA. Dans le menu principal, sélectionnez Exécuter | Actions de débogage | Obtenir le vidage du fil de discussion.

Explorez les fils de discussion disponibles sur la gauche et dans AWT-EventQueue vous verrez la cause du problème.

L'inconvénient des thread dumps est qu'ils ne fournissent qu'un instantané de l'état du programme au moment où ils ont été créés. Vous ne pouvez pas utiliser les thread dumps pour explorer des variables ou contrôler l'exécution d'un programme.

Dans notre exemple, nous n'avons pas besoin de recourir à un thread dump. Cependant, je voulais quand même mentionner cette technique car elle peut être utile dans d'autres cas, par exemple lorsque vous essayez de déboguer une application qui a été lancée sans l'agent de débogage.

Comprendre le problème

Quelle que soit la technique de débogage, nous arrivons à ActionImpl14. Dans cette classe, quelqu'un avait l'intention de faire le travail dans un thread séparé, mais a confondu Thread.start() avec Thread.run(), qui exécute le code dans le même thread que le code appelant.

L'analyseur statique d'IntelliJ IDEA nous en avertit même au moment de la conception :

Une méthode qui effectue de gros travaux (ou dort beaucoup dans ce cas) est appelée sur le thread de l'interface utilisateur et la bloque jusqu'à la fin de la méthode. C'est pourquoi nous ne pouvons rien faire dans l'interface utilisateur pendant un certain temps après avoir cliqué sur le Bouton N.

Remplacement à chaud

Maintenant que nous avons découvert la cause de l'erreur, corrigeons le problème.

Nous pourrions arrêter le programme, recompiler le code, puis l'exécuter à nouveau. Cependant, il n'est pas toujours judicieux de redéployer l'intégralité de l'application simplement parce qu'une petite modification a été apportée.

Faisons-le de manière intelligente. Tout d’abord, corrigez le code à l’aide de la solution rapide suggérée :

Une fois le code prêt, cliquez sur Exécuter | Actions de débogage | Recharger les classes modifiées. Une bulle apparaît, confirmant que le nouveau code est arrivé dans la VM.

Revenons à l'application et vérifions. Cliquer sur le bouton N ne fait plus planter l'application.

Astuce : Gardez à l'esprit que HotSwap a ses limites. Si vous êtes intéressé par les fonctionnalités étendues de HotSwap, ce serait peut-être une bonne idée de jeter un œil aux outils avancés tels que DCEVM ou JRebel

Résumé

Grâce à notre raisonnement et à quelques fonctionnalités du débogueur, nous avons pu localiser le code qui provoquait un crash de l'interface utilisateur dans notre projet. Nous avons ensuite procédé à la correction du code sans perdre de temps en recompilation et redistribution, qui peuvent être longues dans les projets du monde réel.

J'espère que vous trouverez les techniques décrites utiles. Faites-moi savoir ce que vous en pensez !

Si vous êtes intéressé par d'autres articles liés au débogage et au profilage, consultez certains de mes autres articles :

• Debugger.godMode() – Piratez une application JVM avec le débogueur
• Dépannage du débogueur lent
• Quel est le problème avec createDirectories() ? - Guide de profilage du processeur
• Débogage sans points d'arrêt

Restez à l'écoute pour en savoir plus !