Ferramentas de depuração

Há várias maneiras de depurar Jami de uma perspectiva de desenvolvedor, dependendo do que você quer depurar.

Registradores

A primeira maneira é usar registradores de tempo de execução. Iniciar o jami com -d ativará o registro pelo daemon (ou a seção Solução de problemas nas configurações gerais). Como o Jami utiliza várias bibliotecas, não ativamos todos os registros por padrão. Mas você pode passar algumas variáveis de ambiente para exibi-los:

  • SIPLOGLEVEL=5 para ativar os registros do PJSIP.

  • DHTLOGLEVEL=5 para ativar os registros do OpenDHT.

  • AVLOGLEVEL=50 para ativar os registros do ffmpeg.

Depuradores

Geralmente o seu IDE tem um depurador embutido. Caso contrário, pode usar o gdb, por exemplo, para poder adicionar pontos de interrupção, backtraces de crashes, imprimir estruturas internas, etc. É necessário compilar o projeto no modo DEBUG para obter símbolos de depuração.

Alguns comandos úteis:

  • b file.cpp:line - Adicionar um ponto de interrupção (file.cpp:line pode ser substituído por um símbolo)

  • t a a bt - (filamento aplicar todos os retrospectivos) para obter todos os retrospectivos

  • Ctrl + X / A - passar na visão gráfica

  • p - imprimir um valor interno.

Nota: o VSCode é totalmente suportado pelo Jami e pode ser utilizado para depurar o projeto.

Profilos

Os debuggers são úteis, mas não mostram o consumo de memória em tempo real / atividade de rede / uso de CPU. Para isso, você pode usar o perfil embuxado em seu IDE (do Android Studio ou Qt Creator / Visual Studio, por exemplo).

Endereço de desinfetador

Isso pode ser útil para detectar vazamentos, acidentes, possíveis impasses no tempo de execução. Para permitir isso, você pode compilar o daemon com CXXFLAGS+=”-fsanitize=address”. Outras bandeiras como tsan podem ser úteis.

Valgrind/Callgrind

O Valgrind é uma ferramenta para observar alocações, uso da CPU e muito mais, e pode ser usado por meio de: valgrind –tool=callgrind ./jami -d. Isso tornará o aplicativo muito lento, mas poderá fornecer relatórios úteis sobre a alocação de memória e o uso do desempenho (o KCacheGrind pode ser usado para ler os relatórios).

Teste

O daemon tem muitos testes e cobertura ativados. Se o daemon for construído de forma estática (caso contrário, os símbolos privados não estarão disponíveis), a adição de novos testes pode ajudar a reproduzir erros, resolver erros e evitar qualquer regressão. (cf. daemon/tests/unitTests`)

Agente.

Os testes estão usando apenas um daemon para simular ambos os pares. Portanto, pode ser difícil testar em vários ambientes. Outra possibilidade é escrever um cenário e executar um agente (documentação está disponível no repositório do daemon).

LTTng

Finalmente, os tracepoints podem ser criados e analisados. daemon/tools/trace fornecem a documentação e alguns exemplos. A vantagem do LTTng é que é mais rápido do que os registros, pode ser desencadeado por eventos do sistema e pode ser usado com tracepoints já presentes no kernel (de modo que possa ser usado com tracepoints de interfaces de rede).

Teste

Tanto os clientes quanto o daemon possuem testes. Os testes do daemon são escritos em C++ e utilizam o framework cppunit. Eles estão localizados no diretório daemon/tests.