In C, why are the first members of a struct frequently "reset" to 0 when it is deallocated with free()?

The setup

Let's say I have a struct father which has member variables such as an int, and another struct(so father is a nested struct). This is an example code:

struct mystruct {
    int n;
};

struct father {
    int test;
    struct mystruct M;
    struct mystruct N;
};

In the main function, we allocate memory with malloc() to create a new struct of type struct father, then we fill it's member variables and those of it's children:

    struct father* F = (struct father*) malloc(sizeof(struct father));
    F->test = 42;
    F->M.n = 23;
    F->N.n = 11;

We then get pointers to those member variables from outside the structs:

    int* p = &F->M.n;
    int* q = &F->N.n;

After that, we print the values before and after the execution of free(F), then exit:

    printf("test: %d, M.n: %d, N.n: %d\n", F->test, *p, *q);
    free(F);
    printf("test: %d, M.n: %d, N.n: %d\n", F->test, *p, *q);
    return 0;

This is a sample output(*):

test: 42, M.n: 23, N.n: 11
test: 0, M.n: 0, N.n: 1025191952

*: Using gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

Full code on pastebin: https://pastebin.com/khzyNPY1

The question

That was the test program that I used to test how memory is deallocated using free(). My idea(from reading K&R "8.7 Example - A Storage Allocator", in which a version of free() is implemented and explained) is that, when you free() the struct, you're pretty much just telling the operating system or the rest of the program that you won't be using that particular space in memory that was previously allocated with malloc(). So, after freeing those memory blocks, there should be garbage values in the member variables, right? I can see that happening with N.n in the test program, but, as I ran more and more samples, it was clear that in the overwhelming majority of cases, these member variables are "reset" to 0 more than any other "random" value. My question is: why is that? Is it because the stack/heap is filled with zeroes more frequently than any other value?

As a last note, here are a few links to related questions but which do not answer my particular question:

Solution

Apart from undefined behavior and whatever else the standard might dictate, since the dynamic allocator is a program, fixed a specific implementation, assuming it does not make decisions based on external factors (which it does not) the behavior is completely deterministic.

Real answer: what you are seeing here is the effect of the internal workings of glibc's allocator (glibc is the default C library on Ubuntu).

The internal structure of an allocated chunk is the following (source):

struct malloc_chunk {
    INTERNAL_SIZE_T      mchunk_prev_size;  /* Size of previous chunk (if free).  */
    INTERNAL_SIZE_T      mchunk_size;       /* Size in bytes, including overhead. */
    struct malloc_chunk* fd;                /* double links -- used only if free. */
    struct malloc_chunk* bk;        
    /* Only used for large blocks: pointer to next larger size.  */
    struct malloc_chunk* fd_nextsize;       /* double links -- used only if free. */
    struct malloc_chunk* bk_nextsize;
};

In memory, when the chunk is in use (not free), it looks like this:

chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Size of previous chunk, if unallocated (P clear)  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Size of chunk, in bytes                     |A|M|P| flags
  mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             User data starts here...                          |

Every field except mchunk_prev_size and mchunk_size is only populated if the chunk is free. Those two fields are right before the user usable buffer. User data begins right after mchunk_size (i.e. at the offset of fd), and can be arbitrarily large. The mchunk_prev_size field holds the size of the previous chunk if it's free, while the mchunk_size field holds the real size of the chunk (which is at least 16 bytes more than the requested size).

A more thorough explanation is provided as comments in the library itself here (highly suggested read if you want to know more).

When you free() a chunk, there are a lot of decisions to be made as to where to "store" that chunk for bookkeeping purposes. In general, freed chunks are sorted into double linked lists based on their size, in order to optimize subsequent allocations (that can get already available chunks of the right size from these lists). You can see this as a sort of caching mechanism.

Now, depending on your glibc version, they could be handled slightly differently, and the internal implementation is quite complex, but what is happening in your case is something like this:

struct malloc_chunk *victim = addr; // address passed to free()

// Add chunk at the head of the free list
victim->fd = NULL;
victim->bk = head;
head->fd = victim;

Since your structure is basically equivalent to:

struct x {
    int a;
    int b;
    int c;
}

And since on your machine sizeof(struct malloc_chunk *) == 2 * sizeof(int), the first operation (victim->fd = NULL) is effectively wiping out the contents of the first two fields of your structure (remember, user data begins exactly at fd), while the second one (victim->bk = head) is altering the third value.