Take the 2-minute tour ×

i was running a small c program:

int main()
char *p;
p = (char *)malloc(10);
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?

share|improve this question
add comment

7 Answers

up vote 7 down vote accepted

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.

share|improve this answer
A good way to prevent this from happening is free(ptr); ptr = NULL;, since free(NULL); is a no-op. Also, in OP's example malloc could've returned NULL. –  user142019 Jan 14 '12 at 14:48
add comment

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.

share|improve this answer
+1, nicely explained. –  Prasoon Saurav Dec 21 '09 at 6:38
A free() that never complains about double frees combined with a malloc() that always allocates the first free block is the perfect recipe for disaster. –  jbcreix Dec 21 '09 at 7:18
@jbcreix: That's a quality of implementation issue. On some systems, one might not want additional checks for double frees etc. On other systems/uses, it makes perfect sense for such checks. –  Alok Singhal Dec 21 '09 at 17:49
ad 3: That's what the OP is wonderig about: he uses it in a bad way, but nothing bad happens. ad 4: I disagree. main() usually has parameters; if you don't use them, () is better than (void). –  glglgl Feb 26 '13 at 10:34
@glglgl: the question is tagged c, which means that C rules apply. So, () is not better than (void). See securecoding.cert.org/confluence/display/seccode/… for example. –  Alok Singhal Feb 26 '13 at 17:09
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
I believe this question is not about heap corruption because the original poster does not try to use the pointer again. Instead, they are inquiring about calling free multiple times on the same pointer. –  antonm Dec 21 '09 at 6:57
Calling multiple free can result into heap corruption. It still answers the OP's question, I believe. Also, it need not be same pointer it is same memory which could be reused and can result into corruption. –  aJ. Dec 21 '09 at 7:03
Calling free multiple times on the same can cause heap corruption. –  caf Dec 21 '09 at 7:04
add comment

Your Answer


