cat /proc/pid/maps
 

int main()
{
for( ; ; );
return 1;
}

For the above program , cat /proc/pid/maps gives the following output.

1) In this we can find , every library + object file is present three times. Why it is present 3 times?

2) There is no heap region associated with this process. Why?

3). Stack region is present 3 times and the size is 0.
Why?

Kindly share your ideas on both kernelspace/userspace point of view.

root@prabagaran-VirtualBox:/proc# cat 4988/maps


001f7000-001f8000 r-xp 00000000 00:00 0 [vdso]
00804000-00822000 r-xp 00000000 08:01 1442712 /lib/i386-linux-gnu/ld-2.13.so
00822000-00823000 r--p 0001d000 08:01 1442712 /lib/i386-linux-gnu/ld-2.13.so
00823000-00824000 rw-p 0001e000 08:01 1442712 /lib/i386-linux-gnu/ld-2.13.so
008df000-00a55000 r-xp 00000000 08:01 1442725 /lib/i386-linux-gnu/libc-2.13.so
00a55000-00a57000 r--p 00176000 08:01 1442725 /lib/i386-linux-gnu/libc-2.13.so
00a57000-00a58000 rw-p 00178000 08:01 1442725 /lib/i386-linux-gnu/libc-2.13.so
00a58000-00a5b000 rw-p 00000000 00:00 0
08048000-08049000 r-xp 00000000 00:16 1148699 /home/prabagaran/host/Documents and Settings/emo/Desktop/learning/test/2.out
08049000-0804a000 r--p 00000000 00:16 1148699 /home/prabagaran/host/Documents and Settings/emo/Desktop/learning/test/2.out
0804a000-0804b000 rw-p 00001000 00:16 1148699 /home/prabagaran/host/Documents and Settings/emo/Desktop/learning/test/2.out
b782a000-b782b000 rw-p 00000000 00:00 0
b783a000-b783d000 rw-p 00000000 00:00 0
bfed5000-bfef6000 rw-p 00000000 00:00 0 [stack]

Well, I waited to see if anyone else more knowledgeable would reply as I am certainly no expert, but here goes...

I don't know why three entries for a loaded program or shared object. It used to be just two entries, and I can tell you why there were two.

The entry that is marked 'r-xp' is a code segment (sometimes called a text segment). It's the actual executable code in a program or .so (shared object).

The entry that is marked 'rw-p is the data segment (sometimes called .bss segment). I contains the program's variables and constants. Or at least it used to.

That leaves the 'r--p' areas. ?. Maybe program constants now?

You can use 'objdump' or 'readelf' to examine a program or .so, but it's somewhat complicated.

I think heap is malloc'd virtual memory and is represented by these entries:
I believe the '00:00' (major:minor number) and '0' (inode) signify that the memory area is malloc'd.
I think only the one that is marked [stack] is stack, and it's 4k in size (ending address bfef6000 minus starting address bfed5000 = 0x1000, or 4096 bytes). The reason I don't think the other two areas are stack is that they are not adjacent to the one marked stack.

Hope that helps.

Thanks tommylovell for your help.

I have some points to add here.

1). These entries cannot be the heap.
Since , heap is represented by the name [heap]

00a58000-00a5b000 rw-p 00000000 00:00 0
b782a000-b782b000 rw-p 00000000 00:00 0
b783a000-b783d000 rw-p 00000000 00:00 0
bfed5000-bfef6000 rw-p 00000000 00:00 0 [stack]

heap section looks something like this(this line if of a different program)
0965d000-0967e000 rw-p 00000000 00:00 0 [heap]

2).
001f7000-001f8000 r-xp 00000000 00:00 0 [vdso]

Can you tell what this is about(should be some executable code).

3). I guess
00a58000-00a5b000 rw-p 00000000 00:00 0

should be the data segment. It spans 3 pages of memory.
Can you share your idea about this.

4). Since the stack grows from the top to bottom of memory , i guess

b782a000-b782b000 rw-p 00000000 00:00 0
b783a000-b783d000 rw-p 00000000 00:00 0
bfed5000-bfef6000 rw-p 00000000 00:00 0 [stack]

all the three would be something related to stack. (Address starts with 0xbxxxxxxx , all remaining address starts with 0x0xxxxxxx).

5). I believe the '00:00' (major:minor number) and '0' (inode) signify that the memory area is malloc'd.

I am not sure about this since why inode , major:minor number are coming into picture for malloc.
As i know , heap is an anonymous VMA. So , no inode will be associated with this.
Kindly share your views on this.