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 -]

Re: double free

weaselboy1976 wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
>
> Also, if you know of any really good books that describe everything
> about memory in a c program ...[/color]

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]

Re: double free

On 1 Jul 2004 11:27:36 -0700, weaselboy1976@y ahoo.com (weaselboy1976)
wrote:
[color=blue]
>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.[/color]

You probably won't find such a site, because the effects are
implementation dependent. On at least some implementations , it can
corrupt the heap.[color=blue]
>
>Also, if you know of any really good books that describe everything
>about memory in a c program ...
>[/color]
Same problem - dependent on architecture and runtime implementation.
[color=blue]
>Thanks in advance![/color]

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.

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[jacob navia]

Re: double free


"weaselboy1 976" <weaselboy1976@ yahoo.com> a écrit dans le message de
news:c76c305f.0 407011027.5749e 6d2@posting.goo gle.com...[color=blue]
> 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![/color]

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]

Re: double free

In 'comp.lang.c', weaselboy1976@y ahoo.com (weaselboy1976) wrote:
[color=blue]
> 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.[/color]

The standard says that it is an undefined behaviour. That's all. Anything can
happen, ill or not.
[color=blue]
> Also, if you know of any really good books that describe everything
> about memory in a c program ...[/color]

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

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Eric Sosman]

Re: double free

weaselboy1976 wrote:[color=blue]
> 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.[/color]

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_pr ogress() ? 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!

--
Eric.Sosman@sun .com

[Alan Balmer]

Re: double free

On Thu, 1 Jul 2004 21:50:57 +0200, "jacob navia"
<jacob@jacob.re mcomp.fr> wrote:
[color=blue]
>
>I assume that in all implementations where
>free checks if the address is *already* in the free list
>nothing serious can happen.[/color]

What if the memory has been reallocated in the meantime?

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Richard Tobin]

Re: double free

In article <40e45d05$0$623 76$5fc3050@drea der2.news.tisca li.nl>,
Case - <no@no.no> wrote:
[color=blue]
>You could search for free source files of malloc() and free().[/color]

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]

Re: double free

weaselboy1976@y ahoo.com (weaselboy1976) writes:[color=blue]
> 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 ...[/color]

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?)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Spacen Jasset]

Re: double free


"weaselboy1 976" <weaselboy1976@ yahoo.com> wrote in message
news:c76c305f.0 407011027.5749e 6d2@posting.goo gle.com...[color=blue]
> 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![/color]

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]

Re: double free

weaselboy1976 wrote:[color=blue]
> 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![/color]

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]

Re: double free

Idriz Smaili <smaili@vmars.t uwien.ac.at> writes:
[...][color=blue]
> type * p = 0;[/color]

That's valid, but most programmers find NULL clearer than 0.
[color=blue]
> 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[/color]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.