Linux 理解 pmap 输出

understanding pmap output

提问by Arka

I was trying to see memory map of a process on Linux x86-64 using pmap -xcommand. I got confused looking at the output of the pmap. Particularly for the entries for mapping dynamic libraries. There are multiple entries for them (actually 4 for all most all of them, with some having 3 entries). Following is an example

我试图使用pmap -x命令查看 Linux x86-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

The second row for each of the library always has size of 2MB while it has no page permission. Across all libraries it seems its RSS is ALWAYS zero. Last two rows also have same size (which is base page size) and same permissions (a handful libraries does not have rw mapping).

每个库的第二行总是有 2MB 的大小，而它没有页面权限。在所有图书馆中，它的 RSS 似乎始终为零。最后两行也具有相同的大小（即基页大小）和相同的权限（少数库没有 rw 映射）。

Does anybody has some explanation for this? I am kind of having a sense that possibly the mapping with the read-only protection is done by the loader to read the metadata of the library while the portion with the executable permission actually the code for the library. I may be wrong though.

有人对此有一些解释吗？我有一种感觉，具有只读保护的映射可能由加载程序完成以读取库的元数据，而具有可执行权限的部分实际上是库的代码。不过我可能错了。

But I have no clue about that middle row. No permission and no usages? Anyone has some words of wisdom here?

但我不知道中间那一行。没有权限，没有使用？有人在这里有一些智慧的话吗？

I also saw a few pages reported to be on the anonymous memory and not have any mode bit set. What do these represent?

我还看到有几页报告在匿名内存上，并且没有设置任何模式位。这些代表什么？

采纳答案by Xander

First of all , there can be this case that one same process can use more than one memory usage instance. I don't know if this is what you want to know. I have seen that , while using a browser in Linux, with just one tab open, and using the top command, it shows like more than 4 usage in the memory usage list, covering more than 10mb of memory. I think its ok because of the more number of threads running by the same process.

首先，可能存在这样一种情况，即同一个进程可以使用多个内存使用实例。不知道这是不是你想知道的。我已经看到，在 Linux 中使用浏览器时，只打开一个选项卡，并使用 top 命令，它在内存使用列表中显示超过 4 个使用，覆盖超过 10mb 的内存。我认为没问题，因为同一进程运行的线程数更多。

This link may be useful, since, in the usage example itself, if you observe, the mapping of the -x command show more number of usage.

此链接可能很有用，因为在使用示例本身中，如果您观察到 -x 命令的映射会显示更多的使用次数。

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

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

回答by user5479960

These protected "----" pages are guard pages to prevent pointers from indexing between the code and data segments of the library. They only exist in the virtual space of the process and exist to cause a fault if a pointer walks past the end of the segment.

这些受保护的“----”页是保护页，以防止指针在库的代码段和数据段之间建立索引。它们只存在于进程的虚拟空间中，如果指针越过段的末尾，它们的存在会导致错误。

If these weren't addressed into a shared library file I would say they were serving as a buffer for expanding allocations into e.g. malloc or stack growth. For example glibc requests large chunks of address space from the kernel for thread-local allocation arenas then consumes them slowly for malloc'd allocations. In a much larger pmap from a JVM I'm looking at there are a few dozen of these, each following a RW page or filling in the space between two large RW allocations and the boundaries between them shift as the RW pages expand. On X86_64 guard pages like this can use the CPU's memory protection system to catch bad pointer dereferences.

如果这些没有被寻址到共享库文件中，我会说它们用作将分配扩展到例如 malloc 或堆栈增长的缓冲区。例如，glibc 从内核请求大块地址空间用于线程本地分配领域，然后缓慢消耗它们用于 malloc 分配。在来自 JVM 的更大的 pmap 中，我正在查看其中有几十个，每个都跟随一个 RW 页面或填充两个大型 RW 分配之间的空间，并且它们之间的边界随着 RW 页面的扩展而移动。在像这样的 X86_64 保护页上，可以使用 CPU 的内存保护系统来捕获错误的指针取消引用。