Tukukkk

I am trying to understand the basic of linux process memory layout and i got this program:

#include <stdio.h> // standard io

#include <stdlib.h> // C standard library

#include <pthread.h> // threading

#include <unistd.h> // unix standard library

#include <sys/types.h> // system types for linux



// getchar basically is like "read"

// it prompts the user for input

// in this case, the input is thrown away

// which makes similar to a "pause" continuation primitive 

// but a pause that is resolved through user input, which we promptly throw away!

void * thread_func (void * arg) {



    printf("Before malloc in thread 1n");

    getchar();

    char * addr = (char *) malloc(1000);

    printf("After malloc and before free in thread 1n");

    getchar();

    free(addr);

    printf("After free in thread 1n");

    getchar();



}



int main () {



    char * addr;

    printf("Welcome to per thread arena example::%dn", getpid());

    printf("Before malloc in the main threadn");

    getchar();

    addr = (char *) malloc(1000);

    printf("After malloc and before free in main threadn");

    getchar();

    free(addr);

    printf("After free in main threadn");

    getchar();



    // pointer to the thread 1

    pthread_t thread_1;

    // pthread_* functions return 0 upon succeeding, and other numbers upon failing

    int pthread_status;



    pthread_status = pthread_create(&thread_1, NULL, thread_func, NULL);



    if (pthread_status != 0) {

        printf("Thread creation errorn");

        return -1;

    }



    // returned status code from thread_1

    void * thread_1_status;



    pthread_status = pthread_join(thread_1, &thread_1_status);



    if (pthread_status != 0) {

        printf("Thread join errorn");

        return -1;

    }



    return 0;

}

When I started the program, the content in /proc/<pid>/maps is:

00400000-00401000 r-xp 00000000 08:01 1323314                            /home/oscp/xg/c/memory_layout/a.out

00600000-00601000 r--p 00000000 08:01 1323314                            /home/oscp/xg/c/memory_layout/a.out

00601000-00602000 rw-p 00001000 08:01 1323314                            /home/oscp/xg/c/memory_layout/a.out

7fcc372d7000-7fcc37491000 r-xp 00000000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37691000-7fcc37695000 r--p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37695000-7fcc37697000 rw-p 001be000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37697000-7fcc3769c000 rw-p 00000000 00:00 0 

7fcc3769c000-7fcc376b5000 r-xp 00000000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc376b5000-7fcc378b4000 ---p 00019000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc378b4000-7fcc378b5000 r--p 00018000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc378b5000-7fcc378b6000 rw-p 00019000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc378b6000-7fcc378ba000 rw-p 00000000 00:00 0 

7fcc378ba000-7fcc378dd000 r-xp 00000000 08:01 1053733                    /lib/x86_64-linux-gnu/ld-2.19.so

7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0 

7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0 

7fcc37adc000-7fcc37add000 r--p 00022000 08:01 1053733                    /lib/x86_64-linux-gnu/ld-2.19.so

7fcc37add000-7fcc37ade000 rw-p 00023000 08:01 1053733                    /lib/x86_64-linux-gnu/ld-2.19.so

7fcc37ade000-7fcc37adf000 rw-p 00000000 00:00 0 

7ffdc1cff000-7ffdc1d20000 rw-p 00000000 00:00 0                          [stack]

7ffdc1dd8000-7ffdc1ddb000 r--p 00000000 00:00 0                          [vvar]

7ffdc1ddb000-7ffdc1ddd000 r-xp 00000000 00:00 0                          [vdso]

ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

What are the purposes of these memory regions?

7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

...

7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0 

7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0 

Then I press enter a few times after running the program. After it prints "Before malloc in thread 1". The memory layout looks like below:

00400000-00401000 r-xp 00000000 08:01 1323314                            /home/oscp/xg/c/memory_layout/a.out

00600000-00601000 r--p 00000000 08:01 1323314                            /home/oscp/xg/c/memory_layout/a.out

00601000-00602000 rw-p 00001000 08:01 1323314                            /home/oscp/xg/c/memory_layout/a.out

00632000-00653000 rw-p 00000000 00:00 0                                  [heap]

7fcc36ad6000-7fcc36ad7000 ---p 00000000 00:00 0 

7fcc36ad7000-7fcc372d7000 rw-p 00000000 00:00 0 

7fcc372d7000-7fcc37491000 r-xp 00000000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37691000-7fcc37695000 r--p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37695000-7fcc37697000 rw-p 001be000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37697000-7fcc3769c000 rw-p 00000000 00:00 0 

7fcc3769c000-7fcc376b5000 r-xp 00000000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc376b5000-7fcc378b4000 ---p 00019000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc378b4000-7fcc378b5000 r--p 00018000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc378b5000-7fcc378b6000 rw-p 00019000 08:01 1053877                    /lib/x86_64-linux-gnu/libpthread-2.19.so

