Development/FAQs/Debugging FAQ/pt-br

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Geral

Como evitar o Dr. Konqi?

Você deve configurar a variável de ambiente KDE_DEBUG (para 1 ou qualquer outro valor).

Para restaurar o Dr. Konqi, remova a variável de ambiente KDE_DEBUG.

Exemplo:

Para evitar o Dr. Konqi:

export KDE_DEBUG=1

Para ver o Dr. Konqi:

unset KDE_DEBUG

Como mudar o Dr. Konqi para o modo de desenvolvedor?

Edite o arquivo $KDEHOME/share/config/drkonqirc e adicione o seguinte:

[drkonqi]
ConfigName=developer

O que é um core file? Como obtê-lo?

Um core file é uma imagem da memória no momento em que sua aplicação quebrou. Utilizando este arquivo, você pode determinar quais variáveis estavam configuradas e em que ponto a aplicação quebrou.

Algumas distribuições desativam a produção de core files. Para ativa-los novamente, utilize o comando ulimit -c unlimited.

Após obter o core file de um crash, você pode examina-lo com o comando gdb nomeapp core. Isso fará o gdb abrir o core file para a aplicação fornecida. Um vez no prompt do gdb, o comando mais útil é bt, que produz um backtrace do crash. Para mais informações sobre o uso do gdb, veja esta página

Quais ferramentas estão disponíveis para debugar meu aplicativo?

kDebug() (kdDebug() no KDE3) são maneiras simples, porém eficientes de debugar uma aplicação.

gdb, o debugador GNU, é a maneira mais rápida de executar a aplicação passo-a-passo e investigar suas variáveis (são recomendadas as versões do gdb >= 6.x)
Valgrind
kdbg é um frontend gráfico para o gdb com interface KDE. Suporta diversos tipos Qt (incluindo QString) .
Rastreador de vazamentos de memória: Veja kdesdk/kmtrace. O README explica o processo.
qdbus e dbusviewer, do Qt permitem navegar e efetivar chamadas pelo barramento DBus.

Verifique esta página no kdesdk, há muitos scripts úteis lá.

Como faço para exibir um QString no gdb?

Baixe o kdesdk, e adicione a seguinte linha ao seu ~/.gdbinit :

source /caminho/para/fontes/do/kdesdk/scripts/kde-devel-gdb

Você poderá então utilizar printqstring myqstring no gdb para ver seu conteúdo. Por exemplo, QString myqstring = QString::fromLatin1("contents"); pode ser examinada usando

(gdb) printqstring myqstring
$1 = "content"

Veja o arquivo kde-devel-gdb para descobrir outras macros definidas.

Eu não tenho nenhum símbolo quando debugo um aplicativo que utiliza uma kpart, o que devo fazer?

Você deve parar imediatamente após a main para carregar os símbolos de debug da biblioteca compartilhada. Depois disso, você pode debugar normalmente. Também é possível criar uma macro para o gdb, de forma que ele pare assim que a parte for carregada. Para o kword, por exemplo, eu utilizo:

define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *, 
                       QObject *, char const *, bool)' cont

Como debugo um ioslave?

Veja debugando ioslaves

Por que minha conexão entre sinal e slot não está funcionando?

Aqui estão alguns passos que você pode seguir parar descobrir o motivo da sua conexão sinal/slot não estar funcionando (por algum motivo o slot não é chamado).

1 Verifique se o connect ( ) não imprime algum alerta no console durante a execução.

Se imprimir, verifique se a macro Q_OBJECT foi utilizada, se os nomes dos parâmetros não estão no connect, se os tipos dos parâmetros são compatíveis, se o slot está definido e se o moc foi compilado.

1b Ou você pode simplesmente verificar o que o connect ( ) retorna como um bool. Note que isso não fornecerá a mensagem de erro. 2 Verifique se o sinal foi realmente emitido 3 Verifique se o receptor não foi deletado antes de receber o sinal 4 Verifique se emissor ->signalsBlocked( ) retorna false

Especificidades do KDE 4

Há uma maneira preferencial para imprimir dados de debug na stderr?

Sim, utilize kDebug():

#include <kdebug.h>
kDebug() << "KMyApp just started";

A sintaxe é muito parecida com a do cout, você pode utilizar muitos dos tipos nativos entre o "<<". Isso irá imprimir uma mensagem de debug, a qual será automaticamente desativada na versão final (pelo --disable-debug). Caso você queira que a mensagem permaneça na versão final, por ser um alerta ou erro, utilize kWarning() ou kError().

É recomendado que componentes e bibliotecas utilizem uma número de área de debug, por exemplo kDebug(1234). Para isso, o número deve ser registrado em kdelibs/kdecore/kdebug.areas. As áreas de debug tornam possível ativar e desativar a saída de debug para áreas específicas utilizando o programa kdebugdialog, que é parte do kdebase. O kdebugdialog --fullmode também permite controlar onde a saída de debug será escrita. Normalmente não é necessário registrar números de área para aplicativos independentes, exceto quando elas são tão complexas que você queira dividir sua saída em múltiplas áreas.

É possível omitir o número da área na chamado ao kDebug adicionando o seguinte código no seu CMakeLists.txt principal:

add_definitions(-DKDE_DEFAULT_DEBUG_AREA=XXXX)

Para mais informações sobre isso, visite este artigo no blog do Allen Winter.

Para deixar claro: NÃO use qDebug, que não é desativado nas versões finais. Também é melhor evitar assert() ou kFatal(), que quebram o aplicativo quando algo de errado ocorre, proporcionando uma experiência ruim ao usuário. É melhor detectar os erros, imprimir um kWarning() ou kError(), e recuperar-se quando possível.

Para obter timestamps na sua saída de debug, que é muito útil para debugar aplicativos multi-thread, com acesso à rede, e que utilizam operações assíncronas, execute export KDE_DEBUG_TIMESTAMP=1 antes de executar seu aplicativo. Desde KDE SC 4.5.