How do I know if free() really free()ed?
maxw_cc
This may be a silly question, but I was wondering
is there any way to know if free() did free()ed
the space...? Or the only way to know if it worked fine,
is that if my program doesn't crash or my program doesn't receive
SIGABRT, SIGSEGV... or any other implementation defined signal, then
I can assume it worked fine???
Thanks a lot in advance...
Max
Hallvard B Furuseth
> This may be a silly question, but I was wondering
> is there any way to know if free() did free()ed
> the space...? Or the only way to know if it worked fine,
> is that if my program doesn't crash or my program doesn't receive
> SIGABRT, SIGSEGV... or any other implementation defined signal, then
> I can assume it worked fine???
If you don't trust your C library to work correctly, or you don't trust
your program to use it correctly, you can't assume anything at all if
the program seems to work. Maybe it just didn't happen to run across
a bug.
However, there are several "debug malloc" packages and leak detectors
around which can often detect if your program uses malloc/free
incorrectly, e.g. if it frees memory which was not malloced. Which
such packages you can use depends on your operating system.
--
Hallvard
Jan Engelhardt
>> is there any way to know if free() did free()ed
>> the space...? Or the only way to know if it worked fine,
>> is that if my program doesn't crash or my program doesn't receive
>> SIGABRT, SIGSEGV... or any other implementation defined signal, then
>> I can assume it worked fine???
>
>However, there are several "debug malloc" packages and leak detectors
>around which can often detect if your program uses malloc/free
>incorrectly, e.g. if it frees memory which was not malloced. Which
>such packages you can use depends on your operating system.
"dmalloc" library or
man malloc reveals that you can set the environment variable
MALLOC_CHECK_ (for glibc).
- Jan Engelhardt
Dan Pop
The OP has a point. Sadly enough, the following free() implementation
is conforming:
void free(void *ptr) {}
At least, this is what the people who have actually written the C standard
claim...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Arthur J. O'Dwyer
On Wed, 2 Apr 2003, Dan Pop wrote:
>
> In <HBF.2003...@bombur.uio.no> Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
> >max...@yahoo.com (maxw_cc) wrote:
> >
> >> This may be a silly question, but I was wondering
> >> is there any way to know if free() did free()ed
> >> the space...? Or the only way to know if it worked fine,
> >> is that if my program doesn't crash or my program doesn't receive
> >> SIGABRT, SIGSEGV... or any other implementation defined signal, then
> >> I can assume it worked fine???
> >
> The OP has a point. Sadly enough, the following free() implementation
> is conforming:
>
> void free(void *ptr) {}
Of course it is!
> At least, this is what the people who have actually written the C standard
> claim...
And they should know, shouldn't they? On that particular implementation,
you have the interesting behavior that a pointer can be 'free'd multiple
times with no ill effects (although that is merely a harmless
manifestation of undefined behavior).
IOW, since the implementation defines what it means for memory to be
'free'd, the implementation's version of 'free' can do whatever it likes
as long as it conforms to the Standard.
Perhaps the OP meant: "Is this an infinite loop on my system?"
#include <stdlib.h>
int main() {
void *p; while (p=malloc(1000))
free(p);
}
Or perhaps the OP meant: "Does this program crash horribly on my system?"
#include <stdlib.h>
int main() {
void *p = malloc(1000);
free(p);
free(p);
}
Both of these questions can be answered to a reasonable degree of
certitude in five minutes by simple experimentation. Neither answer
is particularly useful with regard to the C language.
-Arthur
Glen Herrmannsfeldt
"Dan Pop" <Dan...@cern.ch> wrote in message
news:b6f53h$3kb$1...@sunnews.cern.ch...
> In <HBF.2003...@bombur.uio.no> Hallvard B Furuseth
<h.b.fu...@usit.uio.no> writes:
>
> >max...@yahoo.com (maxw_cc) wrote:
> >
> >> This may be a silly question, but I was wondering
> >> is there any way to know if free() did free()ed
> >> the space...? Or the only way to know if it worked fine,
> >> is that if my program doesn't crash or my program doesn't receive
> >> SIGABRT, SIGSEGV... or any other implementation defined signal, then
> >> I can assume it worked fine???
(snip)
> The OP has a point. Sadly enough, the following free() implementation
> is conforming:
>
> void free(void *ptr) {}
>
> At least, this is what the people who have actually written the C standard
> claim...
Well, there is that. But also many OS have a relatively expensive memory
allocation/deallocation system, so it is common for the C library to get a
large block from the OS and then suballocate it among calls to malloc().
In that case, calls to free() won't, at the OS level, actually free the
memory.
There are also malloc()/free() usage patterns that might inefficently use
available memory.
If you malloc() a large number of blocks of memory, and then free() ever
other block you leave lots of little holes in (hopefully virtual) memory.
If you then allocate a large number of slightly larger blocks, none of the
holes can be used.
-- glen
Dan Pop
>"Dan Pop" <Dan...@cern.ch> wrote in message
>news:b6f53h$3kb$1...@sunnews.cern.ch...
>> In <HBF.2003...@bombur.uio.no> Hallvard B Furuseth
><h.b.fu...@usit.uio.no> writes:
>>
>> >max...@yahoo.com (maxw_cc) wrote:
>> >
>> >> This may be a silly question, but I was wondering
>> >> is there any way to know if free() did free()ed
>> >> the space...? Or the only way to know if it worked fine,
>> >> is that if my program doesn't crash or my program doesn't receive
>> >> SIGABRT, SIGSEGV... or any other implementation defined signal, then
>> >> I can assume it worked fine???
>
>(snip)
>
>> The OP has a point. Sadly enough, the following free() implementation
>> is conforming:
>>
>> void free(void *ptr) {}
>>
>> At least, this is what the people who have actually written the C standard
>> claim...
>
>Well, there is that. But also many OS have a relatively expensive memory
>allocation/deallocation system, so it is common for the C library to get a
>large block from the OS and then suballocate it among calls to malloc().
>In that case, calls to free() won't, at the OS level, actually free the
>memory.
Why would one expect free() to *ever* return anything back to the OS?
Malcolm
>
the printer you expect the printer to be made available for another program
to use. Similarly when a program closes a window you would expect that area
of screen to become available for another program. So why should memory be
any different?
Hallvard B Furuseth
>Dan Pop <Dan...@cern.ch> wrote in message
>
>> Why would one expect free() to *ever* return anything back to the OS?
Because one doesn't know or hasn't thought about how malloc works?
> Is this a trick question? When a program indicates that it is finished
> with the printer you expect the printer to be made available for
> another program to use. (...) So why should memory be any different?
Several reasons, the most prominent being that memory can be freed in
any order. That leaves "holes" of free memory in the middle of the
process' malloced address space. malloc() reuses these holes when
possible, and typically grabs more memory at the bottom of the address
space otherwise. So it could return memory to the system if free() left
a "hole" at the bottom of the address space, but it usually cannot
return a hole in the middle of the address space to the system. For
that matter, most holes could not be returned even if there was a system
call to do so, because the system operates with "pages" of memory of
e.g. 1024 bytes each, while a hole may be just part of a page, or
overlap two pages.
--
Hallvard
Dan Pop
Because free(something) means: I no longer need this memory block NOW,
but I may need it back in the next function call. Wouldn't you be upset
if, right after freeing a 1K memory block, your program is unable to
allocate another 1K memory block? After all, the standard says:
The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation.
If free() gives the memory block back to the system, you may not be able
to get it back, so it was not made available for further allocation.
Joshua Jones
>
> The free function causes the space pointed to by ptr to be
> deallocated, that is, made available for further allocation.
>
> If free() gives the memory block back to the system, you may not be able
> to get it back, so it was not made available for further allocation.
>
Is it assumed that it is "made available for further allocation"
to any one in particular? The standard doesn't specify this in
this section, so could it be interpreted that it is made available
to anyone, and can subsequently be claimed by another program and
thus not be available to the same program that free'd it?
--
josh(at)cc.gatech.edu | http://intmain.net:800
CS @ College of Computing, Georgia Institute of Technology, Atlanta
681453 local keystrokes since last reboot (72 days ago)
Mark McIntyre
<jo...@cc.gatech.edu> wrote:
>Dan Pop <Dan...@cern.ch> wrote:
>>
>> The free function causes the space pointed to by ptr to be
>> deallocated, that is, made available for further allocation.
>>
>> If free() gives the memory block back to the system, you may not be able
>> to get it back, so it was not made available for further allocation.
>
>Is it assumed that it is "made available for further allocation"
>to any one in particular?
I think its meaning "available for further allocation by the system".
> The standard doesn't specify this in
>this section, so could it be interpreted that it is made available
>to anyone, and can subsequently be claimed by another program and
>thus not be available to the same program that free'd it?
Yup.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Alan Balmer
<markmc...@spamcop.net> wrote:
>On 4 Apr 2003 21:17:25 GMT, in comp.lang.c , Joshua Jones
><jo...@cc.gatech.edu> wrote:
>
>>Dan Pop <Dan...@cern.ch> wrote:
>>>
>>> The free function causes the space pointed to by ptr to be
>>> deallocated, that is, made available for further allocation.
>>>
>>> If free() gives the memory block back to the system, you may not be able
>>> to get it back, so it was not made available for further allocation.
>>
>>Is it assumed that it is "made available for further allocation"
>>to any one in particular?
>
>I think its meaning "available for further allocation by the system".
>
Dunno what the standard-writers intended, but I do know that some
implementations make freed memory available for further allocation by
the C runtime, but not available to the system. In fact there are
implementations which provide a special library function to release
memory back to the system.
>> The standard doesn't specify this in
>>this section, so could it be interpreted that it is made available
>>to anyone, and can subsequently be claimed by another program and
>>thus not be available to the same program that free'd it?
>
>Yup.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Kevin Easton
> On 4 Apr 2003 21:17:25 GMT, in comp.lang.c , Joshua Jones
> <jo...@cc.gatech.edu> wrote:
>
>>Dan Pop <Dan...@cern.ch> wrote:
>>>
>>> The free function causes the space pointed to by ptr to be
>>> deallocated, that is, made available for further allocation.
>>>
>>> If free() gives the memory block back to the system, you may not be able
>>> to get it back, so it was not made available for further allocation.
>>
>>Is it assumed that it is "made available for further allocation"
>>to any one in particular?
>
> I think its meaning "available for further allocation by the system".
>
>> The standard doesn't specify this in
>>this section, so could it be interpreted that it is made available
>>to anyone, and can subsequently be claimed by another program and
>>thus not be available to the same program that free'd it?
>
> Yup.
As you well know, there *is* no one else who may be doing allocation in
the context of the Standard.
- Kevin.
Mark McIntyre
<alba...@att.net> wrote:
>On Fri, 04 Apr 2003 23:22:33 +0100, Mark McIntyre
><markmc...@spamcop.net> wrote:
>
>>I think its meaning "available for further allocation by the system".
>>
>Dunno what the standard-writers intended, but I do know that some
>implementations make freed memory available for further allocation by
>the C runtime, but not available to the system. In fact there are
>implementations which provide a special library function to release
>memory back to the system.
My suspicion is that on these systems, the memory *is* in fact
released back for further allocation by the system, but that the
system has its own rules which tell it to keep it reserved for the
application. The wording does not, after all, require the system to
accept the memory back. :-)
Mark McIntyre
Well, I'd not say quite that. Its probably more accurate to say that a
C programme using only ISO C does not know if there's anything outside
itself which might allocate memory, and consequently does not know if
memory freed is still available, or has been allocated elsewhere if an
elsewhere exists, except by trial and error.
David C.
>
> This may be a silly question, but I was wondering is there any way
> to know if free() did free()ed the space...? Or the only way to know
> if it worked fine, is that if my program doesn't crash or my program
> doesn't receive SIGABRT, SIGSEGV... or any other implementation
> defined signal, then I can assume it worked fine???
What, specifically, are you looking for?
If you want to know whether the C library returned the memory to the
operating system, there is no way to know this from portable code.
You'd need some platform-specific knowledge about your operating
system and/or your C library.
If you want to know whether the memory has been returned to whatever
pool of memory the malloc() function gets its memory from (so that it
might be used to satisfy a future allocation), there's also no way to
know this for sure. Some libraries may return the memory immediately,
and some may mark it for later collection.
The only thing you can be sure of is that your application must act as
if the memory has become invalid the moment it is passed to free().
Although the memory may be readable on some platforms, you can't
guarantee that, and even if the memory is readable, you can't
guarantee that the data stored at the freed addresses is still valid.
-- David
bd
void free(void *x){} dosen't make it available for further allocation :)
Glen Herrmannsfeldt
Well, I suppose in the days of cheap memory, especially virtual memory,
maybe not. As we all know, C does not require it. Still, it might be a
nice thing to do, on some OS.
-- glen
Dan Pop
Given that you're replying to Mark McIntyre, the correct phrasing is:
"As you should well know...". NEVER underestimate his ignorance.
Dan Pop
Indeed (and I thought, for years, that such an implementation would be
non-conforming). Unfortunately, the committee members didn't mean "made
available for further allocation" when they wrote "made available
for further allocation". Don't ask me what they actually meant ;-(
Dan Pop
It depends on your definition of "nice". Would it be nice, to your
program, to no longer be able to allocate a piece of memory it had
freed before?
Alan Balmer
<markmc...@spamcop.net> wrote:
>On Fri, 04 Apr 2003 16:12:49 -0700, in comp.lang.c , Alan Balmer
><alba...@att.net> wrote:
>
>>On Fri, 04 Apr 2003 23:22:33 +0100, Mark McIntyre
>><markmc...@spamcop.net> wrote:
>>
>>>I think its meaning "available for further allocation by the system".
>>>
>>Dunno what the standard-writers intended, but I do know that some
>>implementations make freed memory available for further allocation by
>>the C runtime, but not available to the system. In fact there are
>>implementations which provide a special library function to release
>>memory back to the system.
>
>My suspicion is that on these systems, the memory *is* in fact
>released back for further allocation by the system, but that the
>system has its own rules which tell it to keep it reserved for the
>application. The wording does not, after all, require the system to
>accept the memory back. :-)
And, afaict, the wording doesn't require that the memory be made
available to other processes - after all, the standard doesn't even
know about other processes.
IAC, on one system of which I have knowledge (Watcom C), your
suspicion is wrong :-) My suspicion is that it may be wrong in other
cases as well. .
Watcom provides the _heapshrink function, which returns unused memory
at the end of the heap to the system. Otherwise, ownership is retained
by the heap manager.
I assume that memory is retained for performance reasons, since
Watcom was designed with performance in mind.
nobody
It's inconsistent with utilizing other resources.
It can happen that at one time I can write 10 kB of data to file,
discard it and later write can fail (e.g. due full filesystem).
That's why we are encouraged to check
returns from malloc() (and other funcs).
With current state of affairs, I could put on top of main e.g.
void* p = malloc(10000000);assert(p);free(p);
and never worry about checking malloc() returns in rest of the
program (as long as I always free allocated blocks). This IMHO
somewhat defeats 'dynamic' memory allocation 'purpose'. Yes,
it's dynamic in context of current 'program', but until now I thought
it was in context of 'OS' :-(
#include<stdio.h>
main()??<char*s="./??/"/$9";while(*s&&putchar(*s++??!
'?'+sizeof(char)));return(putchar('*'??''!'??'sizeof(char)));??>
Glen Herrmannsfeldt
"Alan Balmer" <alba...@att.net> wrote in message
news:jv639vkjldev95t3n...@4ax.com...
(snip regarding free() and actually freeing memory)
> And, afaict, the wording doesn't require that the memory be made
> available to other processes - after all, the standard doesn't even
> know about other processes.
>
> IAC, on one system of which I have knowledge (Watcom C), your
> suspicion is wrong :-) My suspicion is that it may be wrong in other
> cases as well. .
Watcom C on which OS? I would not be surprised if it was OS dependent, and
Watcom C runs on many different OS.
> Watcom provides the _heapshrink function, which returns unused memory
> at the end of the heap to the system. Otherwise, ownership is retained
> by the heap manager.
>
> I assume that memory is retained for performance reasons, since
> Watcom was designed with performance in mind.
Including OS that do not have anything called a heap.
-- glen
Glen Herrmannsfeldt
"nobody" <nob...@nowhere.non> wrote
> "Dan Pop" <Dan...@cern.ch> wrote(snip)
> > >>
> > >> Why would one expect free() to *ever* return anything back to the OS?
> > >
> > >Well, I suppose in the days of cheap memory, especially virtual memory,
> > >maybe not. As we all know, C does not require it. Still, it might be
a
> > >nice thing to do, on some OS.
> >
> > It depends on your definition of "nice". Would it be nice, to your
> > program, to no longer be able to allocate a piece of memory it had
> > freed before?
> >
> No, it wouldn't (be nice), and also it wouldn't be selfish :-)
> It's inconsistent with utilizing other resources.
> It can happen that at one time I can write 10 kB of data to file,
> discard it and later write can fail (e.g. due full filesystem).
> That's why we are encouraged to check
> returns from malloc() (and other funcs).
> With current state of affairs, I could put on top of main e.g.
>
> void* p = malloc(10000000);assert(p);free(p);
>
> and never worry about checking malloc() returns in rest of the
> program (as long as I always free allocated blocks). This IMHO
> somewhat defeats 'dynamic' memory allocation 'purpose'. Yes,
> it's dynamic in context of current 'program', but until now I thought
> it was in context of 'OS' :-(
It might not work, either. There have been OS that would setup the page
tables so that all were pointing to the same real page. Then, when the
memory was actually modified allocate a real page frame for it. Note that
the example didn't actually modify the memory.
It may or may not be legal C to do that.
(The example where this became obvious was testing a cache memory system.
The test should have been independent of the contents of the memory, so
didn't bother to initialize it.)
-- glen
Alan Balmer
<g...@ugcs.caltech.edu> wrote:
>
>"Alan Balmer" <alba...@att.net> wrote in message
>news:jv639vkjldev95t3n...@4ax.com...
>
>(snip regarding free() and actually freeing memory)
>
>> And, afaict, the wording doesn't require that the memory be made
>> available to other processes - after all, the standard doesn't even
>> know about other processes.
>>
>> IAC, on one system of which I have knowledge (Watcom C), your
>> suspicion is wrong :-) My suspicion is that it may be wrong in other
>> cases as well. .
>
>Watcom C on which OS? I would not be surprised if it was OS dependent, and
>Watcom C runs on many different OS.
The function is provided for all supported platforms. I expect it will
be supported for any future platforms as well. For any platform, it is
likely to be true that allocating memory from the system is more
expensive than managing memory within a process, simply because the
system has more factors to take into account.
>
>> Watcom provides the _heapshrink function, which returns unused memory
>> at the end of the heap to the system. Otherwise, ownership is retained
>> by the heap manager.
>>
>> I assume that memory is retained for performance reasons, since
>> Watcom was designed with performance in mind.
>
>Including OS that do not have anything called a heap.
>
?
Not sure what you're trying to say. IAC, the point is that some
implementations do *not* make freed memory immediately available to
the operating system.
Dan Pop
>Not sure what you're trying to say. IAC, the point is that some
>implementations do *not* make freed memory immediately available to
>the operating system.
As far as my experience is concerned, *most* implementations do not make
freed memory *immediately* available to the operating system.