Development/FAQs/Debugging FAQ/pt-br: Difference between revisions

    From KDE TechBase
    (Created page with "É possível omitir o número da área na chamado ao kDebug adicionando o seguinte código no seu CMakeLists.txt principal:")
    (Updating to match new version of source page)
     
    (18 intermediate revisions by 2 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 depurar minha aplicação?===
    ===Quais ferramentas estão disponíveis para debugar meu aplicativo?===


    *kDebug() (kdDebug() no KDE3) são maneiras simples, porém eficientes de depurar uma aplicação.
    kDebug() (kdDebug() no KDE3) são maneiras simples, porém eficientes de debugar uma aplicação.
    *gdb, o depurador 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)
    *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 é um frontend gráfico para o gdb com interface KDE. Suporta diversos tipos Qt (incluindo QString) .
    *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.
    *Rastreador de vazamentos de memória: Veja kdesdk/kmtrace. O README explica o processo.
    *qdbus e dbus-viewer, do Qt permitem navegar e efetivar chamadas pelo barramento DBus.
    *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á.
    Verifique [[Special:myLanguage/Development/Tools|esta página]] no kdesdk, há muitos scripts úteis lá.
    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 depuro uma aplicação que utiliza uma kpart, o que devo fazer?===
    ===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 depuração da biblioteca compartilhada. Depois disso, você pode depurar normalmente.
    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:
    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=
    Line 66: Line 66:
                           QObject *, char const *, bool)' cont}}
                           QObject *, char const *, bool)' cont}}


    ===Como depuro um ioslave?===
    ===Como debugo um ioslave?===


    Veja [[Development/Tutorials/Debugging/Debugging IOSlaves|depurando ioslaves]]
    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? ===
    Line 74: Line 74:
    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).
    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).


    <span class="mw-translate-fuzzy">
    1 Verifique se o connect ( ) não imprime algum alerta no console durante a execução.
    1) Verifique se o connect() não imprime algum alerta no console durante a execução.
    </span>


    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.
    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.


    <span class="mw-translate-fuzzy">
    1b Ou você pode simplesmente verificar o que o connect ( ) retorna como um bool. Note que isso não fornecerá a mensagem de erro.
    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
    2) Verifique se o sinal foi realmente emitido
    3 Verifique se o receptor não foi deletado antes de receber o sinal
    3) Verifique se o receptor não foi deletado antes de receber o sinal
    4 Verifique se emissor ->signalsBlocked( ) retorna false
    4) Verifique se emissor->signalsBlocked() retorna false
    </span>


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


    ==Especificidades do KDE 4==
    Yes; see [[Special:myLanguage/Development/Tutorials/Debugging/Using_Error_Messages|this tutorial]].
     
    ===Há uma maneira preferencial para imprimir dados de depuração na stderr?===
     
    Sim, utilize kDebug():
     
    <syntaxhighlight lang="cpp-qt">
    #include <kdebug.h>
    kDebug() << "KMyApp just started";  
    </syntaxhighlight>
     
    A sintaxe é muito parecida com a do cout, você pode utilizar muitos dos tipos nativos entre o "<<". Isso irá imprimir uma mensage de depuração, 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 depuração, por exemplo kDebug(1234). Para isso, o número deve ser registrado em kdelibs/kdecore/kdebug.areas. As áreas de depuração tornam possível ativar e desativar a saída de depuração 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 depuração será escrita. Normalmente não é necessário registrar números de área para aplicações 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>
    add_definitions(-DKDE_DEFAULT_DEBUG_AREA=XXXX)
    </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 a aplicação 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.
     
    Para obter timestamps na sua saída de depuração, que é muito útil para depurar aplicaçãos multi-thread, com acesso à rede, e que utilizam operações assíncronas, execute <tt>export KDE_DEBUG_TIMESTAMP=1</tt> antes de executar sua aplicação. Desde KDE SC 4.5.


    [[Category:FAQs]]
    [[Category:FAQs]]
    [[Category:Programming]]
    [[Category:Programming]]

    Latest revision as of 10:25, 11 March 2016

    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

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

    Yes; see this tutorial.