Hi Ross

Thanks for that patch.

I had a look and have come up with an alternative solution to the problem: 
instead of trying to unwind a half created object if the string or tnode 
malloc fail it is a lot cleaner to reverse the order of allocation. ie forst 
create the tnode or string, then create the object if that succeeds.

I also had a sniff around and found a few other areas where tnode creation 
failures would cause issues.

The fixed stuff has been running in a stress test for almost 24 hours and I've 
just checked that in. 
http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_guts.c?r1=1.93&r2=1.94

I also put a day or so into extending low mem testing and will expand the 
tests more.

Thanks

-- Charles


On Friday 30 October 2009 06:35:32 Ross Younger wrote:
> Whilst doing some stress testing on a board with limited RAM, I tripped
> over an assertion failure.
>
> In yaffs_CreateNewObject, YAFFS would sometimes successfully
> AllocateEmptyObject but not be able to allocate a new tnode, so GetTnode
> returned 0. It would then immediately attempt to FreeObject, but the
> freshly allocated object already has a parent so it hits the YBUG trap at
> line 1992 of yaffs_guts.c.
>
> I attach a patch which fixes this assertion (and a similar case I spotted
> in yaffs_MknodObject) by calling DoGenericObjectDeletion instead of
> FreeObject, though it might instead be reasonable for AllocateEmptyObject
> to not try to add the object to the rootDir or lostNFoundDir.
>
>
> Ross