A pmap is a command-line utility on Linux and Unix systems that displays the memory map of a running process. You give it a process ID, and it shows you exactly how that process is using memory: which libraries it has loaded, how much space each one takes, and what permissions each memory region has. It’s one of the fastest ways to understand what’s happening inside a process from a memory perspective.
The term “pmap” also appears in brain imaging research, where it refers to a probability map. Both meanings are covered below.
How Pmap Works
Every running process on a Linux system has a virtual memory layout. The kernel tracks which chunks of memory belong to which process, what those chunks contain (program code, libraries, stack space, heap data), and what the process is allowed to do with each chunk. All of this information lives in the /proc filesystem, a virtual directory the kernel maintains for every active process.
When you run pmap followed by a process ID, the tool reads that kernel data and formats it into a human-readable table. Each row represents one memory region, or “mapping,” and the output tells you the starting address, the size in kilobytes, the permission flags, and the name of the file or library mapped into that region. At the bottom, you get a total showing the process’s overall memory footprint.
Reading the Output
The basic output of pmap is straightforward: address, size, permissions, and mapping name. But when you use the extended mode (typically with the -x flag), you get additional columns that are more useful for diagnosing problems:
- RSS (Resident Set Size): The amount of memory from that mapping that’s actually loaded into physical RAM right now, as opposed to sitting on disk.
- Dirty: Memory pages that have been modified by the process. Dirty pages haven’t been written back to disk yet, so they represent data that exists only in RAM.
- Mapping: The name of the library, file, or label associated with that memory region. This tells you whether you’re looking at a shared library, the program’s own code, its heap, or its stack.
Some mappings will show up as “anonymous” memory, meaning they aren’t backed by any file on disk. The process heap (where dynamically allocated data lives) and the stack (where function call data is stored) are both anonymous. Copy-on-write pages from privately mapped files also appear as anonymous memory.
Permission Flags
Each memory region carries a set of permission flags that control what the process can do with it. These appear as a short string of letters in the output:
- r: The process can read from this region.
- w: The process can write to this region.
- x: The process can execute instructions stored in this region.
- s: The region is shared. Changes the process makes here are visible to other processes that share the same mapping, and those changes get written back to the underlying file.
- p: The region is private. The process gets its own copy, and modifications stay local.
A region marked r-x is typical for executable code: the process can read and run it, but not modify it. A region marked rw- is typical for data segments and the heap, where the process needs to both read and write but shouldn’t be executing anything. If you see unexpected rwx regions (readable, writable, and executable all at once), that can be a security concern worth investigating.
When Pmap Is Useful
The most common reason to reach for pmap is troubleshooting memory consumption. If a process is using more memory than expected, tools like ps or top will tell you the total, but pmap breaks it down by region. You can see exactly which shared library is consuming the most space, whether the heap has grown unusually large, or whether a memory-mapped file is responsible for the bloat.
For tracking memory leaks over time, you can run pmap repeatedly against the same process and compare the output. If the heap or anonymous memory regions keep growing between snapshots while the process isn’t doing anything new, that’s a strong signal of a leak. The extended output makes this easier because you can watch the RSS and dirty columns climb.
Pmap is also helpful when you need to verify that a process has loaded the correct version of a shared library. The mapping column shows the full file path, so you can confirm whether your application picked up the system library or a custom one you installed elsewhere.
Pmap vs. Other Memory Tools
Linux offers several ways to inspect memory, and each has a different strength. Tools like ps and top give you a single number for a process’s memory usage, which is useful for a quick overview but tells you nothing about where that memory is going. Pmap fills the gap by showing the full memory layout, region by region.
For shared memory analysis, tools like smem go a step further by calculating proportional set size (PSS), which divides shared library memory evenly among all the processes using it. Pmap doesn’t do this. It reports the full RSS for each mapping regardless of sharing, so if ten processes all use the same library, pmap will count that library’s memory in each one. Keep that in mind when adding up totals across processes.
If you need to go even deeper than pmap, reading /proc/[pid]/smaps directly gives you the most granular data the kernel offers, including page table entries and swap usage per mapping. Pmap is essentially a friendlier interface to that same data.
Pmap in Brain Imaging
Outside of computing, “pmap” is shorthand for probability map in neuroscience and medical imaging. A probability map is a 3D representation of the brain where each tiny volume (voxel) is assigned a value indicating how likely it is to belong to a specific brain region across a group of people.
Because no two brains are shaped exactly alike, researchers build these maps by studying postmortem brains and overlaying their structures in a common reference space. Each voxel gets a frequency value representing how many of the studied brains had a particular area at that location. A voxel with a probability of 8 out of 10 means that in 80% of the brains examined, that spot belonged to the labeled region.
A related concept is the maximum probability map (MPM), which takes things one step further. Instead of showing overlapping probabilities, the MPM assigns each voxel to whichever brain area had the highest probability there, creating a clean, non-overlapping parcellation of the brain. This is different from classical brain maps drawn from a single “typical” brain. The MPM reflects the most likely area based on a sample, accounting for natural variation between individuals. Researchers integrate these maps into functional imaging experiments to better understand which brain structures are active during specific tasks.