From owner-freebsd-commit  Sun Sep 24 10:33:17 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id KAA06474
          for freebsd-commit-outgoing; Sun, 24 Sep 1995 10:33:17 -0700
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id KAA06460
          for cvs-all-outgoing; Sun, 24 Sep 1995 10:33:14 -0700
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id KAA06450
          for cvs-gnu-outgoing; Sun, 24 Sep 1995 10:33:12 -0700
Received: from irbs.irbs.com (irbs.com [199.182.75.129])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA06445
          ; Sun, 24 Sep 1995 10:33:07 -0700
Received: (from jc@localhost) by irbs.irbs.com (8.6.12/8.6.6) id NAA03649; Sun, 24 Sep 1995 13:33:01 -0400
From: John Capo <jc@irbs.com>
Message-Id: <199509241733.NAA03649@irbs.irbs.com>
Subject: Re: cvs commit: src/gnu/usr.sbin/ypserv server.c
To: wpaul@freefall.freebsd.org (Bill Paul)
Date: Sun, 24 Sep 1995 13:33:01 -0400 (EDT)
Cc: CVS-commiters@freefall.freebsd.org, cvs-gnu@freefall.freebsd.org
In-Reply-To: <199509241721.KAA06142@freefall.freebsd.org> from "Bill Paul" at Sep 24, 95 10:21:53 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1344      
Sender: owner-commit@FreeBSD.org
Precedence: bulk

Bill Paul writes:
> 
> wpaul       95/09/24 10:21:53
> 
>   Modified:    gnu/usr.sbin/ypserv  server.c
>   Log:
>   phkmalloc strikes!
>   
>   #ifdef out a number of calls to free() left over from the original
>   GNU ypserv implementation. As near as I can tell, the Berkeley DB
>   package does its own garbage collection, hence the caller doesn't
>   have to worry about free()ing the memory returned in the DBT
>   structures during lookups (I'm still not 1005 sure about this:
>   the DB code is very hard to follow. I must use dynamically
>   allocated memory since you can retreive arbitrarily large records
>   from a database, but I'm not sure where it ends up letting go
>   of it). This was not true with GDBM; you had
>   to do your own garbage collection.
>   
>   The general rule is that if you allocate memory inside an RPC
>   service routine, you have to free() it the next time the routine is
>   called since the underlying XDR routines won't do it for you.
>   But if the DB package does this itself, then we don't need to do
>   it in the main program.
>   
>   Note that with the original malloc(), there were never any errors
>   flagged. phkmalloc complained quite loudly.
> 

I have been running 48 hours with all RPC related and read_database()
frees removed and I have no memory leaks.

John Capo
IRBS Engineering