Fix for memory leak: specify NULL as openinfo parameter when calling

dbopen() to open an NIS map.

Testing with very large maps (e.g. a sample password database with 31,000+
entries) has shown that ypserv will leak memory (ps shows RSS and VSZ
growing to 4000 pages or more) when performing repeated yp_next()s or
a yp_all(). The problem with yp_all() is not immediately obvious since
the ypproc_all service is handled in a child process which exits once
the transfer is finished, but with repeated yp_next()s (like what you
get when you use getpwent() to scroll through the password database),
the parent ypserv grows to enormous size and never shrinks again.

It seems this is related to the HASHINFO parameters I used in yp_dblookup.c,
which I actually stole from pwd_mkdb. Calling dbopen() with the default
parameters (specifying openinfo as NULL) fixes the problem.

I still need to see how this impacts the other NIS tools. I'm also
considering changing from hash to btree databases: the hash database
method doesn't support R_CURSOR, which means yp_next_record() has to
do a lot of ugly work in order to reach an arbitrary location in the
database.

usr.sbin/ypserv/yp_dblookup.c

@@ -29,7 +29,7 @@
  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.
  *
- *	$Id: yp_dblookup.c,v 1.2 1995/12/23 21:35:28 wpaul Exp $
+ *	$Id: yp_dblookup.c,v 1.3 1996/02/04 05:39:35 wpaul Exp $
  *
  */
 #include <stdio.h>
@@ -78,7 +78,7 @@ DB *yp_open_db(domain, map)
 
 	snprintf(buf, sizeof(buf), "%s/%s/%s", yp_dir, domain, map);
 
-	dbp = dbopen(buf,O_RDONLY|O_EXCL, PERM_SECURE, DB_HASH, &openinfo);
+	dbp = dbopen(buf,O_RDONLY|O_EXCL, PERM_SECURE, DB_HASH, NULL);
 
 	if (dbp == NULL) {
 		switch(errno) {