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

[Steven Cole <elenstev@mesatop.com>]

On Friday 14 May 2004 09:41 pm, Andrew Morton wrote:
> Lincoln Dale <ltd@cisco.com> wrote:
> >
> > At 02:53 AM 15/05/2004, Andy Isaacson wrote:
> > >That corruption size really does make me think of network packets, so
> > >I'm tempted to blame it on PPP.  Can you find out the MTU of your PPP
> > >link?  "ifconfig ppp0" or something like that.
> > 
> > 1352 bytes coule be remarkably close to the TCP MSS . . .
> > perhaps there is some interaction with ppp where there is an overrun / lost 
> > packet and the TCP window is mistakenly advanced?
> 
> Steve, if it's a memory stomp then perhaps CONFIG_DEBUG_PAGEALLOC and
> CONFIG_DEBUG_SLAB might pick it up.
> 
> It seems awfully deterministic though.
> 
> 
Andy asked me to do the following without ppp, which I did.
The explanation of the odd key is in his previous mail.

#!/bin/sh
x=0
while true; do
        bk clone -qlr40514130hBbvgP4CvwEVEu27oxm46w testing-2.6 foo
        (cd foo; bk pull -q)
        rm -rf foo
        x=`expr $x + 1`
        echo -n "$x "
done

The above caused a failure after the 7th iteration or so.  This time, the
RESYNC/SCCS/s.ChangeSet file didn't have any nulls, but three other
files did, namely s.Makefile, s.CREDITS, s.MAINTAINERS.  Not knowing
whether this was normal or not, I've sent those files to bitkeeper for
analysis.

Since I only began seeing these "Assertion `s && s->tree' failed" problems
with bk in the past month or so, and I generally run a current kernel
on this machine, I booted an older kernel, 2.6.3.  I'm going to run
Andy's test overnight and see if 2.6.3 acts any differently.

In the meantime, I'll have the machine building a 2.6.6-plus kernel
with CONFIG_DEBUG_PAGEALLOC and CONFIG_DEBUG_SLAB if its
use seems indicated in the morning.

Steven