> Howdy, > > I ran into a weird issue today while playing around with pmap. In an > effort to better understand the memory organization of a process, I > created a test program [1] to malloc() memory, and to print the address > where the memory is located. When I run my test program, I get the > following output: > > $ ./foo & > Touching memory pages starting at address 209f8 > [1] 5890 > > To see where memory (especially the heap) is located, I ran pmap against > the process: > > $ pmap -x 5890 > 5890: ./foo > Address Kbytes RSS Anon Locked Mode Mapped File > 00010000 8 8 - - r-x-- foo > 00020000 8 8 8 - rwx-- foo > 00022000 1032 1032 1032 - rwx-- [ heap ] > ... > > If the heap starts at address 22000, how can the chunk of memory I > allocated start at address 209f8? > > Thanks for any insight, > - Ryan
When the linker maps in the various ELF sections of the executable, you typically have a read-only segment (the .text and .rodata sections) followed by a read-write segment (the .data section). This is what you see in your output above (r-x at 10000 and rwx at 20000). The heap is going to start just after your writable data. But your writable data probably doesn't end exactly on a page boundary, so there's some free space there and we use that as the start of the heap. Then when that is used up, brk() will start adding new pages of anonymous memory as the heap grows. So in pmap(1) we faced this little dilemma in that we report mappings and try to label them, but here we have a mapping with overloaded purposes. Roger and I debated this for a while and decided the best answer was to leave data labeled as the object file and show [ heap ] only when the page is 100% dedicated heap. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
