On 9 Sep 1998, Chris G. Demetriou wrote:

> Todd Vierling <tv@pobox.com> writes:
> > On Wed, 9 Sep 1998, Ryan Ordway wrote:
> > : > Um, that shouldn't make sshd, for instance, core-dump.  If that was
> > : > happening, it dounds like (1) the device lookup code for /var/db/kvm.db is
> > : > core-dumping or (2) kvm_mkdb was making a bogus file.  In either case, I
> > : > think something is broken there, and I never really liked the Berkeley-DB
> > : > format kvm.db.  :>
> > : 
> > : 	Yeah, kvm_mkdb dumped core first, which I am guessing is why the
> > : others dumped core. If someone would like, I can put it up for anon ftp.
> > 
> > Probably not a big matter, but the kvm_db stuff really needs to be rethought
> > (that was my original point :).
> 
> huh?  what are you talking about?
> 
> approximately _none_ of those programs (other than kvm_mkdb;
> specifically i'm thinking: sshd, getty, sh, etc.) should be using the
> kvm database.

	Right.

> instead, you'll note that they are all likely to use db bits, which
> have recently been updated to use pread, etc.
> 
> I'd be interested to know:
> 
> * what versions of kernels (and with what names) worked with what
> versions of libraries

	Actually, the problem is that I first booted it, named
/netbsd.BRAHMS-4 (config BRAHMS #4)... which confused things, I am
guessing. The same kernel named /netbsd works just fine.

> I.e. an explicit list.
> 
> To be quite honest, the lossage sounds like it could be from using a
> new libc with an old kernel, rather than anything else.  (that
> shouldn't be generating seg-faults, though, I don't think.)

	Nope, same libc (errr... 1.3F-ish), testing new 1.3H kernel. But
close ;-)

	Ryan

--
HELO... my name is rewt... you have SIGKILLed my father... prepare to vi!