GDB: Auflistung aller abgebildeten Speicherbereiche für einen abgestürzten Prozess

Lesezeit: 5 Minuten

Ich habe einen Full-Heap-Core-Dump von einem toten Prozess auf einer x86-Linux-Maschine (Kernel 2.6.35-22, falls es darauf ankommt), den ich versuche, in GDB zu debuggen.

Gibt es einen GDB-Befehl, den ich verwenden kann, der bedeutet: “Zeige mir eine Liste aller Speicheradressbereiche, die von diesem Prozess zugewiesen wurden?” Mit anderen Worten, kann ich herausfinden, was alle möglichen gültigen Speicheradressen sind, die ich in diesem Dump untersuchen kann?

Der Grund, warum ich frage, ist, dass ich über die suchen muss gesamten Prozesshaufen für eine bestimmte binäre Zeichenfolge und um die zu verwenden find Befehl, brauche ich eine Start- und Endadresse. Einfach von 0x00 bis 0xff zu suchen, funktioniert nicht, weil find hält an, sobald es auf eine Adresse trifft, auf die es nicht zugreifen kann:

(gdb) finde /w 0x10000000, 0xff000000, 0x12345678

Warnung: Zugriff auf Zielspeicher bei 0x105ef883 nicht möglich, Suche wird angehalten.

Ich brauche also eine Liste aller lesbaren Adressbereiche im Speicher, damit ich sie einzeln durchsuchen kann.

(Der Grund, warum ich tun muss das ist, dass ich alle Strukturen im Speicher an diesem Punkt finden muss bei eine bestimmte Adresse.)

Keiner von show mem, show proc, info mem, info proc scheinen zu tun, was ich brauche.

Benutzeravatar des beschäftigten Russen
Angestellter Russe

In GDB 7.2:

(gdb) help info proc
Show /proc process information about any running process.
Specify any process id, or use the program being debugged by default.
Specify any of the following keywords for detailed info:
  mappings -- list of mapped memory regions.
  stat     -- list a bunch of random process info.
  status   -- list a different bunch of random process info.
  all      -- list all available /proc info.

Sie wollen info proc mappingsaußer es funktioniert nicht, wenn es keine gibt /proc (z. B. beim Pos-Mortem-Debugging).

Versuchen maintenance info sections stattdessen.

  • Das ist eines der ersten Dinge, die ich versucht habe, aber es scheint leer zu sein (es gibt nichts unter der Kopfzeile). Vielleicht funktioniert es einfach nicht für Core Dumps?

    – Absturz

    17. April 2011 um 4:52 Uhr

  • maintenance info sections scheint viel tragbarer zu sein und sollte hier die primäre Antwort sein.

    – Phihag

    23. Februar 2012 um 11:56 Uhr

  • Wenn Sie einen Live-Prozess debuggen, können Sie diese Informationen auch abrufen/überprüfen cat /proc/<pid>/maps

    – Nathan Kidd

    25. November 2013 um 16:42 Uhr

  • @phihag Das wurde in eine Antwort umgewandelt. Jetzt überflüssiger Kommentar.

    – Benutzer202729

    24. Juni 2018 um 5:38 Uhr

  • info proc mappings hat bei mir funktioniert. Die PWNDGB-Version ist vmmaps.

    – lennihein

    8. Februar 2021 um 22:22 Uhr

Wenn Sie das Programm und die Kerndatei haben, können Sie die folgenden Schritte ausführen.

1) Führen Sie die gdb zusammen mit der Kerndatei im Programm aus

 $gdb ./test core

2) Geben Sie Info-Dateien ein und sehen Sie, welche verschiedenen Segmente in der Kerndatei vorhanden sind.

    (gdb)info files

Eine Beispielausgabe:

    (gdb)info files 

    Symbols from "/home/emntech/debugging/test".
    Local core dump file:
