On Wednesday 20 February 2008 17:37, Denys Vlasenko wrote:
> On Wednesday 20 February 2008 11:46, Cristian Ionescu-Idbohrn wrote:
> > > > Yes. We were using uninitialized data on stack.
> > >
> > > Right.
> > >
> > > > Fix is attached. Please test.
> > >
> > > Looks much better.
> > > I'll test on my embedded systems too.
> >
> > I'm still seeing uninitialized data which leeds to segfaults :(
> >
> > I run a quite complicated chain of scripts at startup, on my embedded
> > system.
> >
> > See attached.
> >
> > sh: (A) LINE 5914
> > sh: (B) LINE 5921: name='RCLIB=/sh/dhcp_command_line.sh', name_len=6
> > sh: (C) LINE 5923
> > sh (pid 31) segfaults for page address 00000000 at pc 355a0828
> > Segmentation fault
> >
> > Going back to shell/ash.c svn r21020 gives me a clean startup.
> > So, I think I'll stick to r21020 for now.
>
> Can you try attached patch (on top of previous one)?
> It covers a few more cases where we had uninitialized
> ->next pointers:
>
> - sp = stalloc(sizeof(*sp));
> + sp = stzalloc(sizeof(*sp));
> sp->text = start;
And if it still fails, make both alloc() functions zero out
allocated block:
static void *
ckmalloc(size_t nbytes)
{
- return ckrealloc(NULL, nbytes);
+ return memset(ckrealloc(NULL, nbytes), 0, nbytes);
}
static void *
stalloc(size_t nbytes)
{
...
g_stacknleft -= aligned;
+ memset(p, 0, nbytes);
return p;
}
If this helps, then it's only a matter of finding a ckmalloc/stalloc
which really needs to be ckzalloc/stzalloc.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
