Debugging tools

There are several ways to debug Jami from a developer perspective, depending on what is required to be debugged.

목재

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). All logs are not enabled by default, as Jami uses several libraries. However, passing environment variables enables logs:

  • SIPLOGLEVEL=5 enables logs from PJSIP.

  • DHTLOGLEVEL=5 enables logs from OpenDHT.

  • AVLOGLEVEL=50 enables logs from ffmpeg.

디버거

Generally, the IDE has an embedded debugger. Otherwise, gdb can be used, for example, to be able to add breakpoints, backtraces from crashes, print internal structures, etc. To get debug symbols, it is required to compile the project in DEBUG mode.

몇 가지 유용한 명령어:

  • b file.cpp:line - add a breakpoint (file.cpp:line can be replaced by a symbol)

  • t a a bt - (이하로 모든 배트라인을 적용) 모든 배트라인을 얻으려면

  • Ctrl + X / A - 그래픽 시각에서 통과

  • p - 내부 값을 인쇄합니다.

참고

Visual Studio Code is fully supported by Jami and can be used to debug the project.

프로파일러

Debuggers are useful, but they do not show real-time memory consumption/network activity/CPU usage. For this, an embedded profiler in the (Android Studio, Qt Creator/Visual Studio, etc.) IDE can be used.

AddressSanitizer

AddressSanitizer can be useful to detect leaks, crashes, and potential deadlocks at runtime. To enable this, compile the daemon with CXXFLAGS+="-fsanitize=address". Other flags like tsan may be useful.

발그린드/콜그린드

Valgrind is a tool to watch allocations, CPU usage, and more and can be used via: valgrind --tool=callgrind ./jami -d. This will make the application very slow but can provide useful reports about memory allocation/performance usage (KCacheGrind can be used to read reports).

에이전트

테스트는 두 개의 동동자를 시뮬레이션하기 위해 하나의 데이몬을 사용한다. 따라서 다양한 환경에서 테스트하는 것이 어려울 수 있습니다. 또 다른 가능성은 시나리오를 작성하고 에이전트를 실행하는 것입니다.

이산화탄소

Finally, tracepoints can be created and analyzed. daemon/tools/trace provide the documentation and some examples. The advantage of LTTng is that it is quicker than logs, can be triggered by system events and can be used with tracepoints already present in the kernel (so that it can be used with tracepoints from network interfaces).

시험

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.