`/home/emntech/debugging/core', file type elf32-i386.
  0x0055f000 - 0x0055f000 is load1
  0x0057b000 - 0x0057c000 is load2
  0x0057c000 - 0x0057d000 is load3
  0x00746000 - 0x00747000 is load4
  0x00c86000 - 0x00c86000 is load5
  0x00de0000 - 0x00de0000 is load6
  0x00de1000 - 0x00de3000 is load7
  0x00de3000 - 0x00de4000 is load8
  0x00de4000 - 0x00de7000 is load9
  0x08048000 - 0x08048000 is load10
  0x08049000 - 0x0804a000 is load11
  0x0804a000 - 0x0804b000 is load12
  0xb77b9000 - 0xb77ba000 is load13
  0xb77cc000 - 0xb77ce000 is load14
  0xbf91d000 - 0xbf93f000 is load15

In meinem Fall habe ich 15 Segmente. Jedes Segment hat einen Anfang der Adresse und ein Ende der Adresse. Wählen Sie ein beliebiges Segment aus, nach dem Daten gesucht werden sollen. Wählen wir zum Beispiel load11 und suchen nach einem Muster. Load11 hat die Startadresse 0x08049000 und endet bei 0x804a000.

3) Suche nach einem Muster im Segment.

(gdb) find /w 0x08049000 0x0804a000 0x8048034
 0x804903c
 0x8049040
 2 patterns found

Wenn Sie keine ausführbare Datei haben, müssen Sie ein Programm verwenden, das Daten aller Segmente einer Kerndatei druckt. Dann können Sie unter einer Adresse nach bestimmten Daten suchen. Ich finde kein Programm als solches, Sie können das Programm unter folgendem Link verwenden, das Daten aller Segmente eines Kerns oder einer ausführbaren Datei druckt.

 http://emntech.com/programs/printseg.c

  • Gibt es eine Möglichkeit, gdb dazu zu bringen, alle diese Segmente zu durchsuchen, ohne sie manuell anzugeben?

    – entwickelte Mikrobe

    17. August 2014 um 14:31 Uhr

  • Dass printseg.c nicht mehr auf dieser Website ist. Es ist auch nicht auf archive.org verfügbar

    – Folkert van Heusden

    1. Dezember 2020 um 15:43 Uhr


(gdb) maintenance info sections 
Exec file:
    `/path/to/app.out', file type elf32-littlearm.
    0x0000->0x0360 at 0x00008000: .intvecs ALLOC LOAD READONLY DATA HAS_CONTENTS

Dies stammt aus dem obigen Kommentar von phihag und verdient eine separate Antwort. Das funktioniert aber info proc nicht auf arm-none-eabi-gdb v7.4.1.20130913-cvs aus dem Ubuntu-Paket gcc-arm-none-eabi.

  • Dadurch werden Mappings angezeigt, die aus der ausführbaren Datei oder den Bibliotheken stammen, aber keine Dinge wie der Stack eines User-Space-Prozesses. Aber ja, in einem Core-Dump ist das vielleicht das Beste, was Sie tun können, wenn der Core-Dump keine Informationen aufzeichnet /proc/<pid>/maps.

    – Peter Cordes

    2. September um 14:51 Uhr

Sie können auch verwenden info files um alle Abschnitte aller Binärdateien aufzulisten, die in Process Binary geladen wurden.

Ich habe gerade folgendes gesehen:

set mem inaccessible-by-default [on|off]

hier

Es könnte Ihnen ermöglichen, ohne Rücksicht darauf zu suchen, ob der Speicher zugänglich ist.

  • Hm, bei mir auf GDB 10.1 funktioniert das leider nicht.

    – Gizmo

    23. April 2021 um 10:46 Uhr

  • @Gizmo War das auf x86? Der Link beschreibt dies immer noch, wie es funktionieren sollte.

    – tothphu

    28. April 2021 um 4:30 Uhr

  • Ja, Debuggen eines x86-Ziels.

    – Gizmo

    28. April 2021 um 7:59 Uhr

Das Problem mit maintenance info sections ist, dass der Befehl versucht, Informationen aus dem Abschnittsheader der Binärdatei zu extrahieren. Es funktioniert nicht, wenn die Binärdatei ausgelöst wird (z. B. durch sstrip) oder es gibt falsche Informationen, wenn der Lader die Speicherberechtigung nach dem Laden ändern darf (z. B. im Fall von RELRO).

  • Hm, bei mir auf GDB 10.1 funktioniert das leider nicht.

    – Gizmo

    23. April 2021 um 10:46 Uhr

  • @Gizmo War das auf x86? Der Link beschreibt dies immer noch, wie es funktionieren sollte.

    – tothphu

    28. April 2021 um 4:30 Uhr

  • Ja, Debuggen eines x86-Ziels.

    – Gizmo

    28. April 2021 um 7:59 Uhr

1417790cookie-checkGDB: Auflistung aller abgebildeten Speicherbereiche für einen abgestürzten Prozess

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy