On Wednesday 04 February 2009 14:03, Cristian Ionescu-Idbohrn wrote:
> On Wed, 4 Feb 2009, Denys Vlasenko wrote:
>
> > On Tuesday 03 February 2009 20:43, Cristian Ionescu-Idbohrn wrote:
> > > On Sat, 31 Jan 2009, Denys Vlasenko wrote:
> > >
> > > > if (p==NULL) bb_error_msg("p is NULL at %d!", __LINE__)
> > > > ========> expdest = stack_nputstr(p, length, expdest);
> > >
> > > None of the CONFIG_ tweaks led to anything catchable. It's a moving
> > > target :(
> > >
> > > > Let me know what do you see.
> > >
> > > Though, I managed to isolate the problem to the transition from 1.11.3
> > > where ash doesn't segfault in the tested environment, to 1.12.0 (with
> > > applied fixes).
> >
> > So, busybox-1.12.4 (latest 1.12.x) segfaults.
> >
> > Does busybox-1.12.4 with the attached patch reverted works?
> > It should, because this patch returns ash.c to 1.11.3 state.
>
> I see what you mean.
> 1.12.4 with the named patch applied segfaults :(
These are good news! Figuring out where ash broke would be worse.
Download busybox-1.11.3 and 1.12.4, rediff. The diff will be huge.
Let's make it smaller first.
Run this:
grep -rl "ATTRIBUTE_UNUSED" . \
| while read filename; do
sed "s/ATTRIBUTE_UNUSED/UNUSED_PARAM/g" -i $filename
done
grep -rl "ATTRIBUTE_NORETURN" . \
| while read filename; do
sed "s/ATTRIBUTE_NORETURN/NORETURN/g" -i $filename
done
grep -rl "FAST_FUNC" . \
| while read filename; do
sed "s/\* FAST_FUNC/ */g" -i $filename
sed "s/ FAST_FUNC//g" -i $filename
sed "s/FAST_FUNC //g" -i $filename
done
in each tree. Build both and check that 1.11.3 still works
and 1.12.4 still fails. (If it doesn't, these changes are
the reason!)
Now the diff is "only" 950627 bytes
Split it by directory:
root.diff
applets.diff
archival.diff
console-tools.diff
...
util-linux.diff
Apply only those patches which are needed for ash:
root.diff
include.diff
shell.diff
(maybe more, if with only these build fails)
Build both and check that 1.11.3 still works
and 1.12.4 still fails.
I'm afraid starting from there you will need to
split these three patches into smaller pieces
and continue bisecting the bug.
It's long and not interesting work, but it's not requiring
you to actually think much, it's mechanic, and in the end,
it's bound to success - you will find a small change which
causes it.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
