Subject: Re: Bug in mmap() for files with holes
To: Bill Stouder-Studenmund <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 11/14/2007 17:34:04
On Wed, Nov 14, 2007 at 02:21:45PM -0800, Bill Stouder-Studenmund wrote:
> On Wed, Nov 14, 2007 at 04:57:16PM -0500, Thor Lancelot Simon wrote:
> > Lots of operating systems, over the years, have had bugs in mmap() such
> > that, for example, writing a byte into a page notionally backed by a
> > file that has a hole in it causes a segfault or bus error.
> > We appear to have such a bug for _reading_ files consisting only of holes;
> > see the program below. Modifying the program to write one byte to the
> > file before the lseek() that extends it causes the segfault to go away.
> Where do you explicitly grow the file? lseek() alone won't change the file
> length. It is legal to lseek() past EOF.
Hm. Yeah, and if I throw a read() in back to the lseek to 0, it does
indeed return 0 bytes: EOF.
> I think what you want to throw in is an ftruncate().
Probably so. Our mmap() page is not sufficiently precise, and I don't
have the posix realtime spec -- that's where it's specified, right? -- so
I don't know if mmap() is supposed to succeed, but accesses then fault,
when the mapping goes past the current EOF. Is that how it is supposed