Shulou(Shulou.com)06/01 Report--

PostgreSQL uses the process architecture, and each connection corresponds to a background process. In order to better understand this architecture, it is necessary to deeply understand the relevant knowledge of the process. This section mainly introduces the process virtual memory structure under Linux and illustrates it by using C language sample program.

1. Malloc

The sample code in the previous sections allocates memory through malloc, and there is heap in the process's virtual memory. If you don't use malloc, does the virtual memory have heap?

[root@localhost linux] # cat 0-main.c # include # include / * * main-do nothing * * Return: EXIT_FAILURE if something failed. Otherwise EXIT_SUCCESS * / int main (void) {getchar (); return (EXIT_SUCCESS);}

Compile and execute to view the maps of the process

[root@localhost ~] # ps-ef | grep\\. / 0root 21802 18855 0 16:45 pts/7 00:00:00. / 0root 21832 21806 0 16:45 pts/0 00:00:00 grep-- color=auto. / 0 [root@localhost ~] # cat / proc/21802/maps00400000-00401000 r-xp 00000000 fd:00 252008457 / data/source/linux/000600000-00601000 Raquin p 00000000 fd:00 252008457 / data/source/linux/000601000-00602000 rw-p 00001000 fd:00 252008457 / data/source/linux/07fc6e03c5000-7fc6e057d000 r-xp 00000000 fd:00 153635 / usr/lib64/libc-2.17.so7fc6e057d000-7fc6e077d000-p 001b8000 fd:00 153635 / usr/lib64/libc-2.17.so7fc6e077d000-7fc6e0781000 Rmurp 001b8000 fd:00 153635 / usr/lib64/libc-2.17.so7fc6e0781000-7fc6e0783000 rw-p 001bc000 fd:00 153635 / usr/lib64/libc-2.17.so7fc6e0783000-7fc6e0788000 rw-p 00000000 00:00 0 7fc6e0788000-7fc6e07a9000 r-xp 00000000 fd:00 153628 / usr/lib64/ld-2.17.so7fc6e099c000-7fc6e099f000 rw-p 00000000 00:00 0 7fc6e09a7000-7fc6e09a9000 rw-p 00000000 : 000 7fc6e09a9000-7fc6e09aa000 r Murmurp 00021000 fd:00 153628 / usr/lib64/ld-2.17.so7fc6e09aa000-7fc6e09ab000 rw-p 00022000 fd:00 153628 / usr/lib64/ld-2.17.so7fc6e09ab000-7fc6e09ac000 rw-p 00000000 00:00 0 7ffe3c606000-7ffe3c627000 rw-p 00000000 00:00 0 [stack] 7ffe3c6b3000-7ffe3c6b5000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] [root@localhost ~] #

There is no [heap].

Malloc is not a system call, man malloc explains as follows

[.] Allocate dynamic memory […]

Void * malloc (size_t size)

[.]

The malloc () function allocates size bytes and returns a pointer to the allocated memory.

What system functions does malloc call? Can be analyzed by strace

[root@localhost linux] # cat 3-main.c # include # include # include / * * main-let's find out which syscall malloc is using * * Return: EXIT_FAILURE if something failed. Otherwise EXIT_SUCCESS * / int main (void) {void * p; write (1, "BEFORE MALLOC\ n", 14); p = malloc (1); write (1, "AFTER MALLOC\ n", 13); printf ("% p\ n", p); getchar (); return (EXIT_SUCCESS);}

Compile and execute, the strace output is as follows

[root@localhost ~] # strace. / 3execve (". / 3", [. / 3 "], [/ * 25 vars * /]) = 0brk (NULL) = 0x1abe000mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,-1,0) = 0x7fe132467000access (" / etc/ld.so.preload ", R_OK) =-1 ENOENT (No such file or directory) open (" / etc/ld.so.cache ") O_RDONLY | O_CLOEXEC) = 3fstat (3, {st_mode=S_IFREG | 0644, st_size=34897,...}) = 0mmap (NULL, 34897, PROT_READ, MAP_PRIVATE, 3,0) = 0x7fe13245e000close (3) = 0open ("/ lib64/libc.so.6", O_RDONLY | O_CLOEXEC) = 3read (3) "\ 177ELF\ 2\ 1\ 3\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 0\ 3\ 0 >\ 0\ 1\ 0\ 0\ 3\ 0 >\ 0\ 1\ 0\ 0\ 20\ 35\ 2\ 0\ 0\ 0\ 0\ 0\ 0.) = 832fstat (3, {st_mode=S_IFREG | 0755, st_size=2127336,...}) = 0mmap (NULL, 3940800, PROT_READ | PROT_EXEC, MAP_PRIVATE | MAP_DENYWRITE, 3, 0) = 0x7fe131e84000mprotect (0x7fe13203c000, 2097152, PROT_NONE) = 0mmap (0x7fe13223c000, 24576) PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED | MAP_DENYWRITE, 3, 0x1b8000) = 0x7fe13223c000mmap (0x7fe132242000, 16832, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS,-1,0) = 0x7fe132242000close (3) = 0mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,-1,0) = 0x7fe13245d000mmap (NULL, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,-1,0) = 0x7fe13245b000arch_prctl (ARCH_SET_FS) 0x7fe13245b740) = 0mprotect (0x7fe13223c000, 16384, PROT_READ) = 0mprotect (0x600000, 4096, PROT_READ) = 0mprotect (0x7fe132468000, 4096, PROT_READ) = 0munmap (0x7fe13245e000, 34897) = 0write (1, "BEFORE MALLOC\ n", 14BEFORE MALLOC) = 14brk (NULL) = 0x1abe000brk (0x1adf000) = 0x1adf000brk (NULL) = 0x1adf000write (1 "AFTER MALLOC\ n", 13AFTER MALLOC) = 13fstat (1, {st_mode=S_IFCHR | 0620, st_rdev=makedev (136,5),...}) = 0mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,-1,0) = 0x7fe132466000write (1, "0x1abe010\ n", 100x1abe010) = 10fstat (0, {st_mode=S_IFCHR | 0620, st_rdev=makedev (136,5),...}) = 0mmap (NULL, 4096, PROT_READ | PROT_WRITE MAP_PRIVATE | MAP_ANONYMOUS,-1,0) = 0x7fe132465000read (0)

