22

pmap -xコマンドを使用して、Linuxx86-64上のプロセスのメモリマップを表示しようとしました。pmapの出力を見て混乱しました。特にダイナミックライブラリをマッピングするためのエントリの場合。それらには複数のエントリがあります（実際には、ほとんどすべてのエントリで4つで、一部には3つのエントリがあります）。以下は例です

  Address           Kbytes   RSS   Dirty Mode   Mapping

00000036ca200000      88      64       0 r-x--  libpthread-2.5.so
00000036ca216000    2044       0       0 -----  libpthread-2.5.so
00000036ca415000       4       4       4 r----  libpthread-2.5.so
00000036ca416000       4       4       4 rw---  libpthread-2.5.so

各ライブラリの2行目は、ページ権限がない場合でも常に2MBのサイズになります。すべてのライブラリで、RSSは常にゼロのようです。最後の2行も同じサイズ（ベースページサイズ）と同じ権限（少数のライブラリにはrwマッピングがありません）があります。

誰かがこれについていくつかの説明がありますか？おそらく、読み取り専用保護を使用したマッピングは、ライブラリのメタデータを読み取るためにローダーによって行われ、実行可能権限を持つ部分は実際にはライブラリのコードであると感じています。私は間違っているかもしれません。

しかし、私にはその真ん中の列についての手がかりがありません。許可も使用法もありませんか？誰かがここに知恵の言葉を持っていますか？

また、匿名メモリ上にあり、モードビットが設定されていないことが報告されているページもいくつか見ました。これらは何を表していますか？

4

2 に答える 2

8

これらの保護された「----」ページは、ライブラリのコードセグメントとデータセグメントの間でポインタがインデックスを作成するのを防ぐためのガードページです。それらはプロセスの仮想空間にのみ存在し、ポインターがセグメントの終わりを通過した場合に障害を引き起こすために存在します。

これらが共有ライブラリファイルにアドレス指定されていない場合、割り当てをmallocやスタックの拡張などに拡張するためのバッファーとして機能していたと言えます。たとえば、glibcは、スレッドローカル割り当てアリーナのためにカーネルにアドレス空間の大きなチャンクを要求し、malloc割り当てのためにそれらをゆっくりと消費します。私が見ているJVMからのはるかに大きなpmapには、これらが数十個あり、それぞれがRWページに続くか、2つの大きなRW割り当ての間のスペースを埋め、RWページが拡張するにつれてそれらの間の境界がシフトします。このようなX86_64ガードページでは、CPUのメモリ保護システムを使用して、不正なポインタの逆参照をキャッチできます。

于 2015-10-23T12:01:47.523 に答える
4

まず、1つの同じプロセスが複数のメモリ使用量インスタンスを使用できる場合があります。これがあなたが知りたいことなのかわかりません。Linuxでブラウザを使用し、タブを1つだけ開いて、topコマンドを使用すると、メモリ使用量リストに4つ以上の使用量が表示され、10MBを超えるメモリをカバーしていることがわかりました。同じプロセスで実行されるスレッドの数が多いので、問題ないと思います。

このリンクは、使用例自体で観察すると、-xコマンドのマッピングがより多くの使用回数を示しているため、役立つ場合があります。

http://www.cyberciti.biz/tips/howto-find-memory-used-by-program.html

于 2012-03-23T05:00:39.750 に答える