Translation

(glldb) <userinput>process attach -p <replaceable>pid</replaceable></userinput>
(itstool) path: sect3/screen
(lldb) <userinput>process attach -p <replaceable>pid</replaceable></userinput>
66/780
Context English Portuguese (Brazil) State
Oh dear! Looking at the code, we forgot to initialize <symbol>i</symbol>. We meant to put Oh querida! Olhando o código, esquecemos de inicializar <symbol> Eu </symbol> . Nós pretendíamos colocar
<lineannotation>…</lineannotation>
main() {
int i;

i = 5;
printf("This is my program\n");
<lineannotation>…</lineannotation>
<lineannotation>…</lineannotation>
main() {
int i;

i = 5;
printf("This is my program\n");
<lineannotation>…</lineannotation>
but we left the <literal>i=5;</literal> line out. As we did not initialize <symbol>i</symbol>, it had whatever number happened to be in that area of memory when the program ran, which in this case happened to be <literal>-5360</literal>. mas deixamos o <literal> i = 5; </literal> line out. Como nós não inicializamos <symbol> Eu </symbol> , tinha qualquer número que estivesse naquela área de memória quando o programa rodava, o que neste caso aconteceu <literal> 4231 </literal>
The <command>lldb</command> command displays the stack frame every time we go into or out of a function, even if we are using <userinput>up</userinput> and <userinput>down</userinput> to move around the call stack. This shows the name of the function and the values of its arguments, which helps us keep track of where we are and what is going on. (The stack is a storage area where the program stores information about the arguments passed to functions and where to go when it returns from a function call.) <command> gdb </command> exibe o quadro da pilha toda vez que entramos ou saímos de uma função, mesmo se estivermos usando <command> acima </command> e <command> baixa </command> para percorrer a pilha de chamadas. Isso mostra o nome da função e os valores de seus argumentos, o que nos ajuda a saber onde estamos e o que está acontecendo. (A pilha é uma área de armazenamento onde o programa armazena informações sobre os argumentos passados ​​às funções e para onde ir quando retorna de uma chamada de função).
Examining a Core File with lldb Examinando um arquivo principal
A core file is basically a file which contains the complete state of the process when it crashed. In <quote>the good old days</quote>, programmers had to print out hex listings of core files and sweat over machine code manuals, but now life is a bit easier. Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called <filename><replaceable>progname</replaceable>.core</filename> instead of just <filename>core</filename>, to make it clearer which program a core file belongs to. Um arquivo principal é basicamente um arquivo que contém o estado completo do processo quando ele caiu. <quote> os bons velhos tempos </quote> os programadores tiveram que imprimir listas hexadecimais de arquivos principais e suar os manuais de códigos de máquina, mas agora a vida é um pouco mais fácil. Aliás, sob o FreeBSD e outros sistemas 4.4BSD, um arquivo principal é chamado <filename><replaceable> progname </replaceable> .testemunho </filename> em vez de apenas <filename> testemunho </filename> , para tornar mais claro qual programa um arquivo principal pertence.
To examine a core file, specify the name of the core file in addition to the program itself. Instead of starting up <command>lldb</command> in the usual way, type <userinput>lldb -c <replaceable>progname</replaceable>.core -- <replaceable>progname</replaceable></userinput>
The debugger will display something like this: O script pode ser algo como isto:
<prompt>%</prompt> <userinput>lldb -c <filename><replaceable>progname</replaceable>.core</filename> -- <filename><replaceable>progname</replaceable></filename></userinput>
(lldb) target create "<filename><replaceable>progname</replaceable></filename>" --core "<filename><replaceable>progname</replaceable></filename>.core"
Core file '/home/pauamma/tmp/<filename><replaceable>progname</replaceable>.core</filename>' (x86_64) was loaded.
(lldb)
In this case, the program was called <filename><replaceable>progname</replaceable></filename>, so the core file is called <filename><replaceable>progname</replaceable>.core</filename>. The debugger does not display why the program crashed or where. For this, use <userinput>thread backtrace all</userinput>. This will also show how the function where the program dumped core was called.
(lldb) <userinput>thread backtrace all</userinput>
* thread #1, name = '<filename><replaceable>progname</replaceable></filename>', stop reason = signal SIGSEGV
* frame #0: 0x0000000000201347 <filename><replaceable>progname</replaceable></filename>`bazz(anint=5) at temp2.c:17:10
frame #1: 0x0000000000201312 <filename><replaceable>progname</replaceable></filename>`main at temp2.c:10:2
frame #2: 0x000000000020110f <filename><replaceable>progname</replaceable></filename>`_start(ap=&lt;unavailable&gt;, cleanup=&lt;unavailable&gt;) at crt1.c:76:7
(lldb)
<literal>SIGSEGV</literal> indicates that the program tried to access memory (run code or read/write data usually) at a location that does not belong to it, but does not give any specifics. For that, look at the source code at line 10 of file temp2.c, in <function>bazz()</function>. The backtrace also says that in this case, <function>bazz()</function> was called from <function>main()</function>.
Attaching to a Running Program with lldb Anexando a um programa em execução
One of the neatest features about <command>lldb</command> is that it can attach to a program that is already running. Of course, that requires sufficient permissions to do so. A common problem is stepping through a program that forks and wanting to trace the child, but the debugger will only trace the parent. Uma das características mais interessantes sobre <command> gdb </command> é que ele pode se conectar a um programa que já está em execução. Claro, isso pressupõe que você tenha permissões suficientes para isso. Um problema comum é quando você está percorrendo um programa que se bifurca e deseja rastrear o filho, mas o depurador só permitirá rastrear o pai.
To do that, start up another <command>lldb</command>, use <command>ps</command> to find the process ID for the child, and do O que você faz é iniciar outra <command> gdb </command> , usar <command> ps </command> para encontrar o ID do processo para o filho e fazer
(lldb) <userinput>process attach -p <replaceable>pid</replaceable></userinput> (gdb) <userinput>attach <replaceable>pid</replaceable></userinput>
in <command>lldb</command>, and then debug as usual. dentro <command> gdb </command> e, em seguida, depurar como de costume
For that to work well, the code that calls <function>fork</function> to create the child needs to do something like the following (courtesy of the <command>gdb</command> info pages):
<lineannotation>…</lineannotation>
if ((pid = fork()) &lt; 0) /* _Always_ check this */
error();
else if (pid == 0) { /* child */
int PauseMode = 1;

while (PauseMode)
sleep(10); /* Wait until someone attaches to us */
<lineannotation>…</lineannotation>
} else { /* parent */
<lineannotation>…</lineannotation>
<lineannotation>…</lineannotation>
if ((pid = fork()) &lt; 0) /* _Always_ check this */
error();
else if (pid == 0) { /* child */
int PauseMode = 1;

while (PauseMode)
sleep(10); /* Wait until someone attaches to us */
<lineannotation>…</lineannotation>
} else { /* parent */
<lineannotation>…</lineannotation>
Now all that is needed is to attach to the child, set <symbol>PauseMode</symbol> to <literal>0</literal> with <userinput>expr PauseMode = 0</userinput> and wait for the <function>sleep()</function> call to return. Agora tudo que você tem a fazer é anexar à criança, definir <symbol> PauseMode </symbol> para <literal> 0 </literal> e aguarde o <function> dormir() </function> ligue para voltar!
Using gdb
Starting gdb
Start up gdb by typing
<prompt>%</prompt> <userinput>gdb <replaceable>progname</replaceable></userinput> <prompt>%</prompt> <userinput>gdb <replaceable>progname</replaceable></userinput>
although many people prefer to run it inside <application>Emacs</application>. To do this, type: embora muitas pessoas prefiram correr dentro <application> Emacs </application> . Você pode fazer isso por:
<userinput>M-x gdb RET <replaceable>progname</replaceable> RET</userinput> <userinput>M-x gdb RET <replaceable>progname</replaceable> RET</userinput>
Finally, for those finding its text-based command-prompt style off-putting, there is a graphical front-end for it (<package>devel/xxgdb</package>) in the Ports Collection. Finalmente, se você achar que o estilo de prompt de comando baseado em texto é desagradável, há um front-end gráfico para ele ( <package> devel / xxgdb </package> ) na coleção de Portos
Running a Program with gdb Executando um programa no depurador
Compile the program with <option>-g</option> to get the most out of using <command>gdb</command>. It will work without, but will only display the name of the function currently running, instead of the source code. A line like: Você precisará ter compilado o programa com o <option value=-g> -g </option> opção para tirar o máximo proveito do uso <command> gdb </command> . Ele funcionará sem, mas você verá apenas o nome da função em que está, em vez do código-fonte. Se você vir uma linha como:
… (no debugging symbols found) … … (no debugging symbols found) …
when <command>gdb</command> starts up means that the program was not compiled with <option>-g</option>. quando <command> gdb </command> inicia, você saberá que o programa não foi compilado com o <option value=-g> -g </option> opção.

Loading…

User avatar None

Source string changed

FreeBSD Doc / books_developers-handbookPortuguese (Brazil)

(glldb) <userinput>process attach -p <replaceable>pid</replaceable></userinput>
4 months ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/screen
Flags
no-wrap
Source string location
book.translate.xml:2014
String age
4 months ago
Source string age
4 months ago
Translation file
books/pt_BR/developers-handbook.po, string 360