Charles,

Thanks for a quick reply.

On Tuesday 09 October 2007 21:03, Charles Manning wrote:
> Can you clarify as per the question below...
>
> On Wednesday 10 October 2007 09:55:12 Ian McDonnell wrote:
> > Yaffers,
> >
> > [it's my turn to ask for help!]
> >
> > We're using yaffs_guts.c revision 1.10 circa 2005/07/26 from
> > yaffs2 cvs on a well established product. We are getting a
> > few cases of a crash/oops during the scan (small page). It
> > crashes in yaffs_AddObjectToDirectory called from yaffs_Scan
> > -- there's a bad pointer in parent directory children list,
> > so the call to list_add() oops's.
> >
> >
> > NAND state is such that during the scan yaffs finds:
> >
> > 1) a file object header (call it object A) who's
> >    parent ID is 4, the deleted-file-dir.
> >
> > 2) further on several data chunks belonging to object A
> >    are seen -- the in-core data for object A created
> >    in (1) was freed (cuz the parent was deleted(id=4)),
> >    so now a new object A is created, and because this
> >    step has found data chunks, the new A has type=file.
> >
> > 3) further on a directory object is seen with the same
> >    ID as A.  This is not good, and deserves investigation
> >    of it's own, BUT I don't expect yaffs to crash.
>
> That is not good. There should only be one of these.
>
> Question: Is this object also in the deleted-files directory?

No, I don't think so, this directory would have contained three
live files -- I had printed out the directory's name, so know
what it would have contained.

[I've now lost the NAND state and have to try to reproduce the 
problem again. I had disabled NAND writes to avoid losing this 
failed state, but I didn't disable erase (doh), so that's 
propably the reason why I lost the error state. A while back, 
when looking into another issue, I started out by taking a dump 
of NAND but ran into problems trying to restore data/oob -- MTD 
utils don't do this well. This time I thought disabling writes 
would save me, ho-hum].

> > When the scan gets to (3) is sees that the object has
> > changed type and calls yaffs_DestroyObject(in) in the
> > section with the comment "This should not happen..." to zap
> > the existing object.
> >
> > Scan the goes on and calls yaffs_FindOrCreateObjectByNumber
> > with the second objectId 'A' now with type=dir.  Things go
> > bad when yaffs_AddObjectToDirectory is later called because
> > the directory object was incorrectly (re)initialized when it
> > morphed from a file into a directory -- this is why the
> > child list pointers are junk.
>
> Question: Does it looks like this directory should be a "live"
> object with other files in it?

Yes, see above.

> If so, it looks like the real problem is that the somehow the
> directory object got created before the file object was
> deleted. I'll take a look as to how that could have happened.

I read it differently -- looks to me like the original file with 
objectId A got relinked to the deleted-file directory when VFS 
unlinked it and at this point it's on-NAND data was updated to 
have ID 4 as the parent obj. But the data chunks belonging to 
the file would not have been marked on-NAND, just soft deleted, 
so they are seen during the scan, and a new 'prototype' file 
object is created with objectId A. This then clashes with the 
directory objectId A, which I presume was created after the 
original file objectId A was (soft) deleted. Does this make any 
sense?

-imcd