proc_pid_maps(5)

💖 PROC_PID_MAPS(5) — like, the manual page, bestie 💖

okay so bestie, welcome to proc_pid_maps(5), the file formats manual page that's about to tell you everything about peeking at a process's memory map. no cap, this one is a banger. 🫶

---

✨ NAME ✨

/proc/pid/maps — mapped memory regions 🌸

---

🦋 DESCRIPTION 🦋

/proc/pid/maps

it's a file bestie!! it holds all the currently mapped memory regions of a process and their access permissions. the way that it just... shows you everything?? iconic. if you want more lore on memory mappings themselves, go read mmap(2) — she's the main character of that story. 💅

now, who's even allowed to read this file? permission to access it is governed by CAP_PERFMON (that's since Linux 6.15, slay) or a ptrace access mode PTRACE_MODE_READ_FSCREDS check. see ptrace(2) for the whole vibe check situation. 🔥

the format of the file is:

address           perms offset  dev   inode       pathname
00400000-00452000 r-xp 00000000 08:02 173521      /usr/bin/dbus-daemon
00651000-00652000 r--p 00051000 08:02 173521      /usr/bin/dbus-daemon
00652000-00655000 rw-p 00052000 08:02 173521      /usr/bin/dbus-daemon
00e03000-00e24000 rw-p 00000000 00:00 0           [heap]
00e24000-011f7000 rw-p 00000000 00:00 0           [heap]
...
35b1800000-35b1820000 r-xp 00000000 08:02 135522  /usr/lib64/ld-2.15.so
35b1a1f000-35b1a20000 r--p 0001f000 08:02 135522  /usr/lib64/ld-2.15.so
35b1a20000-35b1a21000 rw-p 00020000 08:02 135522  /usr/lib64/ld-2.15.so
35b1a21000-35b1a22000 rw-p 00000000 00:00 0
35b1c00000-35b1dac000 r-xp 00000000 08:02 135870  /usr/lib64/libc-2.15.so
35b1dac000-35b1fac000 ---p 001ac000 08:02 135870  /usr/lib64/libc-2.15.so
35b1fac000-35b1fb0000 r--p 001ac000 08:02 135870  /usr/lib64/libc-2.15.so
35b1fb0000-35b1fb2000 rw-p 001b0000 08:02 135870  /usr/lib64/libc-2.15.so
...
f2c6ff8c000-7f2c7078c000 rw-p 00000000 00:00 0    [stack:986]
...
7fffb2c0d000-7fffb2c2e000 rw-p 00000000 00:00 0   [stack]
7fffb2d48000-7fffb2d49000 r-xp 00000000 00:00 0   [vdso]

heads up — the original sample block is shown with a little leading indentation in the man page source; either way, the columns are the columns. 👑 or whatever, we keep it cute.

the fields, one by one 🎀

• the address field is the address space in the process that the mapping occupies.
• the perms field is a set of permissions, and every single letter matters:

r = read
w = write
x = execute
s = shared
p = private (copy on write)

• the offset field is the offset into the file/whatever. yes, "whatever." that's the actual vibe of the original and we respect it. 💜
• dev is the device, written as major:minor.
• inode is the inode on that device. a 0 here means no inode is associated with the memory region, which is exactly what you'd see with BSS (uninitialized data). not me knowing exactly what BSS is... okay yes me. 💅

the pathname field 🧚

the pathname field will usually be the file that is backing the mapping. and if you're dealing with ELF files, you can easily coordinate it with the offset field by looking at the Offset field in the ELF program headers — that's readelf -l, bestie. slay. ✨

there are also these additional helpful pseudo-paths 🌈

• [stack] — the initial process's stack (also known as the main thread's stack). 🫶
• [stack:tid] (from Linux 3.4 to Linux 4.4) — a thread's stack, where the tid is a thread ID. it corresponds to the /proc/pid/task/tid/ path. this field was removed in Linux 4.5, because providing this information for a process with large numbers of threads is expensive. she was too much for the system to handle, honestly relatable. 😭
• [vdso] — the virtual dynamically linked shared object. see vdso(7) for the lore. ⭐
• [heap] — the process's heap. we love her. 🍓
• [anon:name] (since Linux 5.17) — a named private anonymous mapping. set with prctl(2) PR_SET_VMA_ANON_NAME. 👑
• [anon_shmem:name] (since Linux 6.2) — a named shared anonymous mapping. set with prctl(2) PR_SET_VMA_ANON_NAME. 💖

if the pathname field is blank 🫥

then bestie, this is an anonymous mapping as obtained via mmap(2). and ngl, there is no easy way to coordinate this back to a process's source, short of running it through gdb(1), strace(1), or similar. it's giving mystery. it's giving "we don't know her." 🙈

the newline situation, and it's a whole thing 💀

pathname is shown unescaped except for newline characters, which are replaced with an octal escape sequence. as a result — and this is the plot twist — it is not possible to determine whether the original pathname contained a newline character or the literal \012 character sequence. genuinely ambiguous. we're out here guessing. 😭

and if the file got deleted 🪦

if the mapping is file-backed and the file has been deleted, the string " (deleted)" is appended to the pathname. note that this is ambiguous too. yes, again. the ambiguity is not a bug, it's a lifestyle. 💅

throwback corner 🕰️

under Linux 2.0, there is no field giving pathname. ancient behavior, lowkey fascinating, we weren't there but we respect the elders. 🌸

---

🌟 SEE ALSO 🌟

• proc(5)

---

and that's the whole page bestie!! 💖 this was the proc_pid_maps(5) page as told by me, your local Unix-enjoying girlie. the source is the Linux man-pages, version 6.20, dated 2026-09-17 — so like, remember to stan the version you're actually running, mwah 🎀💅✨