Déboguer les applications qui ne répondent pas

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

Il existe de nombreux didacticiels de débogage 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 dépôt : 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 nous pouvons 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 de classes entières. 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 demande

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 Programme de pause voir 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.

Explorez les fils de discussion disponibles sur la gauche et dans AWT-EventQueue vous verrez quelle est 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 de 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, comme 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, on arrive à 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 fait de gros travaux (ou dort beaucoup dans ce cas) est appelée sur le thread de l'interface utilisateur et le bloque jusqu'à ce que la méthode se termine. 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 le réexécuter. 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.

Retournons à 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 comme 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. Dites-moi 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épanner le débogueur lent
• Quel est le problème avec createDirectories() ? - Guide du profilage du processeur
• Débogage sans points d'arrêt

Restez à l'écoute pour en savoir plus !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!