Date: Sun, 25 Feb 1996 19:19:23 +1100 From: Bruce Evans <bde@zeta.org.au> To: jhay@mikom.csir.co.za, pst@shockwave.com Cc: freebsd-current@freebsd.org Subject: Re: Bug in libc/db/hash/hash.c??? Message-ID: <199602250819.TAA09810@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602250819.TAA09810>