Weird signal issues using yocto's warrior busybox (aarch64) when memory is cached

[Sergio Paracuellos]

Hi,

On Thu, Jan 30, 2020 at 1:42 PM Bernd Petrovitsch
<bernd at petrovitsch.priv.at> wrote:
>
> Hi all!
>
> On 30/01/2020 11:09, Sergio Paracuellos wrote:
> [...]
> > On Thu, Jan 30, 2020 at 11:37 AM Bernd Petrovitsch
> > <bernd at petrovitsch.priv.at> wrote:
> [...]
> >> "bt f" (short for "backtrace full") delivers more information.
> >
> > I tried also this command and the backtrace was the same, no extra info :-(.
>
> Ah, OK - I use only "bt f" (and don't remember why;-).
>
> [...]
> >> Another idea is - similar to valgrind - run the script
> >> with `strace -o strace.tst -F -F --" and see if the (last few)
> Ooops, should have been "-F -f" (yes, newer versions of strace warn
> on both).

Thanks, will try this also.

>
> >> called sys-calls and their parameters make sense.
> >> You may need "bash -c" and/or "sh -c" or similar ...
> >>
> >>> There are no oops and anything but the audit trace in the kernel side,
> >>> and also I am not successful trying to reproduce this bug running a
> >>
> >> Hmm, so it's
> > ??
>
> Ooops: Hmm, so it happens for busybox-sh and GNU-bash.
> Then it's not really busybox-specific but since it's
> reproducible we should hunt it down.

I do think that the bash receives a SIGSEGV because busybox sleep command is
launched from it. First SIGSEGV is always in a command linked to
busybox.nosuid (normally sleep)

>
> [...]
> > Thanks for your effort in this.
>
> De nada - I'm doing such stuff for money;-)

:-)

Best regards,
    Sergio Paracuellos

>
> MfG,
>          Bernd
> --
> "I dislike type abstraction if it has no real reason. And saving
> on typing is not a good reason - if your typing speed is the main
> issue when you're coding, you're doing something seriously wrong."
>     - Linus Torvalds