fluff (filemgr) bug

[caminati]

I have experienced crashes on fluff (like others, see threads 8581.0 and 7945.0), and tried to track down the issue. Probably it would be more appropriate to report on sites hosting fluff source code, but I haven't found a way, so here's what happens to me.

It looks like that:

• if a folder contains a file of 140 or 141 name length, fluff does not display that file
• if it contains a file of length 142 characters or more, fluff crashes upon opening that directory

I managed to recreate the problem with fluff version 0.8.9 (taken from Mike's post on google sites) with something like (fiddle with the 142 to explore the bug):

Code: [Select]

cd /tmp/testdir/; touch $(for i in $(seq 1 142); do echo a; done | tr -d "\n")
Now, upon visiting testdir with fluff, it behaves buggly.

Further specs: I'm running microcore 3.4.1; uname -a outputs: Linux box 2.6.33.3-tinycore #2012 SMP Wed May 12 17:05:42 EEST 2010 i686 GNU/Linux

I wish to express my appreciation for Mike's outstanding work on tiny code gems.

[tinypoodle]

Potentially related:

http://forum.tinycorelinux.net/index.php?topic=7115.msg42805#msg42805

[MikeLockmoore]

Thanks for the bug report and initial investigation.  I probably cannot get to looking at this in detail for at least a day or two.  I'll post again soon!
--
Mike Lockmoore

[MikeLockmoore]

A short update: I was able to reproduce the crash with the standard build.  I rebuilt the code with debugging symbols so I could get more information about the crash using GNU debugger (gdb), but when I run the debug build, it does not crash with the 142-character filename.    However, the file is listed at least twice in the file detail list... and if you switch to another directory, then come back to the same one, the file is repeated even more times. And so on and so forth!  

This one is going to take a bit more work to troubleshoot.  

OK, maybe not too much more.    I built with debug symbols and normal optimizations.  That version still crashed, and I was hoping to find a stack trace to help me isolate the bug.  When I used a 200-character name, I saw a massively corrupted stack that contained a lot of the filename data itself... a symptom of a classic buffer overrun bug for an array allocated locally (in a stack frame).  The 142-character filename length reported by caminati still caused a crash, but I was able to view the stack trace to find out where it crashed.  It was in the new_item_sorts_before_existing_item() function, where some local arrays for filenames were only allocated with with 128 bytes, while a filename can be up to 255.

I have created a new 0.9.0 version that has now full-sized local buffers for these filenames.  I also expanded a few other local buffers in other functions that could be vulnerable to the same type of bug.  I tested this version with the 142 and 200-character filenames that crashed before and they work with no problems (yet?).  You can even expand the file name column in the detail window if you want to see the entire name.

New source is now posted at http://retrospectiva.krautsoft.de/projects/useful-lightweight-software/blog.

Thanks again caminati for reporting this bug.  You just helped make Fluff even stronger.  (Even if that does sound like an oxymoron if taken out of context  ).
--
Mike Lockmoore

[curaga]

while a filename can be up to 255.

Don't count on that Just because it's mostly true now, might not be a year or two on. [See Reiser4]

[MikeLockmoore]

Don't count on that  Just because it's mostly true now, might not be a year or two on. [See Reiser4]

Yikes!

I wonder if there is some fairly standard way I can query the size of each filename before I attempt to retrieve it.  Then Fluff could allocate storage space for each name in a more memory-efficient way, but still handle extreme cases like >255 characters.
--
ML

[curaga]

I would use the NAME_MAX define (from limits.h).

[MikeLockmoore]

@curaga: Yes, good idea.  I was thinking that very thing.