how to find number of bytes freed

[sh.vipin]

is there any way to find out number of bytes freed on a particular
free() call in C

 

[David Resnick]

is there any way to find out number of bytes freed on a particular
free() call in C

The only portable way is to store that information when you initially
allocate the memory (and update it if you subsequently successfully
call realloc using that pointer). If you want non-portable ways, you
could try asking in a platform specific group. Even there, it may
depend on what specific standard library implementation you are using,
and may simply not be available by any means.

-David

 

[sh.vipin]

(e-mail address removed) said:


When you allocate this storage, you know how much storage you allocated.

Don't Forget.

Then, when you come to free it, you know, right?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.

 

[vippstar]

yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.

Don't quote sig blocks.
see rfc 2646 4.3
If you don't want to do something, then don't. Simple, isn't it?

 

[sh.vipin]

The only portable way is to store that information when you initially
allocate the memory (and update it if you subsequently successfully
call realloc using that pointer). If you want non-portable ways, you
could try asking in a platform specific group. Even there, it may
depend on what specific standard library implementation you are using,
and may simply not be available by any means.

-David

ok . agreed. i hoped there might be some standard way in which guard
bytes store the information about the allocated memory. if it is
library specific there might not be any way for this. because then
libararies even might not even allocate gurad byte alongwith the data.

 

[CBFalconer]

is there any way to find out number of bytes freed on a particular
free() call in C

No portable means. When you malloc (realloc, calloc) 'ed the item
you specified what you wanted. You can assume you got that much
back. However malloc can assign more than the requested memory
(for alignment maintenance reasons) in which case you will get back
more.

 

[santosh]

yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.

This is not possible in Standard C. But many implementations of C do
provide extensions for this rather commonly felt need. You should ask
in a group for your implementation, or better yet, just read the
documentation for your system's C library.

 

[Walter Roberson]

(e-mail address removed) said:

When you allocate this storage, you know how much storage you allocated.

Don't Forget.

Then, when you come to free it, you know, right?

The number of bytes of the allocation request is not necessarily
the same as the number of bytes freed.

When one makes an allocation request, one might be given a pointer into
the middle of of chunk of memory, with the initial part used as
overhead by the memory allocator; for example in some memory
allocators, it might be used to contain the size of the object.

Or the allocator might choose to allocate in quantums of a particular
size, or the allocator might use a binary page-splitting algorithm,
so the size of the object actually allocated and pointed to might
be larger than the size requested.

When the free() call is made, all of these overhead bytes and
extra bytes are freed -- so the number of bytes freed does not
necessarily match the number of bytes allocated.

 

[Walter Roberson]

When the free() call is made, all of these overhead bytes and
extra bytes are freed -- so the number of bytes freed does not
necessarily match the number of bytes allocated.

Opps, I meant "so the number of bytes freed does not necessarily
match the number of bytes requested for allocation."

 

[Chris Dollin]

is there any way to find out number of bytes freed on a particular
free() call in C

Not portably.

Usually you don't need to know; free frees what malloc malloced.

What is it that you'd do with the answer, were you to have it?

 

[sh.vipin]

Not portably.

Usually you don't need to know; free frees what malloc malloced.

What is it that you'd do with the answer, were you to have it?

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far. i thought of using xyz_malloc() in stead of malloc
everywhere in my application and inside xyz_malloc add the count of
requested amount to a global variable. but when i have to free it i
need to reduce that count.

i can modify xyz_mallo() to solve this problem such that when asked to
allocate N number of bytes, allocate N+1 and return pointer to the 1st
onwards (not 0th) byte as a new memory to aplication and in first byte
store the number of bytes allocated. but it might cause serious
alignment problem

yea, probably my problem is not hard enough to require a memory
manager to be written. probably there must be some API to tell me
current memory usage.
if you know please let me know, but i would like to do some googling
my own before taking your valuable time on this.

 

[Walter Roberson]

i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far.