As you can see, malloc calls brk to allocate heap memory, and the size is 0x21000 to view the maps of the process.

[root@localhost linux] # cat / proc/14502/maps00400000-00401000 r-xp 00000000 fd:00 36596343 / root/300600000-00601000 r Meltel p 00000000 fd:00 36596343 / root/300601000-00602000 rw-p 00001000 fd:00 36596343 / root/301abe000-01adf000 rw-p 00000000 00:00 0 [heap] 7fe131e84000-7fe13203c000 r-xp 00000000 fd:00 153635 / usr/lib64/libc-2.17.so7fe13203c000-7fe13223c000-p 001b8000 fd:00 153635 / usr/lib64/libc-2.17.so7fe13223c000-7fe132240000 RMurray p 001b8000 fd:00 153635 / usr/lib64/libc-2.17.so7fe132240000-7fe132242000 rw-p 001bc000 fd:00 153635 / usr/lib64/libc-2.17.so7fe132242000-7fe132247000 rw-p 00000000 00:00 0 7fe132247000-7fe132268000 r-xp 00000000 fd:00 153628 / usr/lib64/ld-2.17.so7fe13245b000-7fe13245e000 rw-p 00000000 00:00 0 7fe132465000-7fe132468000 rw-p 00000000 00:00 0 7fe132468000-7fe132469000 Ruki p 00021000 fd:00 153628 / usr/lib64/ld-2.17.so7fe132469000-7fe13246a000 rw-p 00022000 fd:00 153628 / usr/lib64/ld-2.17.so7fe13246a000-7fe13246b000 rw-p 00000000 00:00 0 7ffdfb7b5000-7ffdfb7d6000 rw-p 00000000 00:00 0 [stack] 7ffdfb7ef000-7ffdfb7f1000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] [root@localhost linux] #

01abe000-01adf000 rw-p 00000000 00:00 0 [heap]

Consistent with the strace trace output.

Execute the sample code above

[root@localhost linux] #. / 3BEFORE MALLOCAFTER MALLOC0x1123010

The output is 0x1123010, but the actual starting address is 0x1123000. What is the total of 16 bytes of extra 0x10? In fact, these 16 bytes, the lower 8 bits is the size of the last unallocated chunk (or 0x0 if allocated), and the high 8 bits is the size of the block.

[root@localhost linux] # cat 5-main.c # include # include # include / * pmem-print mem * @ p: memory address to Start printing from * @ bytes: number of bytes to print * * Return: Nothing * / void pmem (void * p Unsigned int bytes) {unsigned char * ptr Unsigned int i; ptr = (unsigned char *) p; for (I = 0; I < bytes; iTunes +) {if (I! = 0) {printf ("");} printf ("x", * (ptr + I));} printf ("\ n");} / * * main-the 0x10 lost bytes * * Return: EXIT_FAILURE if something failed. Otherwise EXIT_SUCCESS * / int main (void) {void * p; int i; for (I = 0; I < 10; iTunes +) {p = malloc (1024 * (I + 1)); printf ("% p\ n", p); printf ("bytes at% p:\ n", (void *) ((char *) p-0x10)); pmem ((char *) p-0x10, 0x10) } return (EXIT_SUCCESS);} [root@localhost linux] #

Compilation execution

[root@localhost linux] #. / 50x2416010bytes at 0x2416000:00 00 00 00 11 04 00 00 00 00...

This is the content of the first 16 bytes of the memory address pointed to by p, 0x4011, where 0x4010 is the size of the block (1024 bytes + 16 bytes) and 0x0001 is the flag bit used to mark whether the last chunk is in use.

II. Reference materials

Virtual memory

Hack the Virtual Memory: malloc, the heap & the program break

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.