Hi Bernd, On Thu, Jan 30, 2020 at 11:37 AM Bernd Petrovitsch <[email protected]> wrote: > > 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.
Not really, there only few instructions to be able to use gdb for local an remote debugging (add links just in case you have interest to look into it): https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#platdev-gdb-remotedebug https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#debugging-with-the-gnu-project-debugger-gdb-on-the-target > > > 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. I tried also this command and the backtrace was the same, no extra info :-(. > 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 ... I'll try to add debug symbols for these two and see if we can get more info about this, thanks. > > > #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;-) Good catch ;) > > exit(1); > > } > > > > int main(void) > > { > > signal(SIGINT, sig_handler); > > signal(SIGSTOP, sig_handler); > > That fails (at least according to the manual page). Well, maybe true and I am not controlling return of these syscalls but it is enough for me to be able to ctr +c program with the SIGINT one :) > > > 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... That's what I want to know also :-). > > [...] > > MfG, > Bernd Thanks for your effort in this. Best regards, Sergio Paracuellos > -- > Bernd Petrovitsch Email : [email protected] > LUGA : http://www.luga.at > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
