Re: Glib and memory allocation

[John Vetterli <jvetterli linux ca>]

Oho!  If a part of the kernel, say a device driver, allocates memory in
"kernel-space" and never explicitly frees it, then there would be a
memory leak inside that device driver.  And since the device driver is
somewhat independent of the process that uses the device driver, there
would be no automatic freeing of that memory when the process dies. 
(Unless I'm mistaken. Or maybe the kernel and device driver developers
have some ultra-clever trick up their sleeves which I couldn't even
begin to imagine.)

You may want to try to contact the people who created your device driver
to see if they know anything about a memory leak.

JV

On Wed, 9 Feb 2005 09:53:57 +0100
Cristiano Ghirardi <cristiano ghirardi gmail com> wrote:
> Thanks,
> off course not boring at all! Unfortunately you confirm what was also
> my opinion: the problem in in the kernel or in a camera-link frame
> grabber that I use...
> What if the memory non freed has been allocated at kernel level?
> Bye
> On Tue, 8 Feb 2005 23:18:35 -0500, John Vetterli <jvetterli linux ca>
> wrote:
> > On Tue, 8 Feb 2005 18:19:03 +0100
> > Cristiano Ghirardi <cristiano ghirardi gmail com> wrote:
> > > it's not clear to me what happens when memory has been allocate
> > > with g_new or g_realloc and not freed. I mean: obviously  this
> > > memory remains in the user space of the process as an infamous
> > > memory leak but it seems to me that under linux 2.4.26 this memory
> > > is not freed also when the process has died! I think that is a
> > > problem in vm in this (quite old) release of Linux but I'd like to
> > > know if someone has already found   this strange behaviour in
> > > glib/Linux.
> >
> > When you call malloc (or realloc, g_malloc, etc.) the memory
> > allocation routines tries to find a large-enough chunk of available
> > memory in the process' data segment.  If no chunk exists, it calls
> > the brk() system call to enlarge the data segment.  When you call
> > free (or g_free) the memory deallocation routines simply make note
> > that that chunk of memory is now available to be re-allocated at a
> > future time.  Very rarely will the process' data segment shrink. 
> > The kernel and vmm only know the size of the process' data segment,
> > they don't care how much of it has been allocated with malloc or how
> > much of it has been freed with free.  So when your program ends, it
> > doesn't matter if you've freed every block or memory or not, the
> > kernel will simply discard the whole data segment, freeing up that
> > much system memory.  Simply terminating a program without freeing
> > memory when an error condition is detected is a common occurrance
> > (e.g. g_new will terminate if it fails) and is often harmless.  So
> > if you think the kernel is not freeing memory when a process dies,
> > it probably has nothing to do with calling free or not. Not freeing
> > memory is mostly a concert in long-lived programs, where repeated
> > calls to malloc without balancing calls to free will eat up more and
> > more memory over time.
> >
> > I hope this info is helpful, or at least not fatally boring.  And to
> > answer your question, no, I haven't noticed any behaviour like
> > that.
-- 
Remember, UNIX spelled backwards is XINU.
                -- Mt.