malloc and free

[Ed]

Hi,

When free() is used to free the memory allocated by malloc(), how does
it know the size of the memory to be freed? I guess I'm asking where
does the info stored? Thanks

Ed

 

[Dave Vandervies]

Hi,

When free() is used to free the memory allocated by malloc(), how does
it know the size of the memory to be freed?

Compiler magic.
(Well, in this case, library magic. But implementation magic in any
case.)

I guess I'm asking where
does the info stored?

Somewhere you can't get at it. Or possibly it gets reconstructed from
other information and doesn't need to be stored. Or possibly free()
just needs to request that the hardware mark the segment as unallocated
and doesn't need the size at all.

If you need to know the size of a chunk of memory you got from malloc,
you'll need to store the size you asked it for somewhere.


dave

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Hi,

When free() is used to free the memory allocated by malloc(), how does
it know the size of the memory to be freed? I guess I'm asking where
does the info stored? Thanks

Implementation dependant.
It could store it in memory just before the memory given back by malloc,
it could use the address as an index into an array/tree/whatnot, and
many other more or less clever things.

 

[Default User]

Hi,

When free() is used to free the memory allocated by malloc(), how does
it know the size of the memory to be freed?
Magic.

I guess I'm asking where does the info stored?

Someplace secret. None of your business, seriously. How a particular
implementation does it is highly platform-specific and of little or no
use to the programmer.




Brian Rodenborn

 

[E. Robert Tisdale]

When free() is used to free the memory allocated by malloc(),
how does it know the size of the memory to be freed?

Obviously, malloc(size_t) stores the size somewhere
where free(void*) can find it.

I guess I'm asking where does the info stored?

Typically, information about the amount of storage allocated
is stored immediately before the allocated storage.
Try this:

> cat main.c

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
if (1 < argc) {
const
size_t n = atoi(argv[1]);
size_t* p = (size_t*)malloc(n*sizeof(size_t));
fprintf(stdout, "p[-2] = %u\n", p[-2]);
fprintf(stdout, "p[-1] = %u\n", p[-1]);
}
return EXIT_SUCCESS;
}

> gcc -Wall -std=c99 -pedantic -o main main.c
> ./main 1

p[-2] = 0
p[-1] = 17

On my computer, malloc allocates storage
in "double word" aligned increments.
It always allocates one double word to store the size
and at least one other double word for storage.

 

[Dan Pop]

Magic.

It derives it, one way or another, from the address of the memory block.
See chapter 8 from K&R2 for one possible answer.

Someplace secret. None of your business, seriously. How a particular
implementation does it is highly platform-specific and of little or no
use to the programmer.

In an ideal world, where programmers didn't make any mistakes, maybe.
In the real world, this kind of information helps understanding the
(mis)behaviour of a buggy program, e.g. why a free() call generates a
segfault or why some implementations complain about a corrupted malloc
arena.

Dan

 

[Method Man]

I guess I'm asking where does the info stored?

Someplace secret. None of your business, seriously.

That may be true.

How a particular
implementation does it is highly platform-specific and of little or no
use to the programmer.

It can be educational to know how a particual implementation of malloc is
done. Perhaps the OP wishes to write his own memory manager and is gathering
information. In any case, there are definitely purposes and uses for seeking
such knowledge.

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Obviously, malloc(size_t) stores the size somewhere
where free(void*) can find it.



Typically, information about the amount of storage allocated
is stored immediately before the allocated storage.
Try this: ....

On my computer, malloc allocates storage
in "double word" aligned increments.
It always allocates one double word to store the size
and at least one other double word for storage.

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0

 

[E. Robert Tisdale]

Obviously, malloc(size_t) stores the size somewhere
where free(void*) can find it.


Typically, information about the amount of storage allocated
is stored immediately before the allocated storage.
Try this:
...

On my computer, malloc allocates storage
in "double word" aligned increments.
It always allocates one double word to store the size
and at least one other double word for storage.

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0

That' not a lot of information.
Would you care to elaborate a little?

 

[Default User]

In <[email protected]> "Default User"


In an ideal world, where programmers didn't make any mistakes, maybe.
In the real world, this kind of information helps understanding the
(mis)behaviour of a buggy program, e.g. why a free() call generates a
segfault or why some implementations complain about a corrupted malloc
arena.

Normally this question is a prelude to accessing this information for
the wrong purposes, like figuring out the size of dynamically-allocated
arrays or such.




Brian Rodenborn

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0

That' not a lot of information.
Would you care to elaborate a little?

Just seems that my computer behaves diffrently than yours
(Running NetBSD on x86 btw)

 

[E. Robert Tisdale]

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0

That' not a lot of information.
Would you care to elaborate a little?

Just seems that my computer behaves diffrently than yours
(Running NetBSD on x86 btw)

Which compiler?

 

[Flash Gordon]

Ed wrote:

When free() is used to free the memory allocated by malloc(),
how does it know the size of the memory to be freed?

Obviously, malloc(size_t) stores the size somewhere
where free(void*) can find it.

