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

The first way is to use runtime loggers. Starting jami with -d will enable logging by the daemon (or the Troubleshoot section in the General settings). Because Jami uses several libraries, we do not enable all logs by default. But you can pass some environment variables to show it:

  • 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

Generally your IDE has an embedded debugger. Else, you can use gdb for example to be able to add breakpoints, backtraces from crashes, print internal structures, etc. You need to compile the project in DEBUG mode to get debug symbols.

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.

Note: VSCode is fully supported by Jami and can be used to debug the project.

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).

Tests

Both clients and daemon have tests. Daemon’s tests are written in C++ and use the cppunit framework. They are located in the daemon/tests directory.