Débogage des applications inactives

Lire dans d'autres langues : Anglais Español 中文

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 fournissent à elles seules de nombreux outils pour déboguer votre application, les scénarios du monde réel peuvent être un peu plus complexes et nécessiter une approche plus avancée.

Dans cet article, nous apprendrons comment trouver les codes qui provoquent un gel de l'interface utilisateur sans beaucoup de connaissances préalables en conception et corriger les codes défectueux en temps réel.

Le problème

Si vous souhaitez suivre, 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 le bug, mais la difficulté est que vous ne savez pas quelle partie du code est responsable de cette fonctionnalité.

Dans notre exemple d'application, la mise en veille 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 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 que l'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 du débogueur et cliquez sur le Bouton N. L'application est suspendue dans 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 l'application

L'approche avec les points de verrouillage 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 le faire même sans les points d'arrêt. Cliquez sur le Bouton N, et pendant que l'application est verrouillée, 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 permet de comprendre ce que fait actuellement l’application. Puisqu'il est verrouillé, nous pouvons identifier la méthode de verrouillage et la retracer jusqu'à l'emplacement de l'appel.

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

Remarque : Pour plus de trucs et astuces avec Programme de pause voir Déboguer 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 Bouton N. Pendant que l'application est verrouillée, accédez à IntelliJ IDEA. Dans le menu principal, sélectionnez Exécuter | Actions de débogage | Obtenir le vidage du fil.

Regardez les discussions disponibles sur la gauche et sous 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é effectué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 effectue un travail intensif (ou un sommeil intense dans ce cas) est appelée sur le thread de l'interface utilisateur et le 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 du bug, résolvons le problème.

Nous pourrions arrêter le programme, recompiler le code puis le réexécuter. Cependant, il n'est pas toujours pratique de replier l'intégralité de la demande juste pour un petit changement.

Faisons cela de manière intelligente. Tout d’abord, corrigez le code à l’aide du correctif rapide suggéré :

Une fois le code prêt, cliquez sur Exécuter | Actions de débogage | Recharger les classes modifiées. Un message apparaît, confirmant que le nouveau code a atteint la VM.

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

Astuce : N'oubliez pas que HotSwap a ses limites. Si vous êtes intéressé par les capacité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 à certaines fonctionnalités du débogueur, nous avons pu localiser le code qui provoquait le gel de l'interface utilisateur dans notre projet. Nous procédons ensuite à la correction du code sans perdre de temps en recompilation et en redéploiement, ce qui peut prendre beaucoup de temps 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 de la lenteur du débogueur
• Débogage sans points d'arrêt
• Quel est le problème avec createDirectories() ? - Guide du profil CPU

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!