Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2020-07-25 12:44:22
Size: 8905
Editor: ?RafaelFontenelle
Comment: Created page. Localization in progress.
Revision 6 as of 2021-08-10 19:07:46
Size: 9766
Editor: ThiagoPezzo
Comment: reviewed / revisão
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#language pt_BR #language pt-br
## English revision: 70
Line 3: Line 4:
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[HowToGetABacktrace|English]] - Português (Brasil) - [[ru/HowToGetABacktrace|Русский]] -~ ~-[[pt_BR/DebianWiki/EditorGuide#translation|Traduções]]: [[HowToGetABacktrace|English]] - Português (Brasil) - [[ru/HowToGetABacktrace|Русский]] -~
Line 8: Line 9:
== How To Get a Meaningful Backtrace ==
This page will attempt to explain how to get a meaningful debugging backtrace from a reproducible program crash. For this example, we will install the package with debugging symbols for "hello" or if this is not available rebuild & install the "hello" package so that we keep debugging information.

For reference, a "#" at the beginning of a line means that what follows is a command that has to be executed as root (or sudo). A "$" at the beginning means that what follows is a command that should be executed as your normal user. A "(gdb)" at the beginning means that you should be typing the rest of the command line at the gdb (GNU Debugger) prompt.
== Como obter um backtrace significativo ==
Esta página tentará explicar como obter um backtrace de depuração significativo de uma falha reproduzível no programa. Neste exemplo, instalaremos o pacote com símbolos de depuração para "hello" ou, se não estiver disponível, reconstrua e instale o pacote "hello" para manter as informações de depuração.

Para referência, um "#" no início de uma linha significa que o que vem a seguir é um comando que deve ser executado como root (ou sudo). Um "$" no início significa que o que vem a seguir é um comando que deve ser executado como seu(sua) usuário(a) normal. Um "(gdb)" no início significa que você deve digitar o restante da linha de comando no prompt do gdb (GNU Debugger).
Line 17: Line 17:
=== Installing the debugging symbols ===

Make sure you have the AutomaticDebugPackages archive listed in your SourcesList:
=== Instalando os símbolos de depuração ===

Verifique se vo tem o pacote AutomaticDebugPackages listado em seu [[pt_BR/SourcesList|SourcesList]]:
Line 27: Line 27:
So, depending on your [[DebianReleases|release]], it might look like this: Então, dependendo da sua [[pt_BR/DebianReleases|versão]], pode se parecer com isso:
Line 34: Line 34:
Other possibilities are: Outras possibilidades são:
Line 41: Line 41:
If you are using Debian buster or later, install DebianPackage:debian-goodies and run the find-dbgsym-packages script to find which dbgsym packages to install:

{{{
$ find-dbgsym-packages /usr/bin/hello 
Se você estiver usando o Debian buster ou posterior, instale DebianPackage:debian-goodies e execute o script find-dbgsym-packages para descobrir quais pacotes do dbgsym instalar:

{{{
$ find-dbgsym-packages /usr/bin/hello
Line 48: Line 48:
Otherwise, to see if the package you’re trying to debug includes a -dbgsym or -dbg package (e.g. for the ''hello'' source package, a ''hello-dbgsym'' or ''hello-dbg'' package exists), search for it in your package manager. On the command line you can use the following command. Caso contrário, para ver se o pacote que você está tentando depurar inclui um pacote -dbgsym ou -dbg (por exemplo, para o pacote fonte ''hello'', um pacote '' ello-dbgsym'' ou ''hello-dbg'' existe), procure-o no seu gerenciador de pacotes. Na linha de comando, você pode usar o seguinte comando:
Line 54: Line 54:
If that doesn't have your debug package either, you could try to rebuild the package as explained in the next section.

If an appropriate package was found you should just be able to install the appropriate debug package and skip the rebuilding process in the following instructions and go straight to running gdb.
Se esse também não tiver seu pacote de depuração, você pode tentar reconstruir o pacote, conforme explicado na próxima seção.

Se um pacote apropriado for encontrado, você poderá instalar o pacote de depuração apropriado e pular o processo de reconstrução nas instruções a seguir e seguir diretamente para a execução do gdb.
Line 62: Line 62:
=== Rebuilding the package you’re debugging ===

''You may skip this section if you were able to install the necessary debug symbols package(s) from the previous section.''
 * Install the basic development packages and the build-dependencies for the package we want to rebuild. Note that you can skip the rebuilding part and go straight to running gdb, but it is unlikely that you will get a useful backtrace. (If the build-dep line fails, check you have deb-src lines in [[SourcesList|apt sources]])
=== Reconstruindo o pacote que você está depurando ===

''Você pode pular esta seção se conseguir instalar os pacotes de símbolos de depuração necessários na seção anterior.''
 * Instale os pacotes básicos de desenvolvimento e as dependências de compilação para o pacote que queremos reconstruir. Observe que você pode pular a parte de reconstrução e ir direto para o gdb, mas é improvável que você obtenha um backtrace útil (se a linha build-dep falhar, verifique se você possui linhas deb-src em [[pt_BR/SourcesList|apt sources]]).
Line 72: Line 72:
 * Download & rebuild our package from source, keeping debugging symbols  * Faça o download e reconstrua nosso pacote da fonte, mantendo os símbolos de depuração:
Line 78: Line 78:
 * Install our newly built package(s). There may be multiple .deb packages generated, so make sure to install only the ones you want. In this example, the .deb generated was called hello_2.1.1-4_amd64.deb.  * Instale nossos pacotes recém-construídos. Pode haver vários pacotes .deb gerados, portanto, instale apenas os que você deseja. Neste exemplo, o .deb gerado foi chamado hello_2.1.1-4_amd64.deb:
Line 84: Line 84:
 * You can ensure the binaries installed from your .deb have debugging symbols with the 'file' command, or with gdb itself (see below).

{{{
$ file /usr/bin/hello # output should contain "not stripped"
}}}

=== Running gdb ===

==== Batch mode ====

For including a backtrace in a bug report, you can run this command and then try to reproduce your crash:
 * Você pode garantir que os binários instalados no seu .deb tenham símbolos de depuração com o comando "file" ou com o próprio gdb (veja abaixo):

{{{
$ file /usr/bin/hello # a saída deve conter "not stripped"
}}}

=== Executando o gdb ===

==== Modo em lote ====

Para incluir um backtrace em um relatório de bug, você pode executar este comando e tentar reproduzir sua falha:
Line 100: Line 100:
==== Interactively ====

Use this method if you need to interactively run gdb.

 * Now run your program as follows, replacing "[--args]" with any arguments you want to run the program with:{{{
==== Interativamente ====

Use este método se precisar executar interativamente o gdb.

 * Execute seu programa como apresentado a seguir, substituindo "[--args]" com quaisquer argumentos com os quais você deseje executar programa:{{{
Line 111: Line 111:
 * Then try to reproduce your crash. If you’re lucky, a crash will occur and you’ll be dropped back to the gdb prompt.
 * If you are not so lucky to get a crash but instead get a freeze, you can still get gdb prompt by pressing CTRL-C in the terminal running gdb.
 * At that point, you can run:{{{
 * Em seguida, tente reproduzir sua falha. Se você tiver sorte, ocorrerá uma falha e você voltará ao prompt do gdb.
 * Se você não tiver tanta sorte em fazer o programa travar, mas somente congelar, ainda poderá receber o prompt do gdb pressionando CTRL-C no terminal que está executando o gdb.
 * Neste ponto, você pode executar:{{{
Line 116: Line 116:
 * You’ll then get a lot of output, which you can then copy & paste to a bug followup e-mail or other bug reporting tool.
 * When you’re done with gdb, you can just run:{{{
 * Você obterá muita saída, que poderá copiar e colar em um e-mail de acompanhamento de relatório de bug ou em outra ferramenta de relatório de bug.
 * Quando você tiver terminado com o gdb, você pode simplesmente executar:{{{
Line 121: Line 121:
If the problem seems to be in a major library such as libc6, xlibs, or libgtk2.0-0, you’ll want to install the appropriate -dbg package (e.g. libc6-dbg in the case of libc6) and then run the problematic program again under gdb.

Often, you will see a backtrace where one or more of the top lines is in malloc() or g_malloc(). When this happens, chances are your backtrace isn’t very useful. The easiest way to find some useful information is to set the environment variable MALLOC_CHECK_ to a value of 2. You can do this while running gdb by doing this:{{{
Se o problema parece estar em uma biblioteca importante, como libc6, xlibs ou libgtk2.0-0, instale o pacote -dbg apropriado (por exemplo, libc6-dbg no caso da libc6) e execute o programa problemático novamente no gdb.

Frequentemente, você verá um backtrace em que uma ou mais das principais linhas estão em malloc() ou g_malloc(). Quando isso acontece, é provável que seu backtrace não seja muito útil. A maneira mais fácil de encontrar algumas informações úteis é definir a variável de ambiente MALLOC_CHECK_ como um valor de 2. Você pode fazer isso enquanto executa o gdb fazendo isso:{{{
Line 127: Line 127:
=== Advanced gdb commands ===
 * If the program you’re backtracing is multi-threaded, you might want to get a backtrace for all threads:{{{
=== Comandos avançados do gdb ===
 * Se o programa para o qual você quer obter o backtrace trabalha em multithread, convém obter um backtrace para todos as threads:{{{
Line 131: Line 131:
 * Another thing which is quite helpful to report is what variables were set locally at each point in the stack:{{{  * Outra coisa que é bastante útil relatar é quais variáveis foram definidas localmente em cada ponto da pilha:{{{
Line 134: Line 134:
 * You might want to report the output of the combination of the preceding options:{{{  * Convém relatar a saída da combinação das opções anteriores:{{{
Line 137: Line 137:
 * And if this is too much irrelevant output, you might want to keep only a few calls, such as the top 10:{{{  * E se essa é uma saída muito irrelevante, convém manter apenas algumas chamadas, como as 10 principais:{{{
Line 140: Line 140:
 * If you have a large backtrace, you can log gdb output to a file (the default is gdb.txt):{{{  * Se você está com um backtrace grande, pode registrar a saída gdb em um arquivo (o padrão é gdb.txt):{{{
Line 143: Line 143:
 * To check you have debugging symbols in your binary:{{{  * Para verificar se você possui símbolos de depuração no seu executável:{{{
Line 147: Line 147:
 # you should see something like this:  # Você deveria ver algo como isso:
Line 152: Line 152:
 # NB you should _not_ see
  Reading symbols from /usr/bin/hello...(no debugging symbols found)...done
}}}


=== Debugging X Errors ===

If
a GTK program has received an X error; i.e. you see a message of the form:
 # Você _não_ deveria ver
  Reading symbols from /usr/bin/hello...
  
(no debugging symbols found)...done
}}}


=== Depurando erros no X ===

Se um program
a GTK recebeu um erro X; ou seja, você vê uma mensagem na forma:
Line 165: Line 166:
then you can try running the program with `--sync`, and break on the `gdk_x_error` function in order to obtain a backtrace, thus: Então você pode tentar executar o programa com `--sync` e interromper a função `gdk_x_error` para obter um retorno, assim:
Line 172: Line 173:
=== Core dump ===

For a crashed program, a core dump file may be used to evaluate post-mortem snapshot of the program's state at the time of the crash. You can check resource limitation including the maximum size of core files created by typing "`ulimit`" on the shell prompt. You may set the core file size to unlimited using "`ulimit -c unlimited`" and/or with some other configuration files (`/etc/security/limits.conf`, `/usr/lib/sysctl.d/50-coredump.conf`, and systemd service files).

The location of core dump file is specified by `/proc/sys/kernel/core_pattern`. If the `systemd-coredump` package is installed under `systemd`, it may look like.
=== Despejo do núcleo ===

Para um programa que travou, um arquivo de despejo do núcleo pode ser usado para avaliar a situação post-mortem do estado do programa no momento da travamento. Você pode verificar a limitação de recursos, incluindo o tamanho máximo dos arquivos do núcleo criados, digitando "`ulimit`" no prompt do shell. Você pode definir o tamanho do arquivo do núcleo como ilimitado usando "`ulimit -c unlimited`" e/ou com outros arquivos de configuração (`/etc/security/limits.conf`, `/usr/lib/sysctl.d/50-coredump.conf` e arquivos de serviço do systemd).

A local do arquivo de despejo principal é especificado por `/proc/sys/kernel/core_pattern`. Se o pacote `systemd-coredump` estiver instalado no `systemd`, pode parecer com:
Line 182: Line 183:
Then the lz4-compressed core dump file is generated in `/var/lib/systemd/coredump` upon crash. You can get information on this compressed core file with: Em seguida, o arquivo de despejo do núcleo compactado pelo lz4 é gerado em `/var/lib/systemd/coredump` após um travamento. Você pode obter informações sobre esse arquivo de núcleo compactado com:
Line 188: Line 189:
You can use this compressed core file with `gdb` by: Você pode usar esse arquivo de núcleo compactado com `gdb` da seguinte maneira:
Line 193: Line 194:
See more:
 * `systemd-coredump`(1), and `coredumpctl`(1)
 * `gdb`(1) and `gcore`(1)
 * `core
`(5), `coredump.conf`(5), `sysctl`(8) and `sysctl.d`(5)
 * https://www.freedesktop.org/software/systemd/man/systemd-coredump.html
 * https://wiki.archlinux.org/index.php/Core_dump
 * core-dump-handler virtual package is provided by DebianPackage:corekeeper, DebianPackage:minicoredumper, DebianPackage:systemd-coredump

=== Other Helpful Links ===

 * [[http://wiki.debian.org/XStrikeForce/XserverDebugging|Debugging the Xorg server]]
 * [[http://wiki.ubuntu.com/Backtrace|Ubuntu Backtrace page]]
 * [[https://wiki.gnome.org/Projects/GnomeShell/Debugging|Debugging GNOME Shell]]
 * [[InterpretingKernelOutputAtProcessCrash|Interpreting kernel output at process crash]]

--AriPollak and LoicMinier
Veja mais:
 * `systemd-coredump`(1) e `coredumpctl`(1)
 * `gdb`(1) e `gcore`(1)
 * `core`(5)
, `coredump.conf`(5), `sysctl`(8) e `sysctl.d`(5)
 * https://www.freedesktop.org/software/systemd/man/systemd-coredump.html (em inglês)
 * [[https://wiki.archlinux.org/title/Core_dump_(Portugu%C3%AAs)|Despejo de núcleo (Arch wiki)]]
 * core-dump-handler é um pacote virtual fornecido por DebianPackage:corekeeper, DebianPackage:minicoredumper, DebianPackage:systemd-coredump

=== Outros links úteis ===

 * [[http://wiki.debian.org/XStrikeForce/XserverDebugging|Depurando o servidor Xorg]] (em inglês)
 * [[http://wiki.ubuntu.com/Backtrace|Página de backtrace do Ubuntu]] (em inglês)
 * [[https://wiki.gnome.org/Projects/GnomeShell/Debugging|Depurando o GNOME Shell]] (em inglês)
 * [[InterpretingKernelOutputAtProcessCrash|Interpretando a saída do kernel no travamento de um processo]] (em inglês)

--AriPollak e LoicMinier

----

Traduções: English - Português (Brasil) - Русский


Como obter um backtrace significativo

Esta página tentará explicar como obter um backtrace de depuração significativo de uma falha reproduzível no programa. Neste exemplo, instalaremos o pacote com símbolos de depuração para "hello" ou, se não estiver disponível, reconstrua e instale o pacote "hello" para manter as informações de depuração.

Para referência, um "#" no início de uma linha significa que o que vem a seguir é um comando que deve ser executado como root (ou sudo). Um "$" no início significa que o que vem a seguir é um comando que deve ser executado como seu(sua) usuário(a) normal. Um "(gdb)" no início significa que você deve digitar o restante da linha de comando no prompt do gdb (GNU Debugger).

# apt install gdb

Instalando os símbolos de depuração

Verifique se você tem o pacote AutomaticDebugPackages listado em seu SourcesList:

deb http://deb.debian.org/debian-debug/ $RELEASE-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ $RELEASE-proposed-updates-debug main

Então, dependendo da sua versão, pode se parecer com isso:

deb http://deb.debian.org/debian-debug/ buster-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ buster-proposed-updates-debug main

Outras possibilidades são:

deb http://deb.debian.org/debian-debug/ testing-debug main
deb http://deb.debian.org/debian-debug/ unstable-debug main
deb http://deb.debian.org/debian-debug/ experimental-debug main

Se você estiver usando o Debian buster ou posterior, instale debian-goodies e execute o script find-dbgsym-packages para descobrir quais pacotes do dbgsym instalar:

$ find-dbgsym-packages /usr/bin/hello
hello-dbgsym

Caso contrário, para ver se o pacote que você está tentando depurar inclui um pacote -dbgsym ou -dbg (por exemplo, para o pacote fonte hello, um pacote ello-dbgsym ou hello-dbg existe), procure-o no seu gerenciador de pacotes. Na linha de comando, você pode usar o seguinte comando:

$ apt-cache search hello dbg
p   hello-dbgsym            - Debug symbols for hello

Se esse também não tiver seu pacote de depuração, você pode tentar reconstruir o pacote, conforme explicado na próxima seção.

Se um pacote apropriado for encontrado, você poderá instalar o pacote de depuração apropriado e pular o processo de reconstrução nas instruções a seguir e seguir diretamente para a execução do gdb.

# apt install hello-dbgsym

Reconstruindo o pacote que você está depurando

Você pode pular esta seção se conseguir instalar os pacotes de símbolos de depuração necessários na seção anterior.

  • Instale os pacotes básicos de desenvolvimento e as dependências de compilação para o pacote que queremos reconstruir. Observe que você pode pular a parte de reconstrução e ir direto para o gdb, mas é improvável que você obtenha um backtrace útil (se a linha build-dep falhar, verifique se você possui linhas deb-src em apt sources).

# apt install build-essential fakeroot gdb
# apt build-dep hello
  • Faça o download e reconstrua nosso pacote da fonte, mantendo os símbolos de depuração:

$ DEB_BUILD_OPTIONS="nostrip noopt" apt -b source hello
  • Instale nossos pacotes recém-construídos. Pode haver vários pacotes .deb gerados, portanto, instale apenas os que você deseja. Neste exemplo, o .deb gerado foi chamado hello_2.1.1-4_amd64.deb:

# apt install ./hello_2.1.1-4_amd64.deb
  • Você pode garantir que os binários instalados no seu .deb tenham símbolos de depuração com o comando "file" ou com o próprio gdb (veja abaixo):

$ file /usr/bin/hello # a saída deve conter "not stripped"

Executando o gdb

Modo em lote

Para incluir um backtrace em um relatório de bug, você pode executar este comando e tentar reproduzir sua falha:

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'thread apply all bt full' --args hello

Interativamente

Use este método se precisar executar interativamente o gdb.

  • Execute seu programa como apresentado a seguir, substituindo "[--args]" com quaisquer argumentos com os quais você deseje executar programa:

     $ gdb hello
     ... gdb loads ...
     (gdb) set pagination 0
     (gdb) run [--args]
     ... hello loads...
  • Em seguida, tente reproduzir sua falha. Se você tiver sorte, ocorrerá uma falha e você voltará ao prompt do gdb.
  • Se você não tiver tanta sorte em fazer o programa travar, mas somente congelar, ainda poderá receber o prompt do gdb pressionando CTRL-C no terminal que está executando o gdb.
  • Neste ponto, você pode executar:

     (gdb) bt
  • Você obterá muita saída, que poderá copiar e colar em um e-mail de acompanhamento de relatório de bug ou em outra ferramenta de relatório de bug.
  • Quando você tiver terminado com o gdb, você pode simplesmente executar:

     (gdb) quit

Se o problema parece estar em uma biblioteca importante, como libc6, xlibs ou libgtk2.0-0, instale o pacote -dbg apropriado (por exemplo, libc6-dbg no caso da libc6) e execute o programa problemático novamente no gdb.

Frequentemente, você verá um backtrace em que uma ou mais das principais linhas estão em malloc() ou g_malloc(). Quando isso acontece, é provável que seu backtrace não seja muito útil. A maneira mais fácil de encontrar algumas informações úteis é definir a variável de ambiente MALLOC_CHECK_ como um valor de 2. Você pode fazer isso enquanto executa o gdb fazendo isso:

 $ MALLOC_CHECK_=2 gdb hello

Comandos avançados do gdb

  • Se o programa para o qual você quer obter o backtrace trabalha em multithread, convém obter um backtrace para todos as threads:

     (gdb) thread apply all bt
  • Outra coisa que é bastante útil relatar é quais variáveis foram definidas localmente em cada ponto da pilha:

     (gdb) bt full
  • Convém relatar a saída da combinação das opções anteriores:

     (gdb) thread apply all bt full
  • E se essa é uma saída muito irrelevante, convém manter apenas algumas chamadas, como as 10 principais:

     (gdb) thread apply all bt full 10
  • Se você está com um backtrace grande, pode registrar a saída gdb em um arquivo (o padrão é gdb.txt):

     (gdb) set logging on
  • Para verificar se você possui símbolos de depuração no seu executável:

     $ gdb
      (gdb) symbol-file /usr/bin/hello
    
     # Você deveria ver algo como isso:
      Reading symbols from /usr/bin/hello ... done
      Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
      (gdb)
    
     # Você _não_ deveria ver
      Reading symbols from /usr/bin/hello...
      (no debugging symbols found)...done

Depurando erros no X

Se um programa GTK recebeu um erro X; ou seja, você vê uma mensagem na forma:

The program 'preview1' received an X Window System error.

Então você pode tentar executar o programa com --sync e interromper a função gdk_x_error para obter um retorno, assim:

 (gdb) break gdk_x_error
 (gdb) run --sync

Despejo do núcleo

Para um programa que travou, um arquivo de despejo do núcleo pode ser usado para avaliar a situação post-mortem do estado do programa no momento da travamento. Você pode verificar a limitação de recursos, incluindo o tamanho máximo dos arquivos do núcleo criados, digitando "ulimit" no prompt do shell. Você pode definir o tamanho do arquivo do núcleo como ilimitado usando "ulimit -c unlimited" e/ou com outros arquivos de configuração (/etc/security/limits.conf, /usr/lib/sysctl.d/50-coredump.conf e arquivos de serviço do systemd).

A local do arquivo de despejo principal é especificado por /proc/sys/kernel/core_pattern. Se o pacote systemd-coredump estiver instalado no systemd, pode parecer com:

|/lib/systemd/systemd-coredump ...

Em seguida, o arquivo de despejo do núcleo compactado pelo lz4 é gerado em /var/lib/systemd/coredump após um travamento. Você pode obter informações sobre esse arquivo de núcleo compactado com:

 $ coredumpctl info -1

Você pode usar esse arquivo de núcleo compactado com gdb da seguinte maneira:

 $ coredumpctl gdb -1

Veja mais:

--AriPollak e ?LoicMinier


CategoryDebugging