Herramientas de depuración

Hay varias formas de depurar Jami desde la perspectiva del desarrollador, según lo que se requiera depurar.

Los madereros

La primera forma es usar registradores de tiempo de ejecución. Iniciar “jami” con “- d “ habilitará el registro por parte del demonio (o la sección Solucionar problemas en la configuración general). Todos los registros no están habilitados de forma predeterminada, ya que Jami usa varias bibliotecas. Sin embargo, pasar variables de entorno habilita los registros:

  • SIPLOGLEVEL=5 habilita registros desde PJSIP.

  • DHTLOGLEVEL=5 habilita registros desde OpenDHT.

  • AVLOGLEVEL=50 habilita registros desde ffmpeg.

Desarregladores

Generalmente, el IDE tiene un depurador integrado. De lo contrario, se puede usar` gdb”, por ejemplo, para poder agregar puntos de interrupción, trazas inversas de bloqueos, imprimir estructuras internas, etc. Para obtener símbolos de depuración, es necesario compilar el proyecto en modo DEBUG.

Algunos comandos útiles:

  • b file.cpp:line - agrega un punto de interrupción (se puede reemplazar file.cpp:line 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.

Nota

Visual Studio Code es totalmente compatible con Jami y se puede utilizar para depurar el proyecto.

Profiles de información

Los depuradores son útiles, pero no muestran el consumo de memoria en tiempo real/actividad de la red/ el uso de la CPU. Para ello, un perfil incrustado en el (Android Studio, Qt Creator/Visual Studio, etc.) Se puede utilizar IDE.

AddressSanitizer

AddressSanitizer puede ser útil para detectar fugas, bloqueos y posibles puntos muertos en tiempo de ejecución. Para habilitar esto, compile el demonio con “CXXFLAGS + =» - fsanitize = address». Pueden ser útiles otras banderas como tsan”.

Valgrind/Callgrind

Valgrind] (https://valgrind.org/) es una herramienta para ver asignaciones, uso de CPU y más, y se puede usar a través de: valgrind tool 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 del rendimiento (KCacheGrind se puede usar para leer informes).

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 rastreo. “daemon/tools `trace” proporciona la documentación y algunos ejemplos. La ventaja de LTTng es que es más rápido que los registros, puede activarse mediante eventos del sistema y puede usarse con puntos de rastreo ya presentes en el kernel (de modo que puede usarse con puntos de rastreo desde interfaces de red).

Pruebas

Both clients and daemon have tests. Coverage is enabled. Daemon’s tests are written in C++ and use the cppunit framework. They are located in the daemon/tests directory. If the daemon is statically built (else the private symbols will be unavailable), adding new tests can help to reproduce bugs, solve bugs, and avoid any regression.