7fcc378b6000-7fcc378ba000 rw-p 00000000 00:00 0 

7fcc378ba000-7fcc378dd000 r-xp 00000000 08:01 1053733                    /lib/x86_64-linux-gnu/ld-2.19.so

7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0 

7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0 

7fcc37adc000-7fcc37add000 r--p 00022000 08:01 1053733                    /lib/x86_64-linux-gnu/ld-2.19.so

7fcc37add000-7fcc37ade000 rw-p 00023000 08:01 1053733                    /lib/x86_64-linux-gnu/ld-2.19.so

7fcc37ade000-7fcc37adf000 rw-p 00000000 00:00 0 

7ffdc1cff000-7ffdc1d20000 rw-p 00000000 00:00 0                          [stack]

7ffdc1dd8000-7ffdc1ddb000 r--p 00000000 00:00 0                          [vvar]

7ffdc1ddb000-7ffdc1ddd000 r-xp 00000000 00:00 0                          [vdso]

ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

What are the purposes of these two regions?

7fcc36ad6000-7fcc36ad7000 ---p 00000000 00:00 0 

7fcc36ad7000-7fcc372d7000 rw-p 00000000 00:00 0 

After it prints "After malloc and before free in thread 1", it creates another two regions below:

7fcc30000000-7fcc30021000 rw-p 00000000 00:00 0 

7fcc30021000-7fcc34000000 ---p 00000000 00:00 0 

What are the purposes of these two regions?

Your question covers many completely different things, so the answer will be long.

The first question is the meaning of

7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

in

7fcc372d7000-7fcc37491000 r-xp 00000000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37691000-7fcc37695000 r--p 001ba000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

7fcc37695000-7fcc37697000 rw-p 001be000 08:01 1053757                    /lib/x86_64-linux-gnu/libc-2.19.so

This inaccessible memory region is a gap between adjacent ELF segments of the library (which is supposed to occupy the contiguous chunk of memory). The ---p protection mode forbids using this gap for occasional memory allocation. If you strace(1) the process when it loads the library, you may see something like this:

mmap(NULL, 1848896, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0) = 0x7f9673d8f000

mprotect(0x7f9673db1000, 1671168, PROT_NONE) = 0

mmap(0x7f9673db1000, 1355776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0x22000) = 0x7f9673db1000

mmap(0x7f9673efc000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0x16d000) = 0x7f9673efc000

mmap(0x7f9673f49000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0x1b9000) = 0x7f9673f49000

The first mmap() maps the first ELF segment into the memory but reserves the space for whole library. This is done to allow the kernel to choose the location for the library on its discretion. To protect any possible gaps between segments mprotect(..., PROT_NONE) is called; then all remaining segments are mapped into the memory using mmap() - this also changes the protection mode of the appropriate memory pages from ---p to whatever mode the segment requires. You may have some fun by taking a look at how it actually works. If you want to verify how this ---p gap is formed during the loading, you may also use readelf(1) with library's binary and do some hexadecimal math with segments' locations and alignments, collating the results with the output of strace.

The second question are the following anonymous mappings:

7fcc36ad6000-7fcc36ad7000 ---p 00000000 00:00 0 

7fcc36ad7000-7fcc372d7000 rw-p 00000000 00:00 0 

This looks like a thread stack for thread 1. The second mapping is the stack itself (372d7000 - 36ad7000 = 800000 = 8 MiB, which is a default stack size limit in many distros, which, in turn, is a default stack size for pthread), and the first one is a stack guard page. This page with mode ---p protects the stack from overflowing, and triggers the segfault when the overflow happens (because of a write to this write-protected page).

Note: in older Linux kernels, the thread stacks were annotated with [stack:TID] names in maps file, but this feature was removed, so I cannot guarantee that this mapping is really a thread stack (though it looks like). However, you may use strace to find the exact thread's stack location from child_stack argument of clone() syscall and compare with this mapping.

Going on. The third question is

7fcc30000000-7fcc30021000 rw-p 00000000 00:00 0 

7fcc30021000-7fcc34000000 ---p 00000000 00:00 0 

Well, this is what malloc() in thread 1 did to allocate the memory you have requested. In short, the whole region 7fcc30000000-7fcc34000000 is a heap, from which allocations are done. The rw-p interval 7fcc30000000-7fcc30021000, allocated from this heap, will grow as you will request more and more memory with malloc(). When this heap will deplete, new one will be requested using mmap().

As you probably noticed, I don't have an explanation for the following mappings in your question:

7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0 

7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0 

I can't recognize those guys quickly and not sure that these are ordinary allocations. Probably this needs separate investigation, as this topic is already too long.