RAM and ext2

[Stefan Sperling]

On Sun, Apr 08, 2007 at 12:17:10PM +0200, Amadeus wrote:
> Stefan,
> 
> On Sonntag, 8. April 2007, Stefan Sperling wrote:
> > Of course I'd like to see it fixed, too.
> > If you want it fixed, then by all means, do fix it!
> 
> Right now, I am doing a "make" in the toolchain directory.... c++

:-)

Good luck!

> > But I've already spent two long weekends on this bug with no result.
> 
> Whow. Can you explain what you have done and where you stopped?

It's been a while... I wish I had taken notes now.

All I remember straight off my head is that there's a call to
strcpy() (or strlen?) that crashes because it's being passed garbage
(i.e. the string is total nonesense and not terminated).

The following might be incorrect, I'm not sure!

If I remember correctly I traced it down to a while loop in the
exe_n_cwd_tab_completion() function in busybox/shell/cmdedit.c:

It starts like this:

       while ((next = readdir(dir)) != NULL) {

I'm not really sure now but the only strcpy() call in that loop
is this one:

          /* find with dirs ? */
            if (paths[i] != dirbuf)
                strcpy(found, next->d_name);    /* only name */

next->d_name comes from uClibc obviously.

But the failing call to strcpy() might have been nested a few levels
deeper as well. But I think it definitely had to do with reading
dirents.
 
> I think hunting bugs in DSLINUX is hard work, and it may be good if we 
> can do something about it!

I would LOVE to have any kind of debugger working.
I've looked at gdbserver once but it does not seem to support arm/nommu :(

> > This is where it crashes in strcpy()
> > alright, but as far as I can tell it crashes because it got a
> > malformed string from somewhere else.
> 
> What else? uClibc?

I don't know where the string is generated. I tried to find it for ages
and gave up. I think I lost it in the kernel. I dumped the string in hex
and looked at it in hex and ascii. It could not make sense of it at
all. Of course I did not keep a copy, sorry :(

> > I don't see a problem here. FAT support will not be dropped,
> > so everyone will be able to make their own choice about what
> > filesystem to use. This is a good thing. I don't see a problem
> > with adding a feature for power users, especially if it does not
> > affect causual users in any way.
> 
> Hm. We have 2 builds with GBA ROM space as RAM now: the RAM build and 
> the DLDI build (+Memory Expansion Pack). They are not compatible. If we 
> add ext2, we have 4.

Or 3, if DLDI does not get ext2 support. If people want that as well
someone else will have to do it or donate/lend a slot-1 device because
I don't have one and I'm not going to invest in one.

And yes, I want to keep the number of builds down, too.
Ideally, we'd only have one type of build...

But if there's a significant advantage of creating a seperate
build I'll go for it and maintain the extra build.
 
> Can you think of a solution which does not increase the number of 
> builds?

See suggestion #2:

2.      Make the RAM build support both vfat and ext2.
        Either one mounted at /media.

But I am still not sure if we should rather go for ext2 as root
filesystem to get rid of the read-only romfs. I also see #2 as a very
viable option though, because it keeps things similar to what we currently
have and does not require very large modifications. I'm undecided.
That's why I started this thread basically, to bounce ideas about that.

-- 
stefan
http://stsp.in-berlin.de                                 PGP Key: 0xF59D25F0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.dslinux.in-berlin.de/pipermail/dslinux-devel-dslinux.in-berlin.de/attachments/20070408/2962102e/attachment.pgp