GDB-Strice zeigt an, dass er an einer ungültigen Adresse ptrace ist

Question

Ich habe bei der Ausführung des NI-Befehls während des GDB-Debugging-NI-Befehls aufgetreten:

Warnung:
Haltepunkt 0 nicht einfügen 0.
Fehler beim Zugriff der Speicheradresse 0x3AC706A: Eingabe- / Ausgangsfehler.
Kummer 0xf6fa4771 in SiglongJMP () von /lib/libc.so.6

Um zu untersuchen, welches Problem GDB trifft, der sich mit i Strac-GDB trifft und eine solche Ausgabe abhebt:

rt_sigprocmask (sig_block, null, [rt_1], 8)= 0
Ptrace (ptrace_peektext, 651, 0xcc4fdf60, [0x1cc4fe470])= 0
ptrace (ptrace_peektext, 651, 0xcc4fe480, [0x3ac706a4506fa1d])= 0
RT_SIGPROCMASK (SIG_BLOCK, NULL, [RT_1], 8)= 0
...
...
RT_SIGPROCMASK (SIG_BLOCK, NULL, [RT_1], 8)= 0
RT_SIGPROCMASK (SIG_BLOCK, NULL, [RT_1], 8)= 0
Ptrace (Ptrace_Getregs, 27781, 0, 0x7FFF8990E8B0)= 0
ptrace (ptrace_peektext, 27781, 0x3AC7068, [0x28b])= -1 EIO (Eingabe- / Ausgangsfehler)
Ptrace (Ptrace_PeekText, 27781, 0x3AC7068, [0x28b])= -1 EIO (Eingabe- / Ausgangsfehler)

es impliziert, dass GDB erster Ptrace an der Speicheradresse 0xcc4fE480 und erhält den Wert 0x3AC706A4506FA1D (eigentlich ein 8-Byte-Wert 0x03AC706A4506FA1D ). Später erhält es eine ausgerichtete Adresse 0x3AC7068 von den ersten 4 Bytes dieses Werts, dh eine ungültige Adresse und verursacht, dass GDB nicht ptet.

Inhalt von / proc / [pid] / maps:

cbce2000-cc353000 R-XP 00000000 08:03 295479 xxx.SO
CC353000-CC3F0000 R - P 00670000 08:03 295479 xxx.SO
CC3F0000-CC3F6000 RW-P 0070D000 08:03 295479 XXX.SO
CC3F6000-CC3FE000 RW-P CC3F6000 00:00 0
CC3FE000-CC3FF000 --- P CC3FE000 00:00 0
CC3FF000-CC4FF000 RWXP CC3FF000 00:00 0
CC4FF000-CC500000 --- P CC4FF000 00:00 0
Kummer CC500000-CC600000 RWXP CC500000 00:00 0
CC62D000-CC673000 R-XP 00000000 08:03 295545 yyy.so
cc673000-cc674000 --- p 00046000 08:03 295545 yyy.so
CC674000-CC675000 R - P 00046000 08:03 295545 yyy.so
CC675000-CC676000 RW-P 00047000 08:03 295545 yyy.so

Es zeigt, dass die Adresse 0xcc4fE480 aus dem Abschnitt mit fettiger Schrift oben aus dem Abschnitt ist. Dieser Abschnitt bezieht sich nicht auf eine beliebige .so- oder bin-Datei.
Kummer Diese Frage steht tatsächlich mit einer anderen Frage http://stackoverflow.com/questions/9564417/gdb-cant-insert-internal-breakpoint , die noch nicht gelöst wurde. Ich habe diese Probleme während der Untersuchung der vorherigen Ausgabe gefunden.
Kummer Ich habe hier 3 Fragen:
1. Schauen Sie sich einen Blick auf die Strafe-Ausgabe für Ptrace hier:
ptrace (ptrace_peektext, 651, 0xcc4fe480, [0x3ac706a4506fa1d])= 0
Warum ist der letzte Parameter, der von eckigen Klammern kommentiert wird? Bedeutet das, dass es den Rückgabewert darstellt? Manuelle Seite sagt, dass ptrace das Wort lesen soll für ptrace_peektext zurücksenden, aber es sieht aus, dass der Straßendruck nicht folgt, so dass ich vermute, dass er den Rückgabewert im letzten Parameter anzeigt.
2. Es gibt einen Abschnitt (der mit fett gedruckt) zwischen zwei .so, aber nicht mit keiner Inode verbunden ist. Was ist derartige Abschnitt?
3. GDB liest ein Wort aus diesem Abschnitt und verwendet dieses Wort als Adresse, aber eigentlich ist das eine ungültige Adresse. Was sind die möglichen Ursachen für einen solchen Fehler?

danke!

Answer 1

1. Take a look at strace output for ptrace here: ptrace(PTRACE_PEEKTEXT, 651, 0xcc4fe480, [0x3ac706a4506fa1d]) = 0 Why is the last parameter annotated by square brackets? Does it mean it represent the return value?

Correct.

1. There's a section (who with bold font) between two .so but not associated with any inode. What does such section represent?

It is a region of memory that has been mmaped with MAP_ANONYMOUNS flag (i.e. it doesn't correspond to any file on disk).

Since the size of that region is exactly 1MB, and since it is surrounded by private regions mapped with PROT_NONE, it is a safe bet that this region represents some thread stack, surrounded by stack guard zones.

1. Gdb reads one word from that section and uses that word as an address, but actually that's an invalid address. What are the possible causes of such error?

For some reason GDB believes that there should be code at address 0x3ac7068, and wants to place an internal breakpoint there. GDB uses internal breakpoints to keep track of loaded shared libraries (among other things).

Output from maintenance info break should reveal what code GDB believes is residing at the "bad" address.

Answer 2

My guess is that your code is overflowing and writing over a valid address, and gdb is accessing that area of memory expecting an address but getting junk data. What is the section of code you're trying to debug? It might help us.