[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

dynamic memory allocation

kamalasan baireddy

5/8/2011 7:13:00 PM

How free() knows to delete memory of same created by malloc() ?
16 Answers

China Blue Veins

5/8/2011 7:17:00 PM

0

In article <133e16b8-2e2a-42d6-87a3-60f7e8b5fdf8@r35g2000prj.googlegroups.com>,
kamalasan baireddy <kamalasanb@gmail.com> wrote:

> How free() knows to delete memory of same created by malloc() ?

Implementation dependent. You free() a pointer returned by malloc() et al at
most once; the implementation takes responsibility for everything else.

--
Damn the living - It's a lovely life. I'm whoever you want me to be.
Silver silverware - Where is the love? At least I can stay in character.
Oval swimming pool - Where is the love? Annoying Usenet one post at a time.
Damn the living - It's a lovely life. In 1492....

Chris M. Thomasson

5/8/2011 7:50:00 PM

0

"kamalasan baireddy" <kamalasanb@gmail.com> wrote in message
news:133e16b8-2e2a-42d6-87a3-60f7e8b5fdf8@r35g2000prj.googlegroups.com...
> How free() knows to delete memory of same created by malloc() ?

Imagine a slab allocator that is padded up to and aligned on a page
boundary. When you call `free()', it simply rounds the address of the
pointer down to page size, and bingo; it has access to the slab allocator.
It then links the free memory into a linked list, or whatever...


Peter Nilsson

5/8/2011 11:19:00 PM

0

kamalasan baireddy <kamalas...@gmail.com> wrote:
> How free() knows to delete memory of same created by malloc() ?

This is a FAQ. See <http://c-faq.com/malloc/freesiz...

--
Peter

Datesfat Chicks

5/9/2011 12:16:00 AM

0

On Sun, 8 May 2011 16:19:01 -0700 (PDT), Peter Nilsson
<airia@acay.com.au> wrote:

>kamalasan baireddy <kamalas...@gmail.com> wrote:
>> How free() knows to delete memory of same created by malloc() ?
>
>This is a FAQ. See <http://c-faq.com/malloc/freesiz...

In addition to what is covered in the FAQ (especially about the ease
of "breaking" malloc and free), I should point out that many C
implementations provide a "debugging" version of memory allocation
functions that will help to pinpoint memory leaks, overrunning the
size of the allocated blocks of memory, etc.

In these cases, I'd guess that the debugging versions keep the
allocation information in a redundant form (multiple locations,
protected by checksums or CRCs, etc.) to make it easier to determine
when something got stepped on.

The "debugging" versions are typically valid implementations, but they
tend to be slower than the "production" functions and to use more
memory than necessary.

The "production" functions are minimalist and assume that the client
program is logically correct.

DFC

io_x

5/9/2011 6:22:00 AM

0


"Datesfat Chicks" <datesfat.chicks@gmail.com> ha scritto nel messaggio
news:e4ces6ld8m9jep27bdt13p3h81lm9rsipa@4ax.com...
> On Sun, 8 May 2011 16:19:01 -0700 (PDT), Peter Nilsson
> <airia@acay.com.au> wrote:
>
>>kamalasan baireddy <kamalas...@gmail.com> wrote:
>>> How free() knows to delete memory of same created by malloc() ?
>>
>>This is a FAQ. See <http://c-faq.com/malloc/freesiz...
>
> In addition to what is covered in the FAQ (especially about the ease
> of "breaking" malloc and free), I should point out that many C
> implementations provide a "debugging" version of memory allocation
> functions that will help to pinpoint memory leaks, overrunning the
> size of the allocated blocks of memory, etc.
>
> In these cases, I'd guess that the debugging versions keep the
> allocation information in a redundant form (multiple locations,
> protected by checksums or CRCs, etc.) to make it easier to determine
> when something got stepped on.
>
> The "debugging" versions are typically valid implementations, but they
> tend to be slower than the "production" functions and to use more
> memory than necessary.
>
> The "production" functions are minimalist and assume that the client
> program is logically correct.

you can show one code is "logically correct"?
you can show only that in X years for Y users the program has no
visible error
for me the debugger version has to run always


> DFC

Francois Grieu

5/9/2011 10:38:00 AM

0

On 09/05/2011 08:21, io_x wrote:
> "Datesfat Chicks"<datesfat.chicks@gmail.com> ha scritto nel messaggio
> news:e4ces6ld8m9jep27bdt13p3h81lm9rsipa@4ax.com...
>> On Sun, 8 May 2011 16:19:01 -0700 (PDT), Peter Nilsson
>> <airia@acay.com.au> wrote:
>>
>>> kamalasan baireddy<kamalas...@gmail.com> wrote:
>>>> How free() knows to delete memory of same created by malloc() ?
>>>
>>> This is a FAQ. See<http://c-faq.com/malloc/freesiz...
>>
>> In addition to what is covered in the FAQ (especially about the ease
>> of "breaking" malloc and free), I should point out that many C
>> implementations provide a "debugging" version of memory allocation
>> functions that will help to pinpoint memory leaks, overrunning the
>> size of the allocated blocks of memory, etc.
>>
>> In these cases, I'd guess that the debugging versions keep the
>> allocation information in a redundant form (multiple locations,
>> protected by checksums or CRCs, etc.) to make it easier to determine
>> when something got stepped on.
>>
>> The "debugging" versions are typically valid implementations, but they
>> tend to be slower than the "production" functions and to use more
>> memory than necessary.
>>
>> The "production" functions are minimalist and assume that the client
>> program is logically correct.
>
> you can show one code is "logically correct"?

It is often possible by review of the whole code.

> you can show only that in X years for Y users the program has no
> visible error

No. That's the status for code that includes at least one module
too big to be reviewed in full.

> for me the debugger version has to run always

That is not always appropriate. The debugger version typically has
overhead in term of speed, code size, and RAM memory size, which can
be a bad thing to a degree ranging from negligible to plain unacceptable.
And more often than not, when the debugger version catches an error
in a production environment, there is simply no mechanism to handle
that error in a useful way (that is, terminate cleanly and report the
error back to the developer together with at least some hint on the
context). In which case there is arguably no benefit to using the debug
version in a production context.
There are certainly case where an off-by-one caught by the debug version
is no caught AND harmless in the production version, and one must at
least understand those who prefer the production version in this case.

Francois Grieu

Angel

5/9/2011 1:59:00 PM

0

On 2011-05-08, kamalasan baireddy <kamalasanb@gmail.com> wrote:
> How free() knows to delete memory of same created by malloc() ?

malloc() and friends are programmed to "remember" which block(s) they
give out, usually by adding a small piece of metadata just before or
after the block it gives out. free() can find this metadata by pointer
arithmetic.

As the FAQ points out, accidentally overwriting this metadata will break
things badly.


--
The perfected state of a spam server is a smoking crater.
- The Crater Corollary to Rule #4

Datesfat Chicks

5/9/2011 3:15:00 PM

0

On Mon, 9 May 2011 08:21:48 +0200, "io_x" <a@b.c.invalid> wrote:
>
>"Datesfat Chicks" <datesfat.chicks@gmail.com> ha scritto nel messaggio
>news:e4ces6ld8m9jep27bdt13p3h81lm9rsipa@4ax.com...
>> On Sun, 8 May 2011 16:19:01 -0700 (PDT), Peter Nilsson
>> <airia@acay.com.au> wrote:
>>
>>>kamalasan baireddy <kamalas...@gmail.com> wrote:
>>>> How free() knows to delete memory of same created by malloc() ?
>>>
>>>This is a FAQ. See <http://c-faq.com/malloc/freesiz...
>>
>> In addition to what is covered in the FAQ (especially about the ease
>> of "breaking" malloc and free), I should point out that many C
>> implementations provide a "debugging" version of memory allocation
>> functions that will help to pinpoint memory leaks, overrunning the
>> size of the allocated blocks of memory, etc.
>>
>> In these cases, I'd guess that the debugging versions keep the
>> allocation information in a redundant form (multiple locations,
>> protected by checksums or CRCs, etc.) to make it easier to determine
>> when something got stepped on.
>>
>> The "debugging" versions are typically valid implementations, but they
>> tend to be slower than the "production" functions and to use more
>> memory than necessary.
>>
>> The "production" functions are minimalist and assume that the client
>> program is logically correct.
>
>you can show one code is "logically correct"?
>you can show only that in X years for Y users the program has no
>visible error
>for me the debugger version has to run always

What you're saying is that software is so untrustworthy that you
always have to have some code that acts as a safeguard or backup for
other code.

OK, assume that code Q checks on code P.

Assume that the probability that P contains defects is B(P). Assume
that the probability Q will not detect those defects is B(Q). The
probability of undetected defects is then B(P) * B(Q).

B(P) * B(Q) is still a non-zero number. There still may be undetected
defects.

And why not use standard techniques to reduce B(P), with the
understanding that B(Q)=1, as there is no Q? You'll still end up with
a small non-zero number ...

It seems hard to mathematically differentiate the case of Q or no Q.
Either case leaves you with a non-zero probability of residual
defects.

DFC

Keith Thompson

5/9/2011 3:33:00 PM

0

Angel <angel+news@spamcop.net> writes:
> On 2011-05-08, kamalasan baireddy <kamalasanb@gmail.com> wrote:
>> How free() knows to delete memory of same created by malloc() ?
>
> malloc() and friends are programmed to "remember" which block(s) they
> give out, usually by adding a small piece of metadata just before or
> after the block it gives out. free() can find this metadata by pointer
> arithmetic.
[...]

A minor point: I don't think the information can be stored *after* the
memory block. free() is given a pointer to the beginning of the
allocated block. Without knowing how big the block is, it wouldn't be
able to find the metadata at the end of it.

There could be *some* metadata stored after the block, as long as
there's some other mechanism to find it -- but it would be more likely
to be clobbered by clumsy user code than metadata stored before the
block.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Kenneth Brody

5/9/2011 6:06:00 PM

0

On 5/9/2011 11:32 AM, Keith Thompson wrote:
> Angel<angel+news@spamcop.net> writes:
>> On 2011-05-08, kamalasan baireddy<kamalasanb@gmail.com> wrote:
>>> How free() knows to delete memory of same created by malloc() ?
>>
>> malloc() and friends are programmed to "remember" which block(s) they
>> give out, usually by adding a small piece of metadata just before or
>> after the block it gives out. free() can find this metadata by pointer
>> arithmetic.
> [...]
>
> A minor point: I don't think the information can be stored *after* the
> memory block. free() is given a pointer to the beginning of the
> allocated block. Without knowing how big the block is, it wouldn't be
> able to find the metadata at the end of it.
>
> There could be *some* metadata stored after the block, as long as
> there's some other mechanism to find it -- but it would be more likely
> to be clobbered by clumsy user code than metadata stored before the
> block.

Yes, I have seen debugging implementations that store metadata after the
block (in addition to before the block), and verify the integrity of that
data at certain times, such as when you free() that block.

--
Kenneth Brody