Printable View
t014y says in the concurrent "link list math" thread that this compiles and executes without error on win XP:
What's the deal? I thought that kind of mistake would be Universally Impermissible?Code:#include <stdio.h>
#include <stdlib.h>
int main() {
void *ptr = malloc(666);
free(ptr);
puts("okay!");
free(ptr);
puts("okay!");
return 0;
}
It's undefined behavior. It may or may not crash or error or destroy your computer.
Maybe in debug mode free() checks a list of allocated pointers and only tries to free it if it's on that list?
i was told that if the pointer was pointing to 'NULL' then free() did nothing... not make the program crash. but i don't know that much.
but if that is true then you could free the same thing any amount of times without crashing the program... right?
Does ptr==NULL in that program? Never! I think my point is it's not your fault, t014y, that this twist has slipped by you if the compiler/OS, etc. let it.Quote:
Originally Posted by t014y
What will happen is that the memory pointed to by ptr is freed, returned back to a pool used by the compiler. But the actual value of ptr, which is that memory address, has not changed (it would if you set it to NULL). You, yourself, and I are free to use that address (since we have it in a variable, ptr) however we like. The problem will arise if you are freeing and allocating in a loop like this, because the compiler will probably stick the next instance of x into that (same size) block, then you "double free" it because you have TWO pointer variables containing the same address. Or -- if you try to realloc one of them when the other just freed -- you will have some similar complication.
Basically, double-freeing occurs when you've lost control of the memory and that is guaranteed to cause a problem sometime soon. In the example I gave, it's easy to get away with, because no more memory is ever allocated so the space is safe. But it shows you're not getting told what you should have been.
The only way ptr would be NULL in the above code is if malloc failed (or one of the standard functions in the code has been replaced by a macro or something is REALLY b0rkened somewhere in the C runtime library).Quote:
Originally Posted by t014y
It is most likely that whatever C runtime this is, it happens to work. Double free, after all, is undefined behaviour, not a "defined to crash".
Setting the pointer to NULL after free is definitely a good thing to do.
Double free can also cause problems later. For example, it may be that free is inserting into a linked list, and if the object has already been freed, it gets inserted twice. Guess what happens when you next ALLOCATE two blocks of that size? You get two pointers to the same bit of memory. Now try to debug why when you update ptr1, the values referenced by ptr2 that you allocated in a completely different place, is changing.... Nasty to figure that one out.
--
Mats
I actually spit an edit about this:Quote:
Originally Posted by matsp
quick like a bunny!Quote:
In the example I gave, it's easy to get away with, because no more memory is ever allocated so the space is safe. But it shows you're not getting told what you should have been.
Quote:
Setting the pointer to NULL after free is definitely a good thing to do.
That's the opposite of what should happen in debug mode. In debug mode, such things should be checked for, and the program should crash if it happens.Quote:
Originally Posted by cpjust
You should also crash if you write past the end of an array, but since VC++ (and maybe other compilers) add extra padding before and after stack variables in debug mode, you don't crash unless you write past the end of the array and the padding.Quote:
Originally Posted by brewbuck