Hi all!
On Thu, 2020-01-30 at 06:53 +0100, Sergio Paracuellos wrote:
[...]
> So I tried to get a backtrace of those two using the cores and this
> two binaries:
>
> $
> /opt/poky/2.7.2/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gdb
> /home/sergio/YOCTO/tools/yocto/workspace/build/tmp/work/oberonx-poky-linux/oberonx-image/1.0-r0/rootfs/bin/busybox.nosuid
> core.23217
> GNU gdb (GDB) 8.2.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "--host=x86_64-pokysdk-linux
> --target=aarch64-poky-linux".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>;.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>;.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> /home/sergio/.gdbinit:1: Error in sourced command file:
> Undefined command: "layout". Try "help".
> Reading symbols from
> /home/sergio/YOCTO/tools/yocto/workspace/build/tmp/work/oberonx-poky-linux/oberonx-image/1.0-r0/rootfs/bin/busybox.nosuid...(no
> debugging symbols found)...done.
>
> warning: core file may not match specified executable file.
> [New LWP 23217]
>
> warning: Could not load shared library symbols for 3 libraries,
> e.g. /lib/libm.so.6.
> Use the "info sharedlibrary" command to see the complete listing.
> Do you need "set solib-search-path" or "set sysroot"?
I don't know yocto (apart from reading about it;-) but perhaps
they have a template .gdbinit file (or docs) somewhere for
this.
> Core was generated by `sleep 1'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0xfffffcd7fffffc60 in ?? ()
> (gdb) bt
"bt f" (short for "backtrace full") delivers more information.
It's perhaps also more helpful if gdb can resolve the shared
libraries and have the symbols somewhere (so that we get the
somewhat exact location ine th source code).
And for the 2nd core file (from bash) too.
Perhaps there are similarities ...
> #0 0xfffffcd7fffffc60 in ?? ()
> #1 0x000000555668af74 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
[...]
Another idea is - similar to valgrind - run the script
with `strace -o strace.tst -F -F --" and see if the (last few)
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
> similar program in C like the following:
>
> #include <unistd.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <stdio.h>
>
> static void sig_handler(int signo)
> {
> printf("Sygnal catched: %d\n", signo);
Typo;-)
> exit(1);
> }
>
> int main(void)
> {
> signal(SIGINT, sig_handler);
> signal(SIGSTOP, sig_handler);
That fails (at least according to the manual page).
> while (1) {
> printf("Testing stuff\n");
> sleep (1);
> }
>
> return 0;
> }
>
> So it seems to be a possible stack corruption with busybox.
To state the obvious: If it is, the question is where
it comes from...
[...]
MfG,
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
