Improper freeing of the heap aborts C program

Question

When trying to free either the same malloced heap twice or the unallocated heap, you get the fatal errors "double free or corruption(fasttop)" and "invalid pointer" respectively, hence the running program aborts immediately.

Although doing so is logically improper, it seems to me that no fatal harm is actually done to the running program. Why is it forced to abort immediately?

I'd prefer it this way to a silent ignore. If you're double-freeing memory then obviously something's going wrong and it would be nice to know what it is — Dan, Jan 29 '12 at 21:15
Should C have supported exception handling, i might prefer that a checked exception is thrown, which in turn the program itself need handle properly. — sof, Jan 29 '12 at 21:22
@sof, looking at this question & your comment on No name's answer, it seems to me that when you say "the unallocated heap" you mean a NULL pointer -- i.e. doing the equivalent of `free(NULL);` or `free(0);`. Is that the case or do you mean something different by 'unallocated heap'? — AAT, Jan 29 '12 at 21:54
No. `free(0)` does nothing at all. `heap=malloc(0); free(heap); free(++ heap)` results in "invalid pointer". — sof, Jan 29 '12 at 22:02

score 3 · Answer 1 · answered Jan 29 '12 at 21:20

An immediate abort maximizes the chances that you'll notice the error and fix it.
Errors of this sort can seem harmless, but with slight code changes, they're disastrous, and hard to debug.

Consider this - you (A) release pointer p, and after a while release it again. Meanwhile, some code (B) did malloc, and happened to get the same address. Now the second free will seem OK, because p is allocated. Now another someone (C) does malloc, and gets the same address again (quite likely, if it's the same size). When C writes to p, he's corrupting B's data. And who's to blame? A. Good luck debugging it.

So a double free should be caught when young, not tolerated.

score 1 · Answer 2 · answered Jan 29 '12 at 21:20

Nothing in the standard guarantees a crash. Doing a double-free is undefined behavior. It will get caught in some circumstances by the runtime library, which will then save you from further harm of your memory management bugs by killing you instantly.

But you can't rely on that. Various forms of silent, nasty heap corruption can occur without you noticing, and you'll be eating your data when that happens - not good.

The runtime gives you a safety net when it can, but don't rely on it. If you trip up on one of those, debug it until it is truely fixed.

score 1 · Answer 3 · answered Jan 29 '12 at 21:24

1

If you have good reason to allow behavior such as double freeing a pointer, than I suggest you have a look at implementing C exception handling using setjmp and longjmp, but from experience, I would be more inclined to eliminate logic like that.

answered Jan 29 '12 at 21:24

octopusgrabbus

10,555
15
68
131

1

There's no way to allow it. As soon as the double free occurs, you've invoked undefined behavior and the entire program state is undefined. – R.. GitHub STOP HELPING ICE Jan 29 '12 at 23:59

score 0 · Answer 4 · answered Jan 29 '12 at 21:31

Consider the following code:

    int * i = (int *)malloc(2 * sizeof(int));
    free(i);
    int * j = (int *)malloc(sizeof(int));
    int * k = (int *)malloc(sizeof(int));
    free(i);

Now, assume j holds the same address as i, and k holds i + 1. When the second free() is ordered you are declaring the whole block (j,k) free, and not just j (free() actually does know how much memory it has to declare free). This behaviour is understandably reprehensible because even though you might be done with j, you might get to use k in the remainder of the code.

After calling `free(heap)` we set `heap=NULL` by convention. Calling `free(heap)` again won't produce such side-effect. — sof, Jan 29 '12 at 21:45

score 0 · Answer 5 · answered Jan 29 '12 at 21:42

Although doing so is logically improper, it seems to me that no fatal harm is actually done to the running program.

Fallacy alert. Consider the following:

thread 1 allocates address 42 and write 'xyzzy' to it.
thread 1 frees address 42.
thread 2 allocates address 42 and write 'plugh' to it.
thread 1 erroneously frees address 42 again.
thread 3 allocates address 42 and write 'twisty-little-passages' to it.

Now threads 2 and 3 both think they own that memory. That's about as sustainable as my young son and daughter both thinking they own that latest toy purchased so, no, it's not going to end well :-)

Keep in mind, those "threads" alluded to don't have to be threads of execution in a multi-threaded environment, that's just a distinction I used to show ownership of the memory.

A good idiom for error handling is:

if you can fix it completely, do so.
if you can't fix it completely, stop as quickly as possible to minimise the damage.

Improper freeing of the heap aborts C program

5 Answers5