Development/FAQs/Debugging FAQ/pt-br: Difference between revisions
Vitorboschi (talk | contribs) (Created page with "Sim, utilize kDebug():") |
(Updating to match new version of source page) |
||
(34 intermediate revisions by 3 users not shown) | |||
Line 31: | Line 31: | ||
Para mais informações sobre o uso do gdb, veja [[Special:myLanguage/Development/Tutorzials/Debugging/Debugging_with_GDB|esta página]] | Para mais informações sobre o uso do gdb, veja [[Special:myLanguage/Development/Tutorzials/Debugging/Debugging_with_GDB|esta página]] | ||
===Quais ferramentas estão disponíveis para | ===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, | *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 | *Valgrind | ||
*kdbg | *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 | *qdbus e dbusviewer, do Qt permitem navegar e efetivar chamadas pelo barramento DBus. | ||
Verifique [[Special:myLanguage/Development/Tools|esta página]] no kdesdk, há muitos scripts úteis lá. | |||
===Como faço para exibir um QString no gdb?=== | ===Como faço para exibir um QString no gdb?=== | ||
Baixe o kdesdk, e adicione a seguinte linha ao seu ~/.gdbinit : | |||
{{Input|1=source / | {{Input|1=source /caminho/para/fontes/do/kdesdk/scripts/kde-devel-gdb}} | ||
Você poderá então utilizar <code>printqstring myqstring</code> no gdb para ver seu conteúdo. | |||
Por exemplo, <code>QString myqstring = QString::fromLatin1("contents");</code> pode ser examinada usando | |||
{{Input|1= | {{Input|1= | ||
Line 55: | Line 55: | ||
Veja o arquivo <tt>kde-devel-gdb</tt> para descobrir outras macros definidas. | Veja o arquivo <tt>kde-devel-gdb</tt> para descobrir outras macros definidas. | ||
===Eu não tenho nenhum símbolo quando | ===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: | |||
{{Input|1= | {{Input|1= | ||
define startkword | define startkword | ||
Line 66: | Line 66: | ||
QObject *, char const *, bool)' cont}} | QObject *, char const *, bool)' cont}} | ||
===Como | ===Como debugo um ioslave?=== | ||
Veja [[Development/Tutorials/Debugging/Debugging IOSlaves|debugando ioslaves]] | |||
=== Por que minha conexão entre sinal e slot não está funcionando? === | === 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 | 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 | 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 | 2 Verifique se o sinal foi realmente emitido | ||
3 | 3 Verifique se o receptor não foi deletado antes de receber o sinal | ||
4 | 4 Verifique se emissor ->signalsBlocked( ) retorna false | ||
==KDE 4 | ==Especificidades do KDE 4== | ||
=== | ===Há uma maneira preferencial para imprimir dados de debug na stderr?=== | ||
Sim, utilize kDebug(): | Sim, utilize kDebug(): | ||
Line 95: | Line 95: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
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 <tt>--disable-debug</tt>). Caso você queira que a mensagem permaneça na versão final, por ser um alerta ou erro, utilize <tt>kWarning()</tt> ou <tt>kError()</tt>. | |||
É 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 {{program|kdebugdialog}}, que é parte do kdebase. O <tt>kdebugdialog --fullmode</tt> 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: | |||
<code> | <code> | ||
Line 105: | Line 105: | ||
</code> | </code> | ||
Para mais informações sobre isso, visite [http://www.kdedevelopers.org/node/3171 este artigo no blog do Allen Winter]. | |||
Para deixar claro: NÃO use <tt>qDebug</tt>, que não é desativado nas versões finais. Também é melhor evitar <tt>assert()</tt> ou <tt>kFatal()</tt>, que quebram o aplicativo quando algo de errado ocorre, proporcionando uma experiência ruim ao usuário. É melhor detectar os erros, imprimir um <tt>kWarning()</tt> ou <tt>kError()</tt>, e recuperar-se quando possível. | |||
<span class="mw-translate-fuzzy"> | |||
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 <tt>export KDE_DEBUG_TIMESTAMP=1</tt> antes de executar seu aplicativo. Desde KDE SC 4.5. | |||
</span> | |||
[[Category:FAQs]] | [[Category:FAQs]] | ||
[[Category:Programming]] | [[Category:Programming]] |
Revision as of 18:18, 7 April 2013
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.