2

I could identify the text, ds and bss segments in /proc/$PID/maps file (by guessing or with the help of access-specifiers of a particular segment). But heap and stack segments are given sequently. Is there a way to identify which segment belongs to stack and which belongs to heap?

----- How to identify the demarkation between heap and stack in this example ---------- 0a8a0000-0ab2e000 rw-p 0a8a0000 00:00 0 [heap]
< b648e000-b648f000 ---p b648e000 00:00 0
< b648f000-b6496000 rw-p b648f000 00:00 0
< b6496000-b6497000 ---p b6496000 00:00 0
< b6497000-b649e000 rw-p b6497000 00:00 0
< b649e000-b649f000 ---p b649e000 00:00 0
< b649f000-b64a6000 rw-p b649f000 00:00 0
< b64a6000-b64a7000 ---p b64a6000 00:00 0
< b64a7000-b64ae000 rw-p b64a7000 00:00 0
< b64ae000-b64af000 ---p b64ae000 00:00 0
< b64af000-b657a000 rw-p b64af000 00:00 0
< b657a000-b657b000 ---p b657a000 00:00 0
< b657b000-b65a5000 rw-p b657b000 00:00 0
< b65a5000-b65a6000 ---p b65a5000 00:00 0
< b65a6000-b67ca000 rw-p b65a6000 00:00 0
< b67ca000-b67cb000 ---p b67ca000 00:00 0
< b67cb000-b69ff000 rw-p b67cb000 00:00 0
< b69ff000-b6a00000 ---p b69ff000 00:00 0
< b6a00000-b6bff000 rw-p b6a00000 00:00 0
< b6bff000-b6c00000 ---p b6bff000 00:00 0
< b6c00000-b6dff000 rw-p b6c00000 00:00 0
< b6dff000-b6e00000 ---p b6dff000 00:00 0
< b6e00000-b6fff000 rw-p b6e00000 00:00 0
< b6fff000-b7000000 ---p b6fff000 00:00 0
< b7000000-b70fd000 rw-p b7000000 00:00 0
< b70fd000-b70fe000 ---p b70fd000 00:00 0
< b70fe000-b72fd000 rw-p b70fe000 00:00 0
< b72fd000-b72fe000 ---p b72fd000 00:00 0
< b72fe000-b7548000 rw-p b72fe000 00:00 0
< b7548000-b7549000 ---p b7548000 00:00 0
< b7549000-b7f37000 rw-p b7549000 00:00 0
< b7f4b000-b7f4c000 ---p b7f4b000 00:00 0
< b7f4c000-b7f51000 rw-p b7f4c000 00:00 0
< bfbae000-bfbc3000 rw-p bffea000 00:00 0 [stack]

gulam
  • 124
  • 1
  • 1
  • 8
  • The stack segment is the only marked `[stack]`. Every other writable segment is the heap, almost by definition. Otherwise, give us your precise definition of *heap* – Basile Starynkevitch Oct 15 '13 at 11:24
  • "Segment" is a term that was relevant 20 years ago. Any modern system is much more complex than the simplistic "code/data/heap/stack segment" description given by literature. In a threaded application you'll have as many stacks as threads, the heap doesn't have to be contiguous, you'll have tons of data mixed with code and read-only data and auxiliary data and PLT and GOT from shared libraries, memory mapped files, special code mappings maintained by the kernel, guard pages, etc. – Art Oct 15 '13 at 11:48
  • 1
    possible duplicate of [Understanding Linux /proc/id/maps](http://stackoverflow.com/questions/1401359/understanding-linux-proc-id-maps) – gavv Sep 28 '15 at 13:13

1 Answers1

6

The /proc/PID/maps file containing the currently mapped memory regions and their access permissions.

The format is:

address           perms offset  dev   inode      pathname

08048000-08049000 r-xp 00000000 03:00 8312       /opt/test
08049000-0804a000 rw-p 00001000 03:00 8312       /opt/test
0804a000-0806b000 rw-p 00000000 00:00 0          [heap]
a7cb1000-a7cb2000 ---p 00000000 00:00 0
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
a7eb2000-a7eb3000 ---p 00000000 00:00 0
a7eb3000-a7ed5000 rw-p 00000000 00:00 0          [stack:1001]
a7ed5000-a8008000 r-xp 00000000 03:00 4222       /lib/libc.so.6
a8008000-a800a000 r--p 00133000 03:00 4222       /lib/libc.so.6
a800a000-a800b000 rw-p 00135000 03:00 4222       /lib/libc.so.6
a800b000-a800e000 rw-p 00000000 00:00 0
a800e000-a8022000 r-xp 00000000 03:00 14462      /lib/libpthread.so.0
a8022000-a8023000 r--p 00013000 03:00 14462      /lib/libpthread.so.0
a8023000-a8024000 rw-p 00014000 03:00 14462      /lib/libpthread.so.0
a8024000-a8027000 rw-p 00000000 00:00 0
a8027000-a8043000 r-xp 00000000 03:00 8317       /lib/ld-linux.so.2
a8043000-a8044000 r--p 0001b000 03:00 8317       /lib/ld-linux.so.2
a8044000-a8045000 rw-p 0001c000 03:00 8317       /lib/ld-linux.so.2
aff35000-aff4a000 rw-p 00000000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]

where "address" is the address space in the process that it occupies, "perms" is a set of permissions:

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

"offset" is the offset into the mapping, "dev" is the device (major:minor), and "inode" is the inode on that device. 0 indicates that no inode is associated with the memory region, as the case would be with BSS (uninitialized data). The "pathname" shows the name associated file for this mapping. If the mapping is not associated with a file:

 [heap]                   = the heap of the program
 [stack]                  = the stack of the main process
 [stack:1001]             = the stack of the thread with tid 1001
 [vdso]                   = the "virtual dynamic shared object",
                            the kernel system call handler

or if empty, the mapping is anonymous. (Source https://www.kernel.org/doc/Documentation/filesystems/proc.txt)

Jain Rach
  • 4,069
  • 1
  • 16
  • 25
  • 2
    Do you mean to say only those segments/pages which are marked as '[heap]' belong to Heap Segment? But @basile-starynkevitch says only those segments/pages which are marked as '[stack]' belong to stack and all other belong to Heap Segment? I'm confused... – gulam Oct 21 '13 at 06:29
  • if the task sees it as a stack you will see the mark [stack]. If its heap it will be shown with [heap] .... Documentation clearly mentions this . – Jain Rach Oct 21 '13 at 10:03
  • 2
    If it's the case, then why should OS allocate so many "Anonymous Segments" to a process (other than stack and heap)? – gulam Oct 21 '13 at 12:32
  • Actually "Anonymous" shows the amount of memory that does not belong to any file. Even a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE and a page is modified, the file page is replaced by a private anonymous copy. "Swap" shows how much would-be-anonymous memory is also used, but out on swap.if it is anonymous , we can consider that blocks are specially belongs delicately to kernal space . – Jain Rach Oct 21 '13 at 13:00
  • 1
    Why should OS allocate memory that does not belong to any file? What's the point in allocating such segments? And how the memory we request from OS (from our code) is related to the amount of memory allocated "anonymously"? – gulam Oct 30 '13 at 07:51