Reverting to previous values in a memory zone in C

Question

I have played a little bit with C and written the following code:

#include<stdio.h>
#include<stdlib.h>
int main() {
    char* value = malloc(5 * sizeof(char));
    int vect[3];
    printf("%d\n", value[135151]);
    int i, count = 0;
    for(i = 0; i < 135152; i++) {
        if(value[i]) {
            count++;
            printf("position is %d, value is %d and i change it with 42\n", i, value[i]);
            value[i] = 42;
            vect[count - 1] = i;
        }
    }
    printf("count is %d\n", count);

    printf("pointer is at location %p\n", value);
    printf("changed values are %d %d %d\n", value[vect[0]], value[vect[1]],
                                                        value[vect[2]]);

    return 0;
}

After several tries, on my laptop, I have found out that if I print value[135152] I get segfault, and if I print value[135151] I get 0 at stdout.

After that, I was curious to find if there are nonzero values in this interval, and 3 nonzero values where shown.

After that, I tried to modify them all to be 42 (I forgot to mention that at many program executions, 20+, even if the vector value was shown at a different location, such as 0xbe7010 or 0x828010, the same nonzero values at the same position remained, which made me understand that the pointer address is virtual (but the location is the same)).

After, I have modified those values, I printed them in the end just to be sure, and they showed 42 all 3 of them. But, at another program execution, the previous values were shown, just like I hadn't modify that memory zone.

I will give you 3 consecutive outputs of mine:

0
position is 24, value is -31 and i change it with 42
position is 25, value is 15 and i change it with 42
position is 26, value is 2 and i change it with 42
count is 3
pointer is at location 0x21bb010
changed values are 42 42 42


0
position is 24, value is -31 and i change it with 42
position is 25, value is 15 and i change it with 42
position is 26, value is 2 and i change it with 42
count is 3
pointer is at location 0x20d1010
changed values are 42 42 42


0
position is 24, value is -31 and i change it with 42
position is 25, value is 15 and i change it with 42
position is 26, value is 2 and i change it with 42
count is 3
pointer is at location 0x19d0010
changed values are 42 42 42

Could you please tell me why those values persist even after changing?

And also, why is the pointer address changing, but memory zone is the same? (I suspect there is a bijective function between the physical and virtual memory in C that changes every time I execute the program).

Thank you for your help and sorry for this Wall of Text!

Answer 1

If I understand your question correctly, the answer is quite a bit simpler than you are thinking. On each program execution, malloc allocates memory by asking for it from the operating system, but neither malloc nor the OS have any particular reason to give you the same space in memory each time your program executes. As far as I know, if you aren't running your program as a kernel level program there really isn't any way to ensure you get the same memory address each time, and even in that case you likely won't have the same value because some other program may have written to the memory in the meantime (or the computer was shut off, since malloc allocates memory from volatile memory). What you are looking for is possibly saving your array to a file and reading from that file on program execution.

Almost everything you are doing is undefined, so I cannot give you an adequate answer to the question of why it is happening. Here are some of the different kinds of undefined behavior you are invoking:

printf("%d\n", value[135151]);

Reading past the end of your array, or more formally dereferencing any pointer whose offset is larger than the size of your array (value[5] or higher) is undefined behavior. I have made many programs were even dereferencing that causes a segfault, but in this case it appears your Operating System or initialization libraries (the stuff that the program runs before main) are allocating your program a bunch of memory without you having to ask.

if(value[i])

The value in a variable or memory space which has not been assigned a value by your program is undefined. It would be perfectly legitimate for all of the memory to be zero, or for it to have whatever value happened to be there from before. Going to your question about reading such memory, it's clearly being assigned specific values by your operating system either after it is released or before it is allocated to your program. One important reason the OS might do this is security - if a program gets the value entered into memory from the program before it, it can read that other program's data, which would be very bad if the previous program was converting plaintext passwords to hashes, for example.

value[i] = 42;

This probably goes without saying, but assigning a value to a memory location which was not allocated to you is also undefined behavior.

EDIT: In response to comment: Undefined behavior means that the standard doesn't define what happens when you do it. Obviously if a program compiles and runs, it must exhibit some behavior, but undefined behavior may be totally different depending on the compiler, standard library version, operating system, and a variety of other factors. In your case, all the variables come together to result in the behavior you are seeing, but without picking apart every detail about your compiler, environment, hardware, etc, we cannot tell you why, and more importantly, that behavior may (and likely would be) totally different if, for example, I compiled and ran this code using a different operating system and compiler.

As a side note, I tried this on a few compilers and got exactly the same results on clang 3.5.0 on Linux Red Hat and similar with gcc, so my best guess is that the information has something to do with malloc's implementation, possibly metadata for free to use when deallocating the memory.

Answer 2

I'll assume you aren't satisfied with "undefined behaviour means anything can happen", and want to know things that are not defined by C itself. Because it's not defined by C, the following is partially speculation:

Address-Space Layout Randomization, or ASLR, is a feature of most modern operating systems. It randomizes the starting address of each major memory area in your program. Its purpose is to make certain types of security vulnerabilities harder to exploit. That's not in the scope of this question.

Also, there is code that runs before main. It initializes various things within the standard library. When I say "your program", I am including this code.

Because of ASLR, the heap will start at a different address in every process. However, because your program doesn't use any other randomness (it is deterministic apart from ASLR), it always allocates memory blocks with the same size and in the same order. Since malloc is not random - apart from the starting address of the heap - on your operating system, it allocates memory in the same "pattern". Perhaps your memory block is always at (start_of_heap + 123400) and something else always gets a memory block at (start_of_heap + 123424) - in this case, the other memory block is always (your_memory_block + 24), even though the exact address varies.

What is this other memory block? It's not possible for me to guess that accurately - but given that your program doesn't crash, it's likely that your program never uses again. It might be important for some feature you aren't using, or it might be book-keeping information for the memory allocator (which never sees your overwritten values, since you never call malloc or free after that).

P.S. Overwriting memory that's not yours is a great way to cause unpredictable crashes that you can't figure out. You should seriously avoid doing this in any real programs. It's also a great way to write programs that aren't portable - maybe OSX stores something more important at that location, or maybe it doesn't even allocate that location (so you segfault when accessing it).