Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)

Larry McVoy
2004-05-17T15:08:17Z

On Mon, May 17, 2004 at 08:02:48AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 17 May 2004, Larry McVoy wrote:
> >
> > > And at some point earlier in the process you did an fflush(), or somebody
> > > else had written a header of n*PAGE_SIZE + 0x4ff bytes, or something like
> > > that. Since this was the ChangeSet file, I suspect that the "header" is
> > > the checkin-comment section at the beginning, and the "second phase" is
> > > the actual key list thing. You know how you write the ChangeSet file
> > > better than I do.
> >
> > I don't think we flush along the way but let me look. Whoops, you're right,
> > we do. Right where you thought too. But that doesn't explain there being
> > 3 blocks of nulls (there should NEVER be a null in the s.ChangeSet file, we
> > don't compress that, it's always ascii).
>
> No, no, I'm not claiming that _you_ are writing the NUL bytes. I'm

Yes, I know that. But you had a theory that depended on flush and other
than the flush at the header/data boundary I don't see one until we are
done and fclose() the file. So if you were counting on 3 fflush() calls
I don't think that is happening (an ltrace would tell us, tell me if you
want to know for sure and I'll check).

> > But the bigger problem is that you are missing the point that I mentioned
> > elsewhere, we are writing to a tmp file, the tmp file is NOT mmapped.
>
> No, the mmap thing was Andrew's theory. My theory is that regular
> "write()" calls can trigger it through the "commit_write()" function.

OK.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com