re: NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)
yes, this is a bug in netbsd-current that was introduced with about 5 month ago with the new unified buffer cache system. it has been fixed. thanks. From: Chuck Silvers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: CVS commit: syssrc Date: Mon, 16 Apr 2001 17:37:44 +0300 (EEST) Module Name:syssrc Committed By: chs Date: Mon Apr 16 14:37:44 UTC 2001 Modified Files: syssrc/sys/nfs: nfs_bio.c Log Message: reads at or after EOF should "succeed". To generate a diff of this commit: cvs rdiff -r1.65 -r1.66 syssrc/sys/nfs/nfs_bio.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)
Tom Lane [EMAIL PROTECTED] writes: I think this is indisputably a bug in (some versions of) NetBSD. I forgot to mention a possible contributing factor: the files involved were NFS-mounted, in the case I was looking at. So this may be an NFS problem more than a NetBSD problem. Anyone want to try the given test case on NFS-mounted files on other systems? I can verify, that with NetBSD-current on sparc, your test code works the way you want it to on local disk, but fails (in the way you've observed), if the target file is on an NFS-mounted file system. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)
Tom Ivar Helbekkmo [EMAIL PROTECTED] writes: I can verify, that with NetBSD-current on sparc, your test code works the way you want it to on local disk, but fails (in the way you've observed), if the target file is on an NFS-mounted file system. FWIW, the test program succeeds (no error) using HPUX 10.20 and a couple different Linux flavors as either client or server. So I'm still thinking that it's NetBSD-specific. It would be useful to try it on some other BSD derivatives though ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)
Tom Ivar Helbekkmo [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
+ ERROR: cannot read block 3 of hash_i4_index: Bad address
"Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms.
The above was on sparc64, but that same problem is the only one I see
in the regression testing on NetBSD/vax that isn't just different
floating point (the VAX doesn't have IEEE), different ordering of
(unordered) collections or different wording of strerror() output.
NetBSD/i386 doesn't have the "Bad address" problem.
After looking into it, I find that the problem is this: Postgres, or at
least the hash-index part of it, expects to be able to lseek() to a
position past the end of a file and then get a non-failure return from
read(). (This happens indirectly because it uses ReadBuffer for blocks
that it has never yet written.) Given the attached test program, I get
this result on my own machine:
$ touch z -- create an empty file
$ ./a.out z 0 -- read at offset 0
Read 0 bytes
$ ./a.out z 1 -- read at offset 8K
Read 0 bytes
Presumably, the same result appears everywhere else that the regress
tests pass. But NetBSD 1.5T gives
$ touch z
$ ./a.out z 0
Read 0 bytes
$ ./a.out z 1
read: Bad address
$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
[EMAIL PROTECTED]:/usr/src/sys/arch/vax/compile/VARG vax
I think this is indisputably a bug in (some versions of) NetBSD. If I
can seek past the end of file, read() shouldn't consider it a hard error
to read there --- and in any case, EFAULT isn't a very reasonable error
code to return. Since it seems not to be a widespread problem, I'm not
eager to change the hash code to try to avoid it.
regards, tom lane
#include stdio.h
#include errno.h
#include fcntl.h
#include unistd.h
int main (int argc, char** argv)
{
char *fname = argv[1];
int fd, readres;
long seekres;
char buf[8192];
fd = open(fname, O_RDONLY, 0);
if (fd 0)
{
perror(fname);
exit(1);
}
seekres = lseek(fd, atoi(argv[2]) * 8192, SEEK_SET);
if (seekres 0)
{
perror("seek");
exit(1);
}
readres = read(fd, buf, sizeof(buf));
if (readres 0)
{
perror("read");
exit(1);
}
printf("Read %d bytes\n", readres);
exit(0);
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: NetBSD Bad address failure (was Re: [HACKERS] Third call for platform testing)
I wrote: I think this is indisputably a bug in (some versions of) NetBSD. If I can seek past the end of file, read() shouldn't consider it a hard error to read there --- and in any case, EFAULT isn't a very reasonable error code to return. Since it seems not to be a widespread problem, I'm not eager to change the hash code to try to avoid it. I forgot to mention a possible contributing factor: the files involved were NFS-mounted, in the case I was looking at. So this may be an NFS problem more than a NetBSD problem. Anyone want to try the given test case on NFS-mounted files on other systems? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
