memory corruption

问题:

i was running a small c program:

#include<stdio.h>
int main()
{
char *p;
p = (char *)malloc(10);
free(p);
free(p);
free(p);
printf("\npointer is freed!!\n");
}

basically i am freeing the memory which has already been freed. i think should result in a core dump!!is it not so?

but it is printing the

pointer is freed!!

am i wrong some where?

回答1:

As per the man page, "if free(ptr) has already been called before, undefined behavior occurs."

It doesn't need to blow up; "not doing anything" is perfectly acceptable undefined behaviour. Also are nasal demons. Don't rely on it.

回答2:

There are multiple issues with your program:

1. Since you're using malloc() and free(), you should do #include <stdlib.h> before calling any of those functions.
2. There's no need to cast the return value from malloc(): it returns a void *, which can be assigned to any other pointer type safely (except function pointers). So, you can do: p = malloc(10);
3. Once you free a pointer allocated by malloc() or realloc(), using the pointer value in any way is bad: in particular, you cannot call free() on it again.
4. int main() is better written as int main(void).
5. Since main() returns int, you should return a value from it. Traditionally, 0 means success.

Of course, the main (no pun intended) problem with your program is freeing it many times, but other issues mentioned above are important too. Once you've free()'d a pointer successfully, calling free() on it is undefined behavior: the program can do anything, including (unfortunately), seeming to not do anything bad. I say "unfortunately" because it might give you a sense of security that it's okay to free() a pointer more than once.

回答3:

Just to add to the other answers, I'd like to note that if you set the pointer to NULL and then called free(), the behaviour wouldn't be undefined anymore. It's pretty much a no-op. However, if the pointer is freed and you call free() on it again before assigning the pointer to a different location (even NULL), you can't be sure of what happens. It could result in a core dump on some implementations and nothing would happen on some others.

回答4:

freeing already freed memory, leads to undefined behavior, you got lucky, in this case, on other times you might get your core-dump

回答5:

It depend on the implementation of your OS (linux, windows...) who implement this function. Their behaviors may be different depending on the OS (undefined behavior), so you must not rely on them and you must free only one time all allocated memory in you program.

EDIT: it is not part of the OS but of the standard library which differ depending on the OS.

回答6:

I would expect DEBUG builds of most compilers to be able to detect this type of a failure and report exactly what happened. So would MSVC do.

In RELEASE, it could be optimized to generate unpredictable behavior faster.

回答7:

Heap corruption need not cause the problem immediately. It could so happen that the freed memory ( or part of the memory) is used to allocat some other structure and then it might cause problem. freeing memory more than once is always UB (undefined) and should not be done even if you don't see evil effects at that moment.