How to Decode /Proc/Pid/Pagemap Entries in Linux

How to decode /proc/pid/pagemap entries in Linux?

Try this
http://www.eqware.net/Articles/CapturingProcessMemoryUsageUnderLinux/
It can parse the pagemap for you, for example, if the virtual address
you are interested is in the heap which is 0x055468 :
= 0004c000-0005a000 rw-p 00000000 00:00 0 [heap]
: 86000000000FD6D6
: 0600000000000000

: 0600000000000000

: 86000000000FE921

: 86000000000FE922

: 0600000000000000

: 86000000000FD5AD

: 86000000000FD6D4

: 86000000000FD5F8

: 86000000000FD5FA =>9th

Suppose the page size as 4KB, and
(0x055468 - 0x4c000) mod 4K = 9,
So the page frame number of your page is the 9th page frames
==> : 86000000000FD5FA
So the physical pfn is 0xFD5FA000 (take the last 55 bits and times page size)
plus the offset: ( 0x055468 - 0x4c000 - 9*4K) = 0x468
==> the physical addr is 0xFD5FA000 + 0x468 = 0xFD5FA468

Using /proc/[pid]/pagemap

There is a tool that will help you to get information you need from the pagemap file.

http://fivelinesofcode.blogspot.com/2014/03/how-to-translate-virtual-to-physical.html

/proc/[pid]/pagemaps and /proc/[pid]/maps | linux

Oooh K, the index was correct but comparing off64_t o (8bytes) with long index was interpreting o wrong hence why I was getting that error.
Ha! this was a stupid mistake.
So adding the appropriate header took care of that.

Missing header :-/ sigh fixes the issue of comparing off64_t with a unsigned long.

Understanding Linux /proc/pid/maps or /proc/self/maps

Each row in /proc/$PID/maps describes a region of contiguous virtual memory in a process or thread. Each row has the following fields:

address           perms offset  dev   inode   pathname
08048000-08056000 r-xp 00000000 03:0c 64593   /usr/sbin/gpm

• address - This is the starting and ending address of the region in the process's address space
• permissions - This describes how pages in the region can be accessed. There are four different permissions: read, write, execute, and shared. If read/write/execute are disabled, a - will appear instead of the r/w/x. If a region is not shared, it is private, so a p will appear instead of an s. If the process attempts to access memory in a way that is not permitted, a segmentation fault is generated. Permissions can be changed using the mprotect system call.
• offset - If the region was mapped from a file (using mmap), this is the offset in the file where the mapping begins. If the memory was not mapped from a file, it's just 0.
• device - If the region was mapped from a file, this is the major and minor device number (in hex) where the file lives.
• inode - If the region was mapped from a file, this is the file number.
• pathname - If the region was mapped from a file, this is the name of the file. This field is blank for anonymous mapped regions. There are also special regions with names like [heap], [stack], or [vdso]. [vdso] stands for virtual dynamic shared object. It's used by system calls to switch to kernel mode. Here's a good article about it: "What is linux-gate.so.1?"

You might notice a lot of anonymous regions. These are usually created by mmap but are not attached to any file. They are used for a lot of miscellaneous things like shared memory or buffers not allocated on the heap. For instance, I think the pthread library uses anonymous mapped regions as stacks for new threads.

---

Related Topics