On most systems, memory can only be requested from the system in
"pages" (of some system-specific size); anything left over in the
"page" that you haven't allocated yet would not be counted by your
program, but it is still "peak memory used by your process".

Counting allocated / deallocated memory also does not take into
account that due to fragmentation, there is almost always memory
allocated to your process but which is not allocated to any
particular user object (some might argue it is allocated to the
memory allocator itself, but details like that are system-specific.)

And as I mentioned in one of my previous responses, there are overhead
bytes needed by the memory allocator to track what is available or free;
those are part of your process but if you only keep a count of your
net requests then you would not be including those.

 

[Bartc]

i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far.

I wrote a memory allocator once where it's free() function /required/ the
number of bytes to free, as the allocator did not store this. I don't
remember that this was ever a problem: usually you knew or could calculate
the N needed.

C's free() of course does not need it (although it means extra overhead to
store it somewhere). But that needn't stop you creating a function such as
free_n(P,N) and using that everywhere.

i can modify xyz_mallo() to solve this problem such that when asked to
allocate N number of bytes, allocate N+1 and return pointer to the 1st
onwards (not 0th) byte as a new memory to aplication and in first byte
store the number of bytes allocated. but it might cause serious
alignment problem

You will need more than 1 byte. Use 8 or 16 instead.

But, your OS might have some utility to tell your the memory usage of your
application.

 

[Antoninus Twink]

i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far.

yea, probably my problem is not hard enough to require a memory
manager to be written. probably there must be some API to tell me
current memory usage.

There is, of course, but the people here will swear blind it doesn't
exist with all the fervor of a madman claiming the sky is not blue.

For example, with gcc you can #include <malloc.h> and use mallinfo().
You can also probably get information from your kernel about your
process's memory usage: for example, on Linux you could investigate
/proc/<pid>/status. How useful the information you'll get is is another
question though...

 

[Richard]

Walter Roberson said:


True, but not particularly important in the grand scheme of things as far
as the abstract machine is concerned.

Yes. But in the real world someone wanting to know the amount used is,
err, probably actually interested in such things.

Wouldn't you think?

 

[Walter Roberson]

On 8 Aug 2008 at 15:02, (e-mail address removed) wrote:

There is, of course, but the people here will swear blind it doesn't
exist with all the fervor of a madman claiming the sky is not blue.

There are a lot of times that the sky is not blue. Like when it is
night out. Or when there are heavy clouds. Severe weather such as
close approximations of torados can turn the sky *very* strange
colors -- as can some kinds of severe snow storms.

"the sky is blue" is not a portable assumption.

 

[Bartc]

There are a lot of times that the sky is not blue. Like when it is
night out. Or when there are heavy clouds. Severe weather such as
close approximations of torados can turn the sky *very* strange
colors -- as can some kinds of severe snow storms.

"the sky is blue" is not a portable assumption.

So what colour is 'sky blue'?

 

[santosh]

So what colour is 'sky blue'?

It's implementation defined!

 

[Serve Lau]

yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.

You dont have to. You can store the number of allocated bytes without have
to introduce a new type. Write your own wrapper around malloc with the added
bonus that you can catch the implementation defined behaviour of malloc(0)
and store the size there. Something like the following but note that this
code doesnt take alignment issues into consideration.

void *my_alloc(size_t n) {
void *pv = 0;

if (n > 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);
}

size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

size_t my_free(void *pv) {
size_t n = 0;

if (pv != 0) {
n = memorysize(pv);

free((size_t *)pv - 1);
}

return n;
}

 

[Ben Bacarisse]

You dont have to. You can store the number of allocated bytes without
have to introduce a new type.

void *my_alloc(size_t n) {
void *pv = 0;

if (n > 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);
}

This can spoil the alignment that malloc has worked hard to ensure. I
think it is better to store the size at the end and I'd memcpy(endp,
&n, sizeof n) that data so as not to worry about alignment of the
size.