I guess I'm asking where does the info stored?

Typically, information about the amount of storage allocated
is stored immediately before the allocated storage.
Try this:
...

On my computer, malloc allocates storage
in "double word" aligned increments.
It always allocates one double word to store the size
and at least one other double word for storage.

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0

That' not a lot of information.
Would you care to elaborate a little?

It shows that your suggesting of what is typically done does not apply
to Nils system, thus demonstrating that you are talking non-portable
rubbish again. I would have said that was completely obvious to someone
with two brain cells to run together.

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0






That' not a lot of information.
Would you care to elaborate a little?

Just seems that my computer behaves diffrently than yours
(Running NetBSD on x86 btw)

Which compiler?

bash-2.05b$ gcc -v
Using built-in specs.
Configured with:
/home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configure
--enable-long-long --disable-multilib --enable-threads --disable-symvers
--build=i386-unknown-netbsdelf --host=i386--netbsdelf
--target=i386--netbsdelf
Thread model: posix
gcc version 3.3.3 (NetBSD nb3 20040520)

 

[E. Robert Tisdale]

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0







That' not a lot of information.
Would you care to elaborate a little?



Just seems that my computer behaves diffrently than yours
(Running NetBSD on x86 btw)

Which compiler?

bash-2.05b$ gcc -v
Using built-in specs.
Configured with:
/home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configure
--enable-long-long --disable-multilib --enable-threads --disable-symvers
--build=i386-unknown-netbsdelf --host=i386--netbsdelf
--target=i386--netbsdelf
Thread model: posix
gcc version 3.3.3 (NetBSD nb3 20040520)

> gcc -v

Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ../gcc-3.4.1.src/configure
Thread model: posix
gcc version 3.4.1

 

[Richard Tobin]

When free() is used to free the memory allocated by malloc(), how does
it know the size of the memory to be freed? I guess I'm asking where
does the info stored? Thanks

As others have said, it's system dependent.

If - for your own education - you want to get some idea of how a
particular system does it, then either look at the source code, or
write a little program that repeatedly mallocs blocks of the same size
and prints out the difference between successive return values.
Typically, the difference will be the same most of the time (though of
course, an implementation could do something completely different).

On some implementations you will see that the difference is always
bigger than the size allocated - maybe enough bigger for a size field,
and then rounded up for alignment. On others (such as the one I'm
using now) the difference will usually be the size rounded up to a
power of two. Clearly in such cases the system is not storing the
size in the block.

-- Richard

 

[Keith Thompson]

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0





That' not a lot of information.
Would you care to elaborate a little?

Just seems that my computer behaves diffrently than yours
(Running NetBSD on x86 btw)

Which compiler?

How is the compiler relevant to the behavior of malloc()?

 

[Mark F. Haigh]

Hi,

When free() is used to free the memory allocated by malloc(), how does
it know the size of the memory to be freed? I guess I'm asking where
does the info stored? Thanks

As Eric Sosman so eloquently put it:

The actual size of the memory pointed to is etched in mystic runes
on a tablet of finest jade, kept in a diamond-encrusted box with
silver hinges and golden locks, hidden in a sacred cave in the Tibetan
highlands and guarded by a crack regiment of three hundred Abominable
Snowmen, each mounted upon a hippogriff with carnivorous tendencies.
Seven immortal unsleeping one-eyed sorcerers stand upon the seven
peaks that surround the Valley of the Cave, each ready to hurl magical
destruction on any who venture near. The stream that flows from the
valley teems with invisible piranhas who eat only man-flesh, and is so
cold that if a single drop should touch your skin you would instantly
freeze to superconducting temperatures.

Or to put it another way, "There are some things Man was not Meant To
Know."


Mark F. Haigh
(e-mail address removed)

 

[Barry Schwarz]

On Wed, 13 Oct 2004 11:15:32 -0700, "E. Robert Tisdale"

snip

Typically, information about the amount of storage allocated
is stored immediately before the allocated storage.
Try this:

cat main.c

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
if (1 < argc) {
const
size_t n = atoi(argv[1]);
size_t* p = (size_t*)malloc(n*sizeof(size_t));
fprintf(stdout, "p[-2] = %u\n", p[-2]);
fprintf(stdout, "p[-1] = %u\n", p[-1]);

Just so the newcomers don't get too confused, be aware these two
invoke undefined behavior, even when the initial assertion is true.

}
return EXIT_SUCCESS;
}

gcc -Wall -std=c99 -pedantic -o main main.c
./main 1

p[-2] = 0
p[-1] = 17

As do these two.

On my computer, malloc allocates storage
in "double word" aligned increments.
It always allocates one double word to store the size
and at least one other double word for storage.

An implementation detail which is not portable and not part of the
language standard.


<<Remove the del for email>>

 

[Dan Pop]

Normally this question is a prelude to accessing this information for
the wrong purposes, like figuring out the size of dynamically-allocated
arrays or such.

I see no point in making assumptions about the OP's intentions and
denying him a sensible answer based on these assumptions.

Dan