|
Size: 8905
Comment: Created page. Localization in progress.
|
Size: 9327
Comment: Partial translation
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| == 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 se segue é um comando que deve ser executado como root (ou sudo). Um "$" no início significa que o que segue é um comando que deve ser executado como seu usuário 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 16: |
| === Installing the debugging symbols === Make sure you have the AutomaticDebugPackages archive listed in your SourcesList: |
=== Instalando os símbolos de depuração === Verifique se você tem o pacote AutomaticDebugPackages listado em seu [[pt_BR/SourcesList|SourcesList]]: |
| Line 27: | Line 26: |
| 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 33: |
| Other possibilities are: | Outras possibilidades são: |
| Line 41: | Line 40: |
| 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: | 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: |
| Line 48: | Line 47: |
| 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 53: |
| 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 61: |
| === 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 71: |
| * 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 77: |
| * 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 83: |
| * 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 99: |
| ==== 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. * Agora, execute seu programa conforme a seguir, substituindo "[--args]" com quaisquer argumentos com os quais você deseje executar programa:{{{ |
| Line 111: | Line 110: |
| * 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 o programa travar, mas sim congelar, ainda poderá receber o prompt do gdb pressionando CTRL-C no terminal executando o gdb. * Neste ponto, você pode executar:{{{ |
| Line 116: | Line 115: |
| * 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 120: |
| 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 126: |
| === Advanced gdb commands === | === Comandos avançados do gdb === |
| Line 157: | Line 156: |
| === Debugging X Errors === | === Depurando erros no X === |
| Line 172: | Line 171: |
| === Core dump === | === Despejo do núcleo === |
| Line 201: | Line 200: |
| === Other Helpful Links === | === Outros links úteis === |
Translation(s): English - Português (Brasil) - Русский
Contents
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 se segue é um comando que deve ser executado como root (ou sudo). Um "$" no início significa que o que segue é um comando que deve ser executado como seu usuário 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.
Agora, execute seu programa conforme 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 o programa travar, mas sim congelar, ainda poderá receber o prompt do gdb pressionando CTRL-C no terminal 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
If the program you’re backtracing is multi-threaded, you might want to get a backtrace for all threads:
(gdb) thread apply all bt
Another thing which is quite helpful to report is what variables were set locally at each point in the stack:
(gdb) bt full
You might want to report the output of the combination of the preceding options:
(gdb) thread apply all bt full
And if this is too much irrelevant output, you might want to keep only a few calls, such as the top 10:
(gdb) thread apply all bt full 10
If you have a large backtrace, you can log gdb output to a file (the default is gdb.txt):
(gdb) set logging on
To check you have debugging symbols in your binary:
$ gdb (gdb) symbol-file /usr/bin/hello # you should see something like this: Reading symbols from /usr/bin/hello ... done Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) # NB you should _not_ see Reading symbols from /usr/bin/hello...(no debugging symbols found)...done
Depurando erros no X
If a GTK program has received an X error; i.e. you see a message of the form:
The program 'preview1' received an X Window System error.
then you can try running the program with --sync, and break on the gdk_x_error function in order to obtain a backtrace, thus:
(gdb) break gdk_x_error (gdb) run --sync
Despejo do núcleo
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.
|/lib/systemd/systemd-coredump ...
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:
$ coredumpctl info -1
You can use this compressed core file with gdb by:
$ coredumpctl gdb -1
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
core-dump-handler virtual package is provided by corekeeper, minicoredumper, systemd-coredump