Regression in ash (crashing)

Rich Felker dalias at aerifal.cx
Wed Dec 12 19:10:14 UTC 2012


On Wed, Dec 12, 2012 at 02:02:00PM -0500, Rich Felker wrote:
> On Wed, Dec 12, 2012 at 08:23:34PM +0300, Leonid Lisovskiy wrote:
> > On Wed, Dec 12, 2012 at 8:19 PM, Rich Felker <dalias at aerifal.cx> wrote:
> > > Can we take this back on-list?
> > 
> > Of course, yes.
> > My suggestion - try to use valgrind(or any similar tool) to track
> > origin of uninitialized value. In my case it was point to copyfunc().
> > After that add debug print of node type and, I hope, we can finally
> > fix all cases.
> 
> Just to be more reproducible, I built latest busybox on a glibc
> system, and it crashes even earlier. The crash is from path_advance
> where it performs memcpy to the block obtained by stackblock(). The
> address it's writing to is not an address but ASCII characters being
> interpreted as an address.
> 
> Valgrind isn't working well because it's static linked. I'll try again
> with dynamic linking.

With dynamic linking and the patch from this thread applied, the first
error valgrind reports is the one that causes the crash:

==6126== Invalid read of size 1
==6126==    at 0x80675F8: evaltree (in /home/dalias/src/busybox/busybox_unstripp
==6126==  Address 0x6e5c7325 is not stack'd, malloc'd or (recently) free'd

I don't think valgrind is going to be a big help because the invalid
alloc/free logic seems to be not at the system malloc level but ash's
stack allocator. Is there any way to get ash to just use malloc/free
for everything so valgrind can detect the invalid usage pattern?

Rich


More information about the busybox mailing list