Herramientas de desarreglamiento

Hay varias maneras de deshacer Jami desde la perspectiva del desarrollador, dependiendo de lo que quieras deshacer.

Los madereros

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 para permitir los registros de PJSIP.

  • DHTLOGLEVEL=5 para permitir registros de OpenDHT.

  • AVLOGLEVEL=50 para permitir los registros de ffmpeg.

Desarregladores

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.

Algunos comandos útiles:

  • b file.cpp:line - Añadir un punto de ruptura (file.cpp:line puede ser sustituido por un símbolo)

  • t a a bt - (files aplicados a todos los retrocesos) para obtener todos los retrocesos

  • Ctrl + X / A - pase en vista gráfica

  • p - imprimir un valor interno.

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

Profiles de información

Los debuggers son útiles, pero no muestran el consumo de memoria en tiempo real / actividad de red / uso de CPU. Para esto, puede usar el perfilador integrado en su IDE (desde Android Studio o Qt Creator / Visual Studio por ejemplo).

Dirección de desinfectante

Esto puede ser útil para detectar fugas, choques, posibles bloqueos en el tiempo de ejecución. Para permitir esto, puede compilar el daemon con CXXFLAGS+=»-fsanitize=adress». Otras banderas como tsan pueden ser útiles.

Valgrind/Callgrind

Valgrind es una herramienta para observar las asignaciones, el uso de la CPU y más y se puede utilizar a través de: valgrind –tool=callgrind./jami -d. Esto hará que la aplicación sea muy lenta, pero puede proporcionar informes útiles sobre la asignación de memoria / uso de rendimiento (KCacheGrind se puede utilizar para leer informes).

Pruebas

Daemon tiene muchas pruebas y cobertura habilitadas. Si el daemon está construido en estático (otros símbolos privados no estarán disponibles), agregar nuevas pruebas puede ayudar a reproducir errores, resolver errores y evitar cualquier regresión.

Agente, ¿ qué?

Las pruebas solo utilizan un daemon para simular ambos pares. Por lo que puede ser difícil probar en diversos entornos. Otra posibilidad es escribir un escenario y ejecutar un agente (la documentación está disponible en el repositorio del daemon).

El número de personas

Finalmente, se pueden crear y analizar puntos de seguimiento. daemon/tools/trace proporcionan la documentación y algunos ejemplos. La ventaja de LTTng es que es más rápido que los registros, puede ser desencadenado por eventos del sistema y puede ser utilizado con puntos de seguimiento ya presentes en el núcleo (de modo que pueda ser utilizado con puntos de seguimiento de interfaces de red).

Pruebas

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.