Re: JFFS2 eats memory

["Øyvind Harboe" <oyvind.harboe@zylin.com>]

On Wed, 2004-07-21 at 00:08, David Woodhouse wrote:
> On Tue, 2004-07-20 at 20:52 +0200, Øyvind Harboe wrote:
> > I caught it in gc.c where at some point the code assumes that gc_node
> > does not change beneath it. Don't remember.
> 
> Hmmm. That sounds like it could break anyway. Can you be more specific?

1. Set jeb->gc_node = NULL; at the end of jffs2_mark_node_obsolete(); 

2. fire up the debugger and start writing to the JFFS2 disk.

3. See below...

in gc.c:

	240	
-	241		if (!raw->next_in_ino) {
 	242			/* Inode-less node. Clean marker, snapshot or something like
that */
 	243			/* FIXME: If it's something that needs to be copied, including
something
 	244			   we don't grok that has JFFS2_NODETYPE_RWCOMPAT_COPY, we
should do so */
 	245			spin_unlock(&c->erase_completion_lock);
-	246			jffs2_mark_node_obsolete(c, raw);
-	247			up(&c->alloc_sem);
-	248			goto eraseit_lock;
 	249		}
 	250	

----- Here raw == NULL, hence jffs2_raw_ref_to_ic() crashes.

-	251		ic = jffs2_raw_ref_to_ic(raw);


> Also, memset the raw_node_ref to 0xdeadbeef before you free it. (Or run
> with slab poisoning enabled in Linux). We should go through the code and
> make sure manually that nothing's going to dereference a pointer to the
> old node after it's freed, but the poisoning is a quick and useful
> debugging aid.

eCos, which I'm using, has this facility built in:
CYGDBG_MEMALLOC_ALLOCATOR_DLMALLOC_DEBUG 


-- 
Øyvind Harboe
http://www.zylin.com