From owner-freebsd-stable  Thu Apr 19 17: 9:36 2001
Delivered-To: freebsd-stable@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id E7F2737B42C; Thu, 19 Apr 2001 17:09:27 -0700 (PDT)
Subject: Re: FreeBSD 4.3-RC5 now on ftp.freebsd.org
In-Reply-To: <200104192334.TAA67858@cs.rpi.edu> from "David E. Cross" at "Apr 19, 2001 07:34:35 pm"
To: crossd@srs.cs.rpi.edu (David E. Cross)
Date: Thu, 19 Apr 2001 17:09:27 -0700 (PDT)
Cc: stable@FreeBSD.ORG, developers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20010420000927.E7F2737B42C@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I did look closer, indeed here is a routine that tickels the exact behaviour 
> that I am describing (which does exactly the re-iterate from the top that 
> you describe):

[chop] 
 
> Note: you will need a relatively large database for this, ours is about 2000, 
> but it looks like you will trip over this with just a 400 byte entry.  Yes, I
> know this is inefficient, it is supposed to be, its purpose is to show that
> the data base internally re-uses the pointers, the end effect is that this
> code produces an infinite loop as the "prev" key gets over-written with a more
> distant key then was previously listed.

Uh... when I originally wrote this code, I tested it with a passwd database
of about 30,000 entries (generated from the /etc/passwd file on the
Columbia University AcIS cluster machines, where everybody in the
university has an account). It didn't crash. And I tested it a lot,
not just by dumping it out directly but using a program that queried
ypserv via getpwent().

What I would try here is to create a private buffer somewhere and
copy the "prev" key into that buffer rather that relying on a pointer
into the Berkeley DB library's private memory. This should prevent
the infinite loop problem (though I don't know if it will prevent
the ypserv crashing with a SEGV problem).

> In my attempts to track down this ypserv problem it has come down to the 
> Berkley DB code.  There is simply no other place it could be.  I ave been
> over the ypserv code line by line, and placed numerous debugging statements, 
> it must be the DB code that is thrashing the stack, specifically how ypserv
> is using the Berkley DB code.

Enumerating the contents of a database this way should work. Doing
many many enumerations could be causing a problem, but I'm not sure
how.

I'm going to have to kludge up another sample database, aren't I.

-Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message