[Aboriginal] Merry christmas, I have found two bugs
bjorn.forsman at gmail.com
Wed Jan 9 23:18:48 PST 2013
On 27 December 2012 14:30, Rob Landley <rob at landley.net> wrote:
> On 12/26/2012 04:23:06 PM, Bjørn Forsman wrote:
>> On 26 December 2012 22:36, Rob Landley <rob at landley.net> wrote:
>> > On 12/26/2012 02:55:04 PM, Bjørn Forsman wrote:
>> >> And now I think I've found two bugs. Bug 1 is
>> >> a segmentation fault during system image boot:
>> >> $ cd build/system-image-avmv5l
>> >> $ ./run-emulator.sh
>> >> [...]
>> >> Freeing init memory: 96K
>> >> Segmentation fault
>> >> 8139cp 0000:00:0c.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
>> >> Not using distcc.
>> >> Type exit when done.
>> >> (armv5l:1) /home #
>> >> Not sure what exactly is segfaulting, but segfault == bug to me. And
>> >> it only happens with ./run-emulator.sh, not ./dev-environment.sh.
>> > There are somewhat different code paths in the init.sh shell script so
>> > it's
>> > probably something only running in the first case. I need to rebuild the
>> > armv5l target to test this, that'll take a few minutes...
> Still grinding away on this. It's... weird.
> If I run_emulator.sh with KERNEL_EXTRA=init=/bin/bash and then exec
> /sbin/init.sh it does _not_ segfault. It doesn't do so with init=/bin/bash
> or init=/bin/ash. But it _does_ do so when init=/sbin/init.sh when that
> starts with #!/bin/bash or #!/bin/ash.
> So it only happens when the script is run as the first process. Not just as
> PID 1, as the _first_process_. If you exec a shell that execs the script, it
> doesn't segfault.
> So the same thing happening with two different shells, but only from a very
> specific execution environment. Is there some asynchronous kernel thread
> that happens to damage whatever's running at the time it completes? Add a
> sleep 1" before the if CPU block... no difference.
> Back up, confirm whether ash or bash IS running, add an ls -l /proc/self/exe
> and it says... toybox. Sigh. Make that ls -l /proc/1/exe (ask about the
> _shell_ not the ls process) and it says... /bin/bash. And when I switch the
> #! line to ash it... isn't segfaulting?
> Hang on, according to "hg diff" the initial version wasn't #!/bin/ash it was
> #!/bin/sh which points to _bash_. So I switched it from bash to bash, which
> is an invalid test. So it's NOT a bug affecting both shells (and thus
> probably some libc thing with setsid or who knows what), it's a BASH BUG.
> Given how old the version of bash I'm using is, and that I've already had to
> fix deep obscure bugs in it before (the backstory behind
> http://landley.net/hg/aboriginal/rev/de8e06350227 is long and epic and
> described in my blog over a course of weeks), I think the correct fix is
> #!/bin/ash (and eventually #!/bin/toysh).
Oh, I forgot to say thanks for looking into this. I appreciate it.
More information about the Aboriginal