[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is malloc garbage collecting?

From: Marcus Brinkmann
Subject: Re: Is malloc garbage collecting?
Date: Sun, 14 Apr 2002 12:58:56 -0400
User-agent: Mutt/1.3.25i

On Sun, Apr 14, 2002 at 06:45:29PM +0200, Wolfgang J?hrling wrote:
> Wolfgang J?hrling <> wrote:
> > Wolfgang J?hrling <> wrote:
> > > Looking at what glibc/hurd/fd-read.c does, it seems to be a leak to not
> > > check for equality and freeing the buffer. Does anyone agree/disagree?
> > 
> > Well, I think I have to disagree with me here. :*)
> And I think that Wolfgang was right (Uh, I'm feeling a bit schizophrenic
> today %-)), because the following program does not segfault:

I have no time to look into the various example code and tell which is
right or not.  But I can tell you some general rules:

1.  When programming in C, all resources that are not released by
someone else have to be released by yourself (well, obviously :)
2.  Usually, nobody does it for you.  In particular, there is no
general garbage collector unless you use one.
3.  Sometimes library functions consume a resource.  In this case you
should not free it.
4.  Sometimes library functions allocate resources for you.  In this
case you have to free it yourself.

Now specifically to the Hurd: io_read uses the Mach buffer return
semantics.  This means that you can provide a buffer, and it might be
used and filled with the data.  But you might also pass 0 if you don't
allocate a buffer.   In any case (regardless if you provide your own
buffer or not, and regardless of its size), the caller might provide you
with a different buffer, and fill that.  In this case you will notice
that the buffer pointer was changed.  If you provided your own buffer,
you have to free it yourself of course.  If you got a different then
your own buffer back, you have to free that one also after using the

One important case where you might get a different buffer back is if your
provided buffer was too small.  However, even that is not definite, some
kernel RPCs use the size of the buffer to switch compatibility modes.
(eg the various _status RPCs).  There is no definite rule for this, you
always have to check the buffer pointer and return value to see what
happened.  In the Hurd, a different buffer is usually only allocated it
the provided buffer was too small.

This is the client side.  Now the server side: For servers, the
situation is very convenient, because mig does some of the work for you.
If you allocate your own buffer, you can just return that and don't care
about the buffer passed to you by mig.  In this case, there are two
options:  You want mig to copy this data, or you want it to consume the
data.  Sometimes you want to make this decision at runtime.  If you give
the dealloc flag, then mig will consume the data, and the buffer will
be freed when MiG has copied it to the client.  Otherwise, MiG will
assume that the server needs the data later on itself, and will not free
it.  you can even make mig to have another parameter in the server stub
that allows you to specify if you want to have the data consumed or not
by mig on a per-call basis, but I forgot how (hell, given my current
state of memory it could even be that this is the default already ;)
See the server writer manual for details on that.

So, if you don't want to leak memory on the client side, always release
any buffer you allocated or get from mig.  If you don't want to leak
memory on the server side, use dealloc for buffers you allocate when
processing the RPC and are returned to the caller (realize that
otherwise you can not garbage collect this data if you don't store away
the information about it somewhere else), or if you return data buffers
that are used longer than just for one RPC reply, you can leave dealloc
out to avoid having MiG releasing it.  (I think we do this in auth
right, where I think we are still violating some rules of being sane,
because we return non-page aligned buffers allocated with malloc).
(I am also not sure if trailing data on the last page is visible to the
caller under some circumstances, which would be a potential security


reply via email to

[Prev in Thread] Current Thread [Next in Thread]