RAM and ext2
Stefan Sperling
stsp at stsp.in-berlin.de
Sun Apr 8 13:02:40 CEST 2007
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
More information about the dslinux-devel
mailing list