| Development/FAQs/Debugging FAQ | Current message text |
|---|---|
| ↓...ing FAQ/Page display title/pt-br | Desenvolvimento/FAQs/FAQ sobre debug |
| ↓...pment/FAQs/Debugging FAQ/1/pt-br | ==Geral== |
| ↓...pment/FAQs/Debugging FAQ/2/pt-br | ===Como evitar o Dr. Konqi?=== |
| ↓...pment/FAQs/Debugging FAQ/3/pt-br | Você deve configurar a variável de ambiente KDE_DEBUG (para 1 ou qualquer outro valor). |
| ↓...pment/FAQs/Debugging FAQ/4/pt-br | Para restaurar o Dr. Konqi, remova a variável de ambiente KDE_DEBUG. |
| ↓...pment/FAQs/Debugging FAQ/5/pt-br | Exemplo:<br /> *Para evitar o Dr. Konqi: ::<code>export KDE_DEBUG=1</code> *Para ver o Dr. Konqi: ::<code>unset KDE_DEBUG</code> |
| ↓...pment/FAQs/Debugging FAQ/6/pt-br | ===Como mudar o Dr. Konqi para o modo de desenvolvedor?=== |
| ↓...pment/FAQs/Debugging FAQ/7/pt-br | Edite o arquivo $KDEHOME/share/config/drkonqirc e adicione o seguinte: <syntaxhighlight lang="ini"> [drkonqi] ConfigName=developer </syntaxhighlight> |
| ↓...pment/FAQs/Debugging FAQ/8/pt-br | ===O que é um core file? Como obtê-lo?=== |
| ↓...pment/FAQs/Debugging FAQ/9/pt-br | 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. |
| ↓...ment/FAQs/Debugging FAQ/10/pt-br | Algumas distribuições desativam a produção de core files. Para ativa-los novamente, utilize o comando <code>ulimit -c unlimited</code>. |
| ↓...ment/FAQs/Debugging FAQ/11/pt-br | 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 é <code>bt</code>, que produz um backtrace do crash. Para mais informações sobre o uso do gdb, veja [[Special:myLanguage/Development/Tutorzials/Debugging/Debugging_with_GDB|esta página]] |
| ↓...ment/FAQs/Debugging FAQ/12/pt-br | ===Quais ferramentas estão disponíveis para debugar meu aplicativo?=== |
| ↓...ment/FAQs/Debugging FAQ/13/pt-br | 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. |
| ↓...ment/FAQs/Debugging FAQ/14/pt-br | Verifique [[Special:myLanguage/Development/Tools|esta página]] no kdesdk, há muitos scripts úteis lá. |
| ↓...ment/FAQs/Debugging FAQ/15/pt-br | ===Como faço para exibir um QString no gdb?=== |
| ↓...ment/FAQs/Debugging FAQ/16/pt-br | Baixe o kdesdk, e adicione a seguinte linha ao seu ~/.gdbinit : {{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 |
| ↓...ment/FAQs/Debugging FAQ/17/pt-br | {{Input|1= (gdb) printqstring myqstring $1 = "content"}} |
| ↓...ment/FAQs/Debugging FAQ/18/pt-br | Veja o arquivo <tt>kde-devel-gdb</tt> para descobrir outras macros definidas. |
| ↓...ment/FAQs/Debugging FAQ/19/pt-br | ===Eu não tenho nenhum símbolo quando debugo um aplicativo que utiliza uma kpart, o que devo fazer?=== |
| ↓...ment/FAQs/Debugging FAQ/20/pt-br | 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= define startkword break main run break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *, char const *, bool)' cont}} |
| ↓...ment/FAQs/Debugging FAQ/21/pt-br | ===Como debugo um ioslave?=== |
| ↓...ment/FAQs/Debugging FAQ/22/pt-br | Veja [[Development/Tutorials/Debugging/Debugging IOSlaves|debugando ioslaves]] |
| ↓...ment/FAQs/Debugging FAQ/23/pt-br | === Por que minha conexão entre sinal e slot não está funcionando? === |
| ↓...ment/FAQs/Debugging FAQ/24/pt-br | 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). |
| ↓...ment/FAQs/Debugging FAQ/25/pt-br | 1 Verifique se o connect ( ) não imprime algum alerta no console durante a execução. |
| ↓...ment/FAQs/Debugging FAQ/26/pt-br | 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. |
| ↓...ment/FAQs/Debugging FAQ/27/pt-br | 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 |
| ↓...ment/FAQs/Debugging FAQ/28/pt-br | ==Especificidades do KDE 4== |
| ↓...ment/FAQs/Debugging FAQ/29/pt-br | ===Há uma maneira preferencial para imprimir dados de debug na stderr?=== |
| ↓...ment/FAQs/Debugging FAQ/30/pt-br | Sim, utilize kDebug(): |
| ↓...ment/FAQs/Debugging FAQ/31/pt-br | <syntaxhighlight lang="cpp-qt"> #include <kdebug.h> kDebug() << "KMyApp just started"; </syntaxhighlight> |
| ↓...ment/FAQs/Debugging FAQ/32/pt-br | 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>. |
| ↓...ment/FAQs/Debugging FAQ/33/pt-br | É 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. |
| ↓...ment/FAQs/Debugging FAQ/34/pt-br | É possível omitir o número da área na chamado ao kDebug adicionando o seguinte código no seu CMakeLists.txt principal: |
| ↓...ment/FAQs/Debugging FAQ/35/pt-br | <code> add_definitions(-DKDE_DEFAULT_DEBUG_AREA=XXXX) </code> |
| ↓...ment/FAQs/Debugging FAQ/36/pt-br | Para mais informações sobre isso, visite [http://www.kdedevelopers.org/node/3171 este artigo no blog do Allen Winter]. |
| ↓...ment/FAQs/Debugging FAQ/37/pt-br | 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. |
| ↓...ment/FAQs/Debugging FAQ/38/pt-br | 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. |
| ↓...ment/FAQs/Debugging FAQ/39/pt-br | [[Category:FAQs]] [[Category:Programming]] |
KDE TechBase 