NetBSD "Bad address" failure (was Re: Third call for platform testing) - Mailing list pgsql-hackers
| From | Tom Lane |
|---|---|
| Subject | NetBSD "Bad address" failure (was Re: Third call for platform testing) |
| Date | |
| Msg-id | 9179.987210991@sss.pgh.pa.us Whole thread Raw |
| In response to | Re: [lockhart@alumni.caltech.edu: Third call for platform testing] (Tom Ivar Helbekkmo <tih@kpnQwest.no>) |
| Responses |
Re: NetBSD "Bad address" failure (was Re: Third call for platform testing)
re: NetBSD "Bad address" failure (was Re: Third call for platform testing) |
| List | pgsql-hackers |
Tom Ivar Helbekkmo <tih@kpnQwest.no> writes:
> Tom Lane <tgl@sss.pgh.pa.us> 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
root@varg.i.eunet.no:/usr/src/sys/arch/vax/compile/VARGvax
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);
}
pgsql-hackers by date: