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
to work?

Thor