double free

[weaselboy1976]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

Also, if you know of any really good books that describe everything
about memory in a c program ...

Thanks in advance!

 

[Case -]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

You could search for free source files of malloc() and free().
Studying these files, will give you detailed insight in what
the effects are of multiple free-ing the same block.

In short what happens when you free() a block more than once,
is mixing up the internal block administration of the C memory
allocaton library. If you've ever worked on dynamic data
structures, like lists or trees, you probably know what I'm
talking about.

Also, if you know of any really good books that describe everything
about memory in a c program ...

There's the C-faq online, and I think any book on C. A book that
does not cover this, is not a C book.

Case

 

[Alan Balmer]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

You probably won't find such a site, because the effects are
implementation dependent. On at least some implementations, it can
corrupt the heap.

Also, if you know of any really good books that describe everything
about memory in a c program ...

Same problem - dependent on architecture and runtime implementation.

Thanks in advance!

Obviously the proper way to handle freeing a pointer more than once is
"Don't do it!" If you have a reason to know the effects on a
particular implementation, you need to find a newsgroup or other
source of information which deals with that particular implementation,
because it will be off-topic here.

 

[jacob navia]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

Also, if you know of any really good books that describe everything
about memory in a c program ...

Thanks in advance!

I assume that in all implementations where
free checks if the address is *already* in the free list
nothing serious can happen.

In all others, there is a block twice in the free list,
that can later be allocated twice to the program
again. Unrelated data items will have the same
address and when you write into one you corrupt the
other.

This can go unnoticed for years or provoke
a crash immediately. It depends on which blocks
are used where, etc.

Depending on the algorithm used by free, the
free list could become corrupted when inserting
a block that is already there.

To avoid this, and other catastrophes that may fall into you
use a garbage collector. The machine takes care of
freeing blocks regularly.

lcc-win32 offers a gc with its runtime.

 

[Emmanuel Delahaye]

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

The standard says that it is an undefined behaviour. That's all. Anything can
happen, ill or not.

Also, if you know of any really good books that describe everything
about memory in a c program ...

This is an implementation issue. The C langage isn't concerned by it. The
interface and the behaviour only matter.

 

[Eric Sosman]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

Others have mentioned the likelihood of corrupting
the data structures malloc() and friends use to keep track
of memory. But even if no such corruption occurs, it's
easy to see that trouble can ensue:

ptr1 = malloc(size); // suppose we get "Area A"
...
free (ptr1); // Area A ready for re-use
...
ptr2 = malloc(size); // suppose we get Area A again
...
free (ptr1); // second free(); Area A released
...
ptr3 = malloc(size); // acquire Area A a third time

Now you've got both ptr2 and ptr3 pointing to the same area
of memory. So when you do

strcpy (ptr2, "green"); // stores "green" in Area A
strcpy (ptr3, "red"); // overwrites it with "red"
printf ("Push the %s button immediately!\n",
emergency_in_progress() ? ptr3 : ptr2);

you will be responsible for the meltdown of the nuclear power
plant, and the subsequent release of radiation that mutates
your weaselly offspring into giant ferrets. Be warned!

 

[Alan Balmer]

I assume that in all implementations where
free checks if the address is *already* in the free list
nothing serious can happen.

What if the memory has been reallocated in the meantime?

 

[Richard Tobin]

You could search for free source files of malloc() and free().

Even better, you could try writing your own implementation -
mymalloc() and myfree() - allocating memory out of a block you get
from the real malloc(). You will quickly see various ways that things
can go wrong.

-- Richard

 

[Keith Thompson]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

Also, if you know of any really good books that describe everything
about memory in a c program ...

Section 7 of the C FAQ <http://www.eskimo.com/~scs/C-faq/top.html> is
pretty good. Any decent C textbook should also give you a good
description.

Quick answer: Once you've passed a pointer to free(), its value
becomes invalid. Doing anything with that value, including passing it
to free() again, invokes undefined behavior, with arbitrarily bad
results. (Even if it didn't, it would probably indicate a flaw in
your program; if you've already freed the pointer, why do it again?)

 

[Spacen Jasset]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

Also, if you know of any really good books that describe everything
about memory in a c program ...

Thanks in advance!

If we assume that the implementation uses a linked list, like many do, then
there are two immediate effects of a "double free" that spring to mind:

1) The allocator will read the block header and see that it is already freed
and either:
a) In debug mode fire off some sort of notification
b) Do nothing and return

2) The block will have been merged with a neighbouring free block and:
a) In debug mode will report and invalid memory block
b) Attempt to update the block allocation information, and either do
nothing or write allocation information to a free data area - which could
corrupt data if the merged block has already been re-allocated.

In short, many bad things can happen depending on how the allocator works.

Look for memory allocation algorithms on a search engine, or see Knuth, vol
1 for an idea of how memory allocaiton works.

 

[Idriz Smaili]

Hello

Does anyone know of a good website that actually describes and
demonstrates WHY freeing a pointer more than once is a problem. I'm
specifically interested in what the ill effects are.

Also, if you know of any really good books that describe everything
about memory in a c program ...

Thanks in advance!

Hi,

a trick is to initilize always all variables, even if they are pointers,
which means that:

type * p = 0;

if you thereafter allocate memory for p then the code should looks like:

p = (type *) malloc (sizeof (type));
^^^^^^^^ // is needed if C++ compiler is
// used
if (!p)
{
/* no memory was allocated */
/* handle the case here */
}

.....

if (p)
{
/* well, the pointer still points to a memory location */
/* therefore, the free has to be call */

free (p);

/* but, don't forget to reset p to 0 for further consistent
* checking
*/
p = 0;
}

Best wishes,
Idriz

 

[Keith Thompson]

type * p = 0;

That's valid, but most programmers find NULL clearer than 0.

if you thereafter allocate memory for p then the code should looks like:

p = (type *) malloc (sizeof (type));
^^^^^^^^ // is needed if C++ compiler is
// used

This has been discussed at length many times. Briefly, if you're
using a C compiler, casting the result of malloc() is useless and can
mask errors. If you're using a C++ compiler, you should be writing
C++, which generally means using operator new rather than malloc().
If you actually have a good reason to be writing code that will
compile as either C or C++, you're probably P.J. Plauger, and you
don't need advice from me.

The recommended idiom is:

p = malloc(sizeof *p);

which will continue to work even if you change the declaration of p so
it points to a different type.