web-dev-qa-db-ja.com

GDB：クラッシュしたプロセスのすべてのマップされたメモリ領域のリスト

GDBでデバッグしようとしているx86 Linuxマシン上のデッドプロセス（問題があればカーネル2.6.35-22）からフルヒープコアダンプを取得しました。

「このプロセスによって割り当てられたすべてのメモリアドレス領域のリストを表示する」という意味の、使用できるGDBコマンドはありますか？言い換えれば、このダンプで調べることができる有効なメモリアドレスのすべてを把握できますか？

私が尋ねる理由は、特定のバイナリ文字列をプロセスヒープ全体で検索する必要があり、findコマンドを使用するには、開始と終了が必要だからです。住所。 findはアクセスできないアドレスに遭遇するとすぐに停止するため、0x00から0xff ..への単純な検索は機能しません。

（gdb）find/w 0x10000000、0xff000000、0x12345678

警告：0x105ef883でターゲットメモリにアクセスできず、検索を停止します。

そのため、一度に1つずつ検索できるように、メモリ内のすべての読み取り可能なアドレス領域のリストを取得する必要があります。

（私がthatを行う必要がある理由は、at特定のアドレスを指すメモリ内のすべての構造体を見つける必要があるからです。）

show mem、show proc、info mem、info proc私が必要なことをするようです。

clinuxgdb
49
Crashworks

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.

info proc mappingsが必要な場合、ただし/procがない場合は機能しません（pos-mortemデバッグ中など）。

代わりにmaintenance info sectionsを試してください。

73
Employed Russian

プログラムとコアファイルがある場合は、次の手順を実行できます。

1）プログラムでコアファイルとともにgdbを実行する

 $gdb ./test core

2）情報ファイルを入力し、コアファイルに存在する異なるセグメントを確認します。

    (gdb)info files

サンプル出力：

    (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

私の場合、15個のセグメントがあります。各セグメントには、アドレスの始まりとアドレスの終わりがあります。データを検索するセグメントを選択します。たとえば、load11を選択してパターンを検索できます。 Load11の開始アドレスは0x08049000であり、0x804a000で終了します。

3）セグメント内のパターンを検索します。

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

実行可能ファイルがない場合は、コアファイルのすべてのセグメントのデータを印刷するプログラムを使用する必要があります。次に、アドレスで特定のデータを検索できます。そのようなプログラムは見つかりません。次のリンクでプログラムを使用して、コアまたは実行可能ファイルのすべてのセグメントのデータを印刷できます。

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

私はちょうど次を見ました：

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

ここ

メモリにアクセスできるかどうかに関係なく検索できる場合があります。

5
tothphu

info filesを使用して、プロセスバイナリにロードされたすべてのバイナリのすべてのセクションを一覧表示することもできます。

4
abhi
(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

これは上記のphihagによるコメントからのもので、別の答えに値します。これは機能しますが、info procは、gcc-arm-none-eabi Ubuntuパッケージのarm-none-eabi-gdb v7.4.1.20130913-cvsにはありません。

4
alexei

maintenance info sectionsの問題は、コマンドがバイナリのセクションヘッダーから情報を抽出しようとすることです。バイナリがトリップされた場合（たとえば、sstrip）またはローダーがロード後にメモリ許可を変更する可能性がある場合（たとえば、RELROの場合）誤った情報を提供します。

0
Ta Thanh Dinh