Due to a bogus "memory leak fix" commit made in November, ash is crashing running some shell scripts, notably musl libc's configure script (http://git.musl-libc.org/cgit/musl/tree/configure). The offending commit is: http://git.busybox.net/busybox/commit/shell/ash.c?id=4ba6c5d3ba3d2c7922aff6b5c2e73b8325f1cf17 There is a thread on the mailing list discussing it here: http://lists.busybox.net/pipermail/busybox/2012-December/thread.html#78738 Basically, the original memory leak is unbounded growth of a stack object maintained by ash during long-running nested loops involving redirection. The "memory leak fix" was invalid because it's attempting to free a string not at the top of the stack, and thereby potentially clobbering all other data that was allocated on the stack between that string and the top of the stack. Unless a better fix can be made right away, please just revert the offending commit; a memory leak is at least less of an offense than crashing. I suspect fixing the leak correctly will require dropping the stack-based allocation strategy, possibly replacing it with something akin to talloc. I do not presently have a minimal test case, but the musl configure script can be run outside of the musl source tree and should demonstrate the crash perfectly well.
Created attachment 4712 [details] test-case script
I have a test case which uncover segfault after 4ba6c5d3 commit. It(script) assumes that all busybox binaries must be under /tmp/bb. In case of any other location simply modify the script.
Reverted in git.