CODEWITHSUNDEEP
cmemory-managementmallocfree
sof
sof

Reputation: 9649

Improper freeing of the heap aborts C program

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?

Upvotes: 2

Views: 779

Answers (5)

paxdiablo
paxdiablo

Reputation: 881293

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.

Upvotes: 0

No name is fine too
No name is fine too

Reputation: 3

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.

Upvotes: 0

octopusgrabbus
octopusgrabbus

Reputation: 10685

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.

Upvotes: 1

Mat
Mat

Reputation: 206689

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.

Upvotes: 1

ugoren
ugoren

Reputation: 16441

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.

Upvotes: 3

Related Questions