From owner-freebsd-current Sun Feb 25 00:21:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19370 for current-outgoing; Sun, 25 Feb 1996 00:21:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19359 for ; Sun, 25 Feb 1996 00:21:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA09810; Sun, 25 Feb 1996 19:19:23 +1100 Date: Sun, 25 Feb 1996 19:19:23 +1100 From: Bruce Evans Message-Id: <199602250819.TAA09810@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, pst@shockwave.com Subject: Re: Bug in libc/db/hash/hash.c??? Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> Well, I haven't seen it happen here yet, perhaps it only breaks if the water >> in your drain goes the wrong way? Actually, the only reason I could imagine >:-) I thought my computer didn't know that. :-) >> ... >> I've put up on freefall a new revision of hash.c, >> try http://freefall.cdrom.com/~pst/hash.c >> >> This postpones the stat until you've successfully opened the file and then >> just does a fstat. I don't like it, because it adds additional syscall >> overhead, but wtf. >> > >OK, I tried this one and it does work correctly now. I'm not sure how postponing the stat helps. The problem seems to be with concurrent accesses to the database. First cap_mkdb opens it and it gets initialized. This hasn't changed. Then the getcap library opens it and it gets initialized again because the file length is 0. Oops. I noticed a(nother) Heisenbug in the old code. statbuf.st_size isn't initialized if stat() fails. This only matters if stat() fails with an error other than ENOENT. (There is a similar bug involving errno.) Bruce