What happens when you try to free() already freed memory in c?

Question

For example:

char * myString = malloc(sizeof(char)*STRING_BUFFER_SIZE);
free(myString);
free(myString);

Are there any adverse side effects of doing this?

score 41 · Accepted Answer · answered Sep 26 '08 at 04:59

41

Here's the chapter and verse.

If the argument [to the free function] does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined. (ISO 9899:1999 - Programming languages — C, Section 7.20.3.2)

answered Sep 26 '08 at 04:59

Chris Conway

55,321
43
129
155

13

FYI: When C or C++ say "undefined" they usually mean "crash" or "memory corruption" or something equally terrible. Beware. – Orion Edwards Mar 02 '09 at 02:43
15

No, they really do mean "undefined." That just happens to include crashes and memory corruption. – Chris Conway Mar 02 '09 at 17:23
12

@OrionEdwards The compiler could, for example, decide to launch NetHack. – remmy Apr 19 '14 at 12:03

score 20 · Answer 2 · answered Sep 25 '08 at 19:33

20

One of nothing, silent memory corruption, or segmentation fault.

answered Sep 25 '08 at 19:33

mbac32768

11,453
9
34
40

Segfaults happen when you access memory that is out of bounds. – May 19 '16 at 06:43

score 14 · Answer 3 · answered Sep 25 '08 at 19:33

14

Yes, you can get a double free error that causes your program to crash. It has to do with malloc's internal data structures to keep track of allocated memory.

answered Sep 25 '08 at 19:33

jbleners

1,023
1
8
14

score 9 · Answer 4 · edited Oct 24 '08 at 06:09

9

Answer summary:

Yes, bad things can and probably will happen.

To prevent this do:

free(myString);
myString = NULL;

Note that all references to the memory must be set to NULL if others were created.

Also, calling free() with a NULL results in no action. For more info see: man free

edited Oct 24 '08 at 06:09

Jonathan Leffler

730,956
141
904
1,278

answered Sep 25 '08 at 19:44

lillq

14,758
20
53
58

Note that if you have made any copies of the pointer those should be set to NULL as well. – Michael Carman Sep 25 '08 at 22:55
Seems like the community is leaning more towards putting answer summaries in the actual question, not as a question that is still buried... – PhirePhly Sep 26 '08 at 05:36
Bad idea, since it's not applicable to const values. You do use const values where possible, don't you? – Steve Jessop Nov 30 '08 at 14:47

score 6 · Answer 5 · answered Sep 25 '08 at 19:34

6

Not so clever. Google for double free vulnerabilities. Set your pointer to NULL after freeing to avoid such bugs.

answered Sep 25 '08 at 19:34

Armin Ronacher

31,998
13
65
69

Unfortunately you can't write a wrapper to free that does this for you, the pointer is passed by value not reference. i.e. Free(void **p) {free(*p); *p = NULL;} This is not as easy to retool code with. – jbleners Sep 25 '08 at 19:40
ajbl, use a macro. #define freep(x) (free(x); x = 0;) – Derek Park Sep 25 '08 at 19:46
Bad idea, since it's not applicable to const values. You do use const values where possible, don't you? – Steve Jessop Nov 30 '08 at 14:47
@Steve: I know this is old, but didn't we elsewhere discuss that passing a const-qualified pointer to `free` is not valid (both conceptually and formally, unless you cast away the qualifier)? :-) – R.. GitHub STOP HELPING ICE Sep 06 '11 at 04:05
@R..: I'm talking about `char *const ptr = malloc(STRING_BUFFER_SIZE); ... ; free(ptr);`. I don't think that is either formally or conceptually invalid. After that, `ptr = 0;` isn't on the cards. So if you define a macro `freep` as Derek says, then you can't use it on `ptr`. – Steve Jessop Sep 06 '11 at 07:22

score 6 · Answer 6 · answered Aug 28 '11 at 19:35

6

It (potentially) makes demons fly out of your nose.

answered Aug 28 '11 at 19:35

Jens

69,818
15
125
179

score 5 · Answer 7 · answered Sep 25 '08 at 19:33

5

Depending on which system you run it on, nothing will happen, the program will crash, memory will be corrupted, or any other number of interesting effects.

answered Sep 25 '08 at 19:33

John Millikin

197,344
39
212
226

score 3 · Answer 8 · edited Oct 24 '08 at 06:10

3

Always set a pointer to NULL after freeing it. It is safe to attempt to free a null pointer.

It's worth writing your own free wrapper to do this automatically.

edited Oct 24 '08 at 06:10

Jonathan Leffler

730,956
141
904
1,278

answered Sep 25 '08 at 19:36

Martin Beckett

94,801
28
188
263

Your free() wrapper must either be a macro or must use a different interface from the standard free() function. – Jonathan Leffler Oct 24 '08 at 06:11

score 3 · Answer 9 · answered Sep 25 '08 at 19:38

3

Bad Things (TM)

Really, I think it's undefined so anything at all including playing "Global Thermonuclear War" with NORAD's mainframe

answered Sep 25 '08 at 19:38

BCS

75,627
68
187
294

score 2 · Answer 10 · answered Sep 25 '08 at 19:33

2

Don't do that. If the memory that got freed is re-allocated to something else between the calls to free, then things will get messed up.

answered Sep 25 '08 at 19:33

Khoth

13,068
3
28
27

2

Things will usually be messed up even if the memory is not reallocated between the two calls to free. – Jonathan Leffler Oct 24 '08 at 06:09

score 1 · Answer 11 · answered Sep 25 '08 at 19:42

It may crash your program, corrupt memory, or have other more subtle negative effects. After you delete memory, it is a good idea to set it to NULL (0). Trying to free a null pointer does nothing, and is guaranteed to be safe. The same holds true for delete in c++.

score 1 · Answer 12 · answered Sep 26 '08 at 04:43

1

In short: "Undefined Behavior".

(Now, what that can include and why that is the case the others have already said. I just though it was worth mentioning the term here as it is quite common).

answered Sep 26 '08 at 04:43

Christian.K

47,778
10
99
143

Google for 'nasal demons' to find out more. – Jonathan Leffler Oct 24 '08 at 06:13

score 1 · Answer 13 · answered Sep 28 '08 at 03:35

1

The admittedly strange macro below is a useful drop-in replacement for wiping out a few classes of security vulnerabilities as well as aid debugging since accesses to free()'d regions are more likely to segfault instead of silently corrupting memory.

#define my_free(x) do { free(x); x = NULL; } while (0)

The do-while loop is to help surrounding code more easily digest the multiple-statements. e.g. if (done) my_free(x);

answered Sep 28 '08 at 03:35

mbac32768

11,453
9
34
40

Wouldn't "#define my_free(x) { free(x); x = NULL; }" work just as well? – Graeme Perrow Sep 28 '08 at 03:54
No, after expansion there's an illegal semicolon in if (done) {free(x); x=NULL}; else do_more(); Good luck finding the "else without matching if" error in your original source. – MSalters Oct 03 '08 at 15:46
C has the comma operator for a reason. `#define my_free(x) (free((x)),(x)=0)` – R.. GitHub STOP HELPING ICE Feb 26 '11 at 04:26

score -1 · Answer 14 · answered Aug 26 '10 at 13:07

Another interesting situation:

char * myString = malloc(sizeof(char)*STRING_BUFFER_SIZE);
char * yourString = myString;

if (myString)
{
    free(myString);
    myString = NULL;
}
// Now this one is safe, because we keep to the rule for 
// setting pointers to NULL after deletion ...
if (myString)
{
    free(myString);
    myString = NULL;
}

// But what about this one:
if (yourString)
{
    free(yourString);
    yourString = NULL;
}

//?!? :)

What happens when you try to free() already freed memory in c?

14 Answers14

Linked

Related