Is there a difference between setting a pointer to NULL before and after allocating it?
For example, is there any difference between
char* c = NULL;
and
char* c = malloc(sizeof(char));
c = NULL;
What are the, if any, implications of each of those statements, and is there any difference in calling free(c) in each of those situations?
Let's look at the two cases.
Case 1: Before malloc
Well, there's almost no harm done here. Unless the pointer was pointing to something before, the pointer is simply set to NULL and points to nothing. Calling free() on a pointer that points to nothing does nothing. "Free the people?" Okay. "Free the free?" You can't really free something that's already sort of "free." No stranger, no danger. Moving on...
Case 2: After malloc
Let's break it down:
char* c = malloc(sizeof(char));
c = NULL;
The first command will reserve memory from the operating system for your program. That's dynamic allocation--getting more memory on the fly.
The second command sets your pointer to NULL. What does that mean?
Memory leak. That means your program has basically borrowed memory from the operating system and forgot about it. This is a big no-no. If a program keeps doing it over and over, they will eventually crash (or the entire system will crash).
Just like how you should always return things to friends, you should always return memory to the operating system. Therefore, you must always call free() for every point you malloc(); just like opening and closing brackets (), [], or {} in C or C++.
Never set a pointer to NULL until after you free() the memory associated with it.
Before allocating it, it might have (depending on where it was declared) garbage data in it. By assigning it to null before, you basically assure it is in a known good state.
After allocating and assigning the address to a variable, setting the pointer to null means that the pointer will no longer reference the allocated memory. Normally this creates a memory leak (a bit of allocated memory that cannot be referenced anymore, and so it cannot be freed). However there are times were this is appropriate. For example, if your logic has two references to the memory, one for allocation / deallocation purposes and one for "current item of interest" it might be appropriate to assign the current item of interest and then assign null to it as this "current item of interest" pointer is not related to memory allocation and deallocation.
Finally, if it is a pointer to be used for deallocation, after you free() the pointer, you might want to then set the pointer to null for the same reasons you set the pointer to null prior to allocation (to make sure that your program doesn't get confused by finding an address value in the pointer when that's not memory you want accessed).
Yes there's a difference. The second one causes a memory leak.
As to your second question, if c = NULL, then free(c) will have no effect.
You're not setting the allocated memory to NULL, you're setting the pointer to NULL so that it no longer points to the memory that you allocated. When you call free on it, you're not freeing the memory that you allocated, since the pointer doesn't point to it.
This is called a memory leak: you've allocated some memory, but you no longer have a pointer to it so you can't free it, so the memory will remain "in use" and unavailable to other programs even though you're not actually using it anymore.
Calling free on a NULL pointer has no effect.
Related
I am Confused and thinking about Free Pointer in Following way , can someone clarify
I always thought that the free function just removes the address stored in the pointer, hence breaking the connection between the pointer and the space allocated for block. At the end making the values at the space a garbage value and hence making it virtually free to use by another program.
Please specify the reason why I am wrong.
Also, What happens when you point two pointers to a single space allocated
and Try to free them both? Does it Gives a compilation Error / Run Time Error?
free(ptr) de-allocates the memory block pointed to by its argument ptr, that is it returns the block to the free pool. Consecutive calls to malloc() may use that memory, re-allocating it for another purpose.
However, free() receives its argument as a copy, that is it gets the value from the ptr variable, not the variable itself. As a result it can't 'clear the pointer'. If you expect the ptr variable becomes NULL, you're wrong. That's a common mistake. You should assign ptr = NULL yourself after free() to make sure the variable value becomes unusable.
As for the memory block itself: free() is not obliged to 'make it garbage' or clear it. You can try accessing the freed memory by the same pointer, and often you will see the previous content still present there.
But don't rely on it! The memory can be reallocated for another purpose almost any time (the freed memory might even become unavailable for the process), so fiddling with it may invoke unpredictable results (so-called Undefined Behavior).
An attempt to deallocate a block twice (i.e. a second free() with the same pointer) is UB, too.
I have been taught in lectures, that calling free() on a pointer twice is really, really bad. I know that it is good practice, to set a pointer to NULL, right after having freed it.
However, I still have never heard any explanation as to why that is. From what I understand, the way malloc() works, it should technically keep track of the pointers it has allocated and given you to use. So why does it not know, whether a pointer it receives through free() has been freed yet or not?
I would love to understand, what happens internally, when you call free() on a location that has previously already been freed.
When you use malloc you are telling the PC that you want to reserve some memory location on the heap just for you. The computer gives back a pointer to the first byte of the addressed space.
When you use free you are actually telling the computer that you don't need that space anymore, so it marks that space as available for other data.
The pointer still points to that memory address. At this point that same space in the heap can be returned by another malloc call. When you invoke free a second time, you are not freeing the previous data, but the new data, and this may not be good for your program ;)
To answer your first question,
So why does it not know, whether a pointer it receives through free() has been freed yet or not?
because, the specification for malloc() in C standard does not mandate this. When you call malloc() or family of functions, what it does is to return you a pointer and internally it stores the size of the memory location allocated in that pointer. That is the reason free() does not need a size to clean up the memory.
Also, once free()-d, what happens with the actually allocated memory is still implelentation dependent. Calling free() is just a marker to point out that the allocated memory is no longer in use by the process and can be reclaimed and e re-allocated, if needed. So, keeping track of the allocated pointer is very needless at that point. It will be an unnecessary burden on the OS to keep all the backtracks.
For debugging purpose, however, some library implementations can do this job for you, like DUMA or dmalloc and last but not the least, memcheck tool from Valgrind.
Now, technically, the C standard does not specify any behaviour if you call free() on an already free-ed pointer. It is undefined behavior.
C11, chapter ยง7.22.3.3, free() function
[...] if
the argument does not match a pointer earlier returned by a memory management
function, or if the space has been deallocated by a call to free() or realloc(), the
behavior is undefined.
C standard only says that calling free twice on a pointer returned by malloc and its family function invoke undefined behavior. There is no further explanation why it is so.
But, why it is bad is explained here:
Freeing The Same Chunk Twice
To understand what this kind of error might cause, we should remember how the memory manager normally works. Often, it stores the size of the allocated chunk right before the chunk itself in memory. If we freed the memory, this memory chunk might have been allocated again by another malloc() request, and thus this double-free will actually free the wrong memory chunk - causing us to have a dangling pointer somewhere else in our application. Such bugs tend to show themselves much later than the place in the code where they occured. Sometimes we don't see them at all, but they still lurk around, waiting for an opportunity to rear their ugly heads.
Another problem that might occure, is that this double-free will be done after the freed chunk was merged together with neighbouring free chunks to form a larger free chunk, and then the larger chunk was re-allocated. In such a case, when we try to free() our chunk for the 2nd time, we'll actually free only part of the memory chunk that the application is currently using. This will cause even more unexpected problems.
When you are calling malloc you are getting a pointer. The runtime library needs to keep track of the malloced memory. Typically malloc does not store the memory management structures separated from the malloc ed memory but in one place. So a malloc for x bytes in fact takes x+n bytes, where one possible layout is that the first n bytes are containing a linked list struct with pointers to the next (and maybe previous) allocated memory block.
When you free a pointer then the function free could walk through it's internal memory management structures and check if the pointer you pass in is a valid pointer that was malloced. Only then it could access the hidden parts of the memory block. But doing this check would be very time consuming, especially if you allocate a lot. So free simply assumes that you pass in a valid pointer. That means it directly access the hidden parts of the memory block and assumes that the linked list pointers there are valid.
If you free a block twice then you might have the problem that someone did a new malloc, got the memory you just freed, overwrites it and the second free reads invalid pointers from it.
Setting a freed pointer to NULL is good practice because it helps debugging. If you access freed memory your program might crash, but it might also just read suspicious values and maybe crash later. Finding the root cause then might be hard. If you set freed pointers to NULL your program will immediately crash when you try to access the memory. That helps massively during debugging.
So I was reading through some code for a class and I am a little confused about how variable's are deallocated in C.
The code given is
#include<stdio.h>
main () {
int n=0;
char *p = "hello world";
while (*p!= 0) { // *p != '\0';
putc(*p, stdout);
p++;
}
printf("\np = %d", *p);
printf("\np = %d\n", p);
}
So i get that you don't need to free any memory for the char* since no mallocs are happening but i don't get why this code wouldn't leak any memory... If you are incrementing a pointer for a string and thus moving pointer to the next block of memory (1byte) then aren't you losing the initial reference and all reference points that you increment over? How would would this memory be reclaimed without a reference point, unless one is saved by the compiler before this type of operation occurs. I would appreciate some insight on how this is being reclaimed!
The task of deallocating memory is imposed on the owner of that memory. Just because you have a pointer to some memory region does not mean that you own that memory and, therefore, does not mean that you are responsible for deallocating it.
String literal "hello world" is an object with static storage duration. It is stored in static memory. Static memory is always owned by the runtime environment. The runtime environment is aware of data stored in static memory. The runtime environment knows when that data has to be deallocated (which is easy, since static memory is basically "never" deallocated - it exists as long as your program runs).
So, again, you with your pointer p do not really own any memory in static region. You just happen to refer to that memory with your p . It is not your business to worry about deallocation of that memory. It will be properly deallocated when the time comes (i.e. when the program ends) and it will be done properly without any help from you and your pointer p. You can change your p as much as you want, you can make it point to a completely different memory location, or you can discard it without any reservations. Speaking informally, nobody cares about your p.
The only memory you can possibly own in a C program is memory you personally allocated with malloc (or other dynamic memory allocation functions). So, you have to remember to eventually call free for the memory that you allocated yourself (and you have to make sure you know the original value returned by malloc to pass to that free). All other kinds of memory (like static or automatic) are never owned by you, meaning that freeing it is not your business and preserving the original pointer values is completely unnecessary.
You aren't leaking any memory because you are not dynamically allocating any memory. Memory leaks come from not freeing dynamically allocated memory. Locally allocated memory (like char *p) or statically allocated memory (like the string "hello world" that p initially points at) cannot contribute to leaks.
You are not dynamically allocating any new memory, hence you do not need to free it.
The string literal "hello world" is an object which is part of the program itself. When the "hello world" expression is evaluated, the program essentially obtains a pointer to a piece of itself. That memory cannot be deallocated while the program is running; that would be equivalent to making a "hole" in the program. The memory has the same lifetime as the program itself.
In the C language, the programmer is not required to manage memory which has the same lifetime as the program: this is externally managed (or mismanaged, as the case may be) by the environment which starts the program, and deals with the aftermath when the program terminates.
Of course, the memory still has to be managed; it's just that the responsibility does not lie with the C program. (At least, not in an environment which provides a hosted implementation of the C language. The rules for some embedded system might be otherwise!)
In a program that is embedded, the string literal (along with the rest of the program) could actually live in ROM. So there might really be nothing to clean up. The pointer is an address which refers to some permanent location on a chip (or several chips).
In short: because the program itself is short. You could be doing any malloc you want in there, and no leaks would actually happen, since all the memory is handed back to the OS as soon as the process ends. A leak would not be an issue in your example. Anyway,
in your case, a leak is not happening, because the variable p is pointing to a literal string, which is located in the data segment of the memory (i.e. it is a constant, written in the executable). This kind of memory cannot be de-allocated, because its space is fixed.
Actually, it is false that this is not a problem, because a very big executable, with lots of big constants in it, could have a remarkable memory footprint, but anyway this is not called a leak, because memory usage may be big, but it does not increase over time, which is the main point of a memory leak (hence the name leak).
When you declare your variables locally, the compiler knows how much space is required for each variable and when you run your program, each local variable (and also each function call) is put on stack. Just after return statement (or } bracket if void function) each local variable is popped from stack, so you don't have to free it.
When you call new operator (or malloc in pure C), the compiler doesn't know the size of the data, so the memory is allocated runtime on heap.
Why I'm explaining this is fact that whenever you call new or malloc (or calloc), it's your responsibility to free memory you don't want to use anymore.
In addition to the other answers, incrementing a pointer in C doesn't create or lose "references", nor does it cause any copying or other altering of the memory that the pointer points to. The pointer in this case is just a number that happens to point to a statically allocated area of memory.
Incrementing the pointer doesn't alter the bytes that the pointer used to point to. The "H", is still there. But the program now thinks that the string starts with "e". (It knows where the end of the string is because by convention strings in C end with a null.
There are no checks that the pointer points to what you think it should, or any valid area at all. The program itself could lose track of an area of memory (for instance if you set p=0), or increment p beyond the end of the string, but the compiler doesn't keep track of this (or prevent it), and it doesn't de-allocate the memory used for the string.
If you change the pointer to point to the "wrong" location in memory, fun (bad) things will happen - such as page faults, stack overflows and core dumps.
I am struggling to wrap my head around malloc in c - specifically when it needs to be free()'d. I am getting weird errors in gcc such as:
... free(): invalid next size (fast): ...
when I try to free a char pointer. For example, when reading from an input file, it will crash on certain lines when doing the following:
FILE *f = fopen(file,"r");
char x[256];
while(1) {
if(fgets(x,sizeof x,f)==NULL) break;
char *tmp = some_function_return_char_pointer(x); //OR malloc(nbytes);
// do some stuff
free(tmp); // this is where I get the error, but only sometimes
}
I checked for obvious things, such as x being NULL, but it's not; it just crashes on random lines.
But my REAL question is - when do I need to use free()? Or, probably more correctly, when should I NOT use free? What if malloc is in a function, and I return the var that used malloc()? What about in a for or while loop? Does malloc-ing for an array of struct have the same rules as for a string/char pointer?
I gather from the errors I'm getting in gcc on program crash that I'm just not understanding malloc and free. I've spent my quality time with Google and I'm still hitting brick walls. Are there any good resources you've found? Everything I see says that whenever I use malloc I need to use free. But then I try that and my program crashes. So maybe it's different based on a variable's scope? Does C free the memory at the end of a loop when a variable is declared inside of it? At the end of a function?
So:
for(i=0;i<100;i++) char *x=malloc(n); // no need to use free(x)?
but:
char *x;
for(i=0;i<100;i++) {
x=malloc(n);
free(x); //must do this, since scope of x greater than loop?
}
Is that right?
Hopefully I'm making sense...
malloc() is C's dynamic allocator. You have to understand the difference between automatic (scoped) and dynamic (manual) variables.
Automatic variables live for the duration of their scope. They're the ones you declare without any decoration: int x;
Most variables in a C program should be automatic, since they are local to some piece of code (e.g. a function, or a loop), and they communicate via function calls and return values.
The only time you need dynamic allocation is when you have some data that needs to outlive any given scope. Such data must be allocated dynamically, and eventually freed when it is no longer necessary.
The prime usage example for this is your typical linked list. The list nodes cannot possibly be local to any scope if you are going to have generic "insert/erase/find" list manipulation functions. Thus, each node must be allocated dynamically, and the list manipulation functions must ensure that they free those nodes that are no longer part of the list.
In summary, variable allocation is fundamentally and primarily a question of scope. If possible keep everything automatic and you don't have to do anything. If necessary, use dynamic allocation and take care to deallocate manually whenever appropriate.
(Edit: As #Oli says, you may also want to use dynamic allocation in a strictly local context at times, because most platforms limit the size of automatic variables to a much smaller limit than the size of dynamic memory. Think "huge array". Exceeding the available space for automatic variables usually has a colourful name such as "pile overrun" or something similar.)
In general, every call to malloc must have one corresponding call to free.* This has nothing to do with scope (i.e. nothing to do with functions or loops).
* Exceptions to this rule include using functions like strdup, but the principle is the same.
Broadly speaking, every pointer that is ever returned by malloc() must eventually be passed to free(). The scope of the variable that you store the pointer in does not affect this, because even after the variable is no longer in scope, the memory that the pointer points to will still be allocated until you call free() on it.
Well, the scope of the malloc'd memory lays between calls to malloc and free or otherwise until process is stopped (that is when OS cleans up for the process). If you never call free you get a memory leak. That could happen when address that you can pass to free goes out of scope before you actually used it - that is like loosing your keys for the car, car is still there but you can't really drive it. The error you are getting is most likely either because function returns a pointer to some memory that was not allocated using malloc or it returns a null pointer which you pass to free, which you cannot do.
You should free memory when you will no longer be accessing it. You should not free memory if you will be accessing it. This will give you a lot of pain.
If you don't want memory leak, you have to free the memory from malloc.
It can be very tricky. For example, if the // do some stuff has a continue, the free will be skipped and lead to memory leak. It is tricky, so we have shared_ptr in C++; and rumor has it salary of C programmer is higher than C++ programmer.
Sometimes we don't care memory leak. If the memory holds something that is needed during the whole lifetime of execution, you can choose not to free it. Example: a string for environment variable.
PS: Valgrind is a tool to help detect memory bugs. Especially useful for memory leak.
malloc(n) allocates n bytes of memory from a memory location named heap and then returns a void* type of pointer to it. The memory is allocated at runtime. Once you have allocated a memory dynamically, scope does not matter as long as you keep a pointer to it with you(or the address of it specifically). For example:
int* allocate_an_integer_array(int n)
{
int* p = (int*) (malloc(sizeof(int)*n));
return p;
}
This functions simply allocates memory from heap equal to n integers and returns a pointer to the first location. The pointer can be used in the calling function as you want to. The SCOPE does not matter as long as the pointer is with you..
free(p) returns the memory to heap.
The only thing you need to remember is to free it as if you don't free it and lose the value of its address, there will bw a memory leak. It is so because according to OS, you are still using the memory as you have not freed it and a memory leak will happen..
Also after freeing just set the value of the pointer to null so that u don't use it again as the same memory may be allocated again at any other time for a different purpose....
So, all you need to do is to be careful...
Hope it helps!
When malloc is called, the size is stored adjacent to the allocated block so that free will know how much to free etc ( http://c-faq.com/malloc/freesize.html ).
My question is, Say we have dynamically allocated memory and later in the code we increment the pointer
pointer++
And then later, if i call a
free(pointer)
what memory does actually get freed up.
Is it number of allocated bytes starting from the current address pointed by 'pointer' or from the base address to which it has been allocated.
You need to free() the same pointer as you received from malloc(). Incrementing, altering or changing it is undefined behaviour, that is usually a segmentation fault.
Think of the pointer you receive as a book from a library. You get home and read it. Afterwards you remove the front page and the book's back and hand it back to the librarian. Will he accept it or are you in serious trouble now? ;-)
You can only call free() on a value that you previously obtained from malloc(), calloc(), or realloc() (or NULL). Everything else is undefined.
For example, an implementation might store the size of the allocated block in 4 bytes before the return address from malloc(). Then, free() goes back 4 bytes and finds out the size. This wouldn't work if you don't pass the original pointer back to free().
It will cause undefined behavior. Most likely it will crash your program either instantly or later.
That's undefined behavior. And it will most probably results in problem later on.
If you increment the pointer without saving the original malloced location you can't call free on it. You have to save the original location somewhere and use a temporary point when you increment.
doing pointer++ to original pointer is terribly wrong. result of freeing it may be different on different implementations, but you definitely shouldn't do it.
The code managing the free storage just assumes that you wouldn't hand it the wrong pointer. It takes whatever you give, doesn't check its plausibility, and interprets it the same way it would interpret the right pointer. It will act according to whatever values it reads from whatever memory locations it looks at assuming the pointer was rightfully obtained. If you handed it a stray pointer, it will find nonsensical values and thus act nonsensical.
This is called undefined behavior and it's a mean thing. It might format your hard drive, toast your CPU, or make your program seemingly work the way it is expected to until you retire. You never know.
This is what we call a memory leak/segmentation fault.
You HAVE to pass the same pointervalue to free() as the one you got from malloc() or your application will misbehave/crash.
The pointer returned by malloc() points directly to the memory on the heap that will be used by your program.
However, this isn't the only memory that's allocated. A few bytes are allocated in the memory locations immediately preceding the pointer returned that indicate the size of the chunk on the heap. This isn't used by your program, but it will definitely be needed by free.
When free(p) is called, the information about its chunk on the heap is contained in, say, the locations from p-4 through p-1. This depends on implementation of course, but the details need not concern the programmer. The only thing that the programmer needs to know is that free uses that area of memory to free the chunk of memory from the heap, and that area is derived from the original pointer p.
In other words, if you call free on p, it will only make sense if malloc once returned exactly p.
If you pass in a pointer that wasn't created with malloc, who knows what will lie at p-1, p-2, etc.? It will probably result in a catastrophic failure.