Re: Newbie question on malloc()

["John T. Williams" <jowillia@vt.edu>]

According to the glibc documentation, it is not guaranteed to do so

http://www.gnu.org/software/libc/manual/html_node/Termination-Internals.html#Termination%20Internals






On Thu, 2004-06-03 at 19:24, Paul Gimpelj wrote:
> hi,
> pardon me for patching to this thread,
> 
> but, following this conversation,
> if files are left open at exit, does the operating system (linux) flush the
> i/o buffers to disk before closing files?
> This is not the case with windows 95/98  and dos.
> OR, does the _exit() function in the c runtime do it.
> Thanks.
> 
> thanks
> 
> regards,
> Paul
> 
> 
> ----- Original Message -----
> From: "John T. Williams" <jowillia@vt.edu>
> To: "Glynn Clements" <glynn.clements@virgin.net>
> Cc: "Micha Feigin" <michf@post.tau.ac.il>; "linux-c-programming"
> <linux-c-programming@vger.kernel.org>
> Sent: Thursday, June 03, 2004 6:25 PM
> Subject: Re: Newbie question on malloc()
> 
> 
> >
> > I think this is may be a somewhat misleading statement. Not freeing
> > memory before normal termination decreases re-usability of your code.
> > You never know when your main function might be reused verbatim as
> > another sub function. Failing to free memory before all reference leave
> > scope can lead to massive memory leeks. Further, the more memory your
> > program is holding at any given moment of operation the more pages it
> > holds, the more pages it holds the more likely any particular call to a
> > memory location will lead to a page fault, and page faults are
> > expensive. Freeing memory allows malloc to reassign that memory next
> > time its called. Now I know that this was a question about freeing
> > memory before termination, and therefore unless we are talking about a
> > situation where your code is being reused my last two arguments hold no
> > weight, but I believe that it is simply good practice to always be aware
> > of memory you have dynamically allocated and always free it after you no
> > more use for it. In this way you don't get used to saying well if I miss
> > it the operating system will clean it up for me. Please note I do not
> > suggest that one should go to out of the way to free memory on abnormal
> > termination, but its simply good practice to free memory when it is no
> > longer being used in the normal behavior of your code.
> >
> >
> >
> > On Thu, 2004-06-03 at 03:59, Glynn Clements wrote:
> > > Micha Feigin wrote:
> > >
> > > > > I have made a daemon in which dynamic memory is gotten
> > > > > by malloc(). Does the memory get free automatically without
> > > > > free() by the deamon  when the daemon process is killed?
> > > > > Thanks in advance.
> > > >
> > > > It does, but in general its not in good practice to count on process
> > > > exit for freeing memory (a good way to get memory leaks).
> > >
> > > This is incorrect.
> > >
> > > You shouldn't make an effort to return memory to the process' heap (by
> > > calling free()) if the program is about to terminate.
> > >
> > > Doing so consumes CPU time (and probably disk bandwidth, given that
> > > some of that memory will probably be swapped out) and doesn't provide
> > > any benefit (free() won't usually return memory to the OS and, in any
> > > case, all of the process' memory will be returned to the OS upon
> > > exit).
> > >
> > > The only valid reason for free()ing memory blocks upon termination is
> > > if the structure of the program is such that it isn't practical to
> > > avoid doing so. E.g. if data structures have matched setup/cleanup
> > > routines, and you need to call the cleanup code for other reasons, and
> > > the cleanup code will free the memory anyway.
> > >
> > > Similarly, you don't need to explicitly close() file descriptors, or
> > > release file locks (those obtained with flock/lockf/fcntl) as the OS
> > > will do that.
> > >
> > > The sort of actions which might make sense to perform before calling
> > > exit() are:
> > >
> > > + Writing a log entry reporting shutdown
> > > + Deleting temporary files
> > > + Deleting any SysV IPC structures which aren't shared with other
> > >   processes.
> > > + Informing other networked processes of termination, e.g. sending a
> > >   "QUIT" command.
> > > + Killing child processes.
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html