Les outils de débogage

Il y a plusieurs façons de déboguer Jami d’un point de vue de développeur, selon ce que vous voulez déboguer.

Les bûcherons

La première façon est d’utiliser des logs de temps d’exécution. En commençant jami avec -d, vous pourrez enregistrer par le démon (ou la section Troubleshoot dans les paramètres généraux).

  • SIPLOGLEVEL=5 pour permettre les journaux de PJSIP.

  • DHTLOGLEVEL=5 pour permettre les journaux à partir d’OpenDHT.

  • AVLOGLEVEL=50 pour permettre les journaux à partir de ffmpeg.

Débogageurs

En général, votre IDE dispose d’un débogageur intégré. Sinon, vous pouvez utiliser gdb par exemple pour pouvoir ajouter des points de rupture, des retombées des crashs, imprimer des structures internes, etc. Vous devez compiler le projet en mode DEBUG pour obtenir des symboles de débogage.

Quelques commandes utiles:

  • b file.cpp:line - Ajouter un point de rupture (file.cpp:line peut être remplacé par un symbole)

  • t a a bt - (fil appliquer tous les traces) pour obtenir tous les traces

  • Ctrl + X / A - passe dans la vue graphique

  • p - imprimer une valeur interne.

Les profils

Les débogageurs sont utiles, mais ils ne montrent pas la consommation de mémoire en temps réel / l’activité réseau / l’utilisation du processeur. Pour cela, vous pouvez utiliser le profilé intégré dans votre EDI (à partir d’Android Studio ou de Qt Creator / Visual Studio par exemple).

Adresse désinfectant

Cela peut être utile pour détecter des fuites, des accidents, des impasses potentielles en temps d’exécution. Pour le faire, vous pouvez compiler le daemon avec CXXFLAGS+= »-fsanitize=address ». D’autres drapeaux comme tsan peuvent être utiles.

Les produits de la catégorie « Vallgrind »

Valgrind est un outil permettant de surveiller les allocations, l’utilisation de la CPU et plus encore et peut être utilisé via: valgrind –tool=callgrind./jami -d. Cela rendra l’application très lente mais peut fournir des rapports utiles sur l’utilisation de l’allocation de mémoire / de la performance (KCacheGrind peut être utilisé pour lire des rapports).

Tests

Si le daemon est construit en statique (autrement les symboles privés ne seront pas disponibles), l’ajout de nouveaux tests peut aider à reproduire les bugs, à résoudre les bugs et à éviter toute régression.

Agent

Les tests utilisent seulement un daemon pour simuler les deux pairs. Il peut donc être difficile de tester dans divers environnements.

LTTng

Enfin, des tracepoints peuvent être créés et analysés. daemon/tools/trace fournissent la documentation et quelques exemples. L’avantage de LTTng est qu’il est plus rapide que les journaux, peut être déclenché par des événements du système et peut être utilisé avec des tracepoints déjà présents dans le noyau (de sorte qu’il peut être utilisé avec des tracepoints d’interfaces réseau).