Thread: Memory Allocation and Structs

Accessing memory that has been freed is Undefined behaviour [1]. There is no guarantee that it will work, or that it will NOT work. It depends on the implementation of the compiler and if the block of memory gets reused. For example this:

Code:

#include <stdio.h>
#include <stdlib.h>

typedef struct
{
	int some_data;
} LIST;


int main(void)
{
	LIST* item;
        LIST* item2;

	item = malloc(sizeof(LIST));

	item->some_data = 33; 

	printf("some_data = %d\n", item->some_data);
	
	free(item); 

        item2 = malloc(sizeof(*item2));
        item2->some_data = 42;

	printf("some_data = %d\n", item->some_data);   // should I still be able to access this after the free?

	return 0;
}

is almost guaranteed to produce the output of:

Code:

some_data = 33
some_data = 42

I say almost guarnteed, because there is no guarantees as to what happens when you allocate another block of the same size that you just freed - the most common scenario is that the last freed block is used.

[1] I just wrote that article on cpwiki. If anyone fancies enhancing or extending it [it could get VERY long], feel free.

--
Mats

This is also why it's custom to set a pointer to NULL after freeing it so you know it's freed.

Originally Posted by reversaflex

JDGATX I guess you got what I think is the desired behaviour, thanks for checkin that out!

If you do the same on a Visual Studio Debug build, you will get a HUGE integer (possibly huge negative) value back from your freed memory, because the runtime library fills the freed memory with a special value to indicate it's been freed. (I think it's 0xDFDFDFDF - which is minus a few billion or as an integer). It appears that JDGATX's build fills that part of memory with the value zero - whether that applies to ALL of the freed memory or just the first 4 bytes or so is another question.

But it's undefined as far as the C standard is concerned, and as such, there is absolutely no telling what happens [including a possible crash].

--
Mats

If we want to be correct, it may work and it may not. If all data within the page has been previously freed (or not allocated at all) and when you free the rest of the data inside the page, it will get unloaded from the process and you'll get an access violation (because the process won't have access to the page anymore).
However, the process may still have data still allocated within said page, which means it will still be able to access and write to the location. So, it's undefined behavior.
Curious about virtual memory? Have a look at cpwiki's virtual memory article.

Originally Posted by Elysia

If we want to be correct, it may work and it may not. If all data within the page has been previously freed (or not allocated at all) and when you free the rest of the data inside the page, it will get unloaded from the process and you'll get an access violation (because the process won't have access to the page anymore).
However, the process may still have data still allocated within said page, which means it will still be able to access and write to the location. So, it's undefined behavior.
Curious about virtual memory? Have a look at cpwiki's virtual memory article.

<pedant>As discussed in a previous thread, the malloc/free functions are optimized, so the system will not free the memory back to the OS unless it REALLY thinks there is a huge gain (e.g. you have freed many megabytes of memory in consecutive pages). So even if you free every memory allocation on a particular page, it's unlikely that it leads to an access violation later on</pedant>

--
Mats