• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 1881 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3359: Callstack of SIGABORT

Ondrej Kucharik
Prodigy 40 points
Part Number: AM3359


Tool/software: Linux

Hi community,

I develop a multithreaded application on arm platform ( TI AM335X (3359) ) and I got an issue with debugging coredumps.
In the raising SIG ABORT in one of the thread, I'm not able to catch the signal at an usefull place. I can catch it only in signal handler but it is too late. The signal handler is in the main().
There is no stack from the originating thread. I can see only callstack from a serving routine of the signal handler. Does somebody know how to get to a standard callstack?
I mean to have a call stack from originating place of raising of SIGABORT.

A few details are bellow ...

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Callstack from coredump:
Program terminated with signal SIGABRT, Aborted.
#0  0xb6b76d14 in raise () from /lib/libc.so.6
(gdb) bt
#0  0xb6b76d14 in raise () from /lib/libc.so.6
#1  0xb6b7a814 in abort () from /lib/libc.so.6
#2  0xb6de0dd0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#3  0xb6ddec1c in ?? () from /usr/lib/libstdc++.so.6

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
HW:
root@WIM1:~# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 795.44
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2

Hardware        : Generic AM33XX (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

root@WIM1:~# uname -a
Linux WIM1 4.1.13-yocto-standard #1 Thu Apr 20 18:07:09 CEST 2017 armv7l GNU/Linux

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
packages:
poky-jethro-14.0.1
arm-poky-linux-gnueabi-gcc-5.2.0

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
compiler flags:

arm-poky-linux-gnueabi-g++  -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
--sysroot=/jenkins_data/wim-build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb
-DHAVE_CONFIG_H
-I. -I..    -I/jenkins_data/wim-build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/include/skybase
-DDBUS_API_SUBJECT_TO_CHANGE
-I/jenkins_data/wim-build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/include/dbus-c++-1
-I/jenkins_data/wim-build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/include/dbus-1.0
-I/jenkins_data/wim-build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/lib/dbus-1.0/include
-Wall -pipe -std=c++14 -O2 -pipe -g -feliminate-unused-debug-types -fvisibility-inlines-hidden -c -o DlClassServer.o `test -f 'Classif/DlClassServer.cpp' || echo './'`Classif/DlClassServer.cpp

linker flags:

arm-poky-linux-gnueabi-libtool  --tag=CXX   --mode=link arm-poky-linux-gnueabi-g++  -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
--sysroot=/jenkins_data/build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb
-I/jenkins_data/build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/include/skybase
-DDBUS_API_SUBJECT_TO_CHANGE
-I/jenkins_data/build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/include/dbus-c++-1
-I/jenkins_data/build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/include/dbus-1.0
-I/jenkins_data/build-standard/skybase/yocto_build/tmp/sysroots/skyboard-evb/usr/lib/dbus-1.0/include
-Wall -pipe -std=c++14 -O2 -pipe -g -feliminate-unused-debug-types -fvisibility-inlines-hidden  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o
DataLogger *.o
-llog -ldbus-c++-1 -ldbus-1 -leeprom -lskyboard -lutils -llog -lssl -lcrypto -lskyboard -llog -lutils -llog -leds -llog -lhwclock -llog -lrt -lpthread -lboost_regex -lboost_system -lboost_serialization -ldaq -ldsp -lm -ldl

  • 0
    TI__Guru**** 161600 points
    Hi Ondrej,

    Have you tested
    bt n

    This should print the stack trace from the innermost n frames.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 40 points

    Hi Yordan,

    Thanks for the advice. I didn't try it but I've tried now. Here is the output. It seems that gdb cannot go throught "Backtrace stopped: previous frame identical to this frame (corrupt stack?)" I don't believe that the stack is corrupted because the most of my coredumps are "corrupted". I think that it is a kind of indication where should be the previous thread but it is not there.

    Program terminated with signal SIGABRT, Aborted.
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    (gdb) bt
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    #1  0xb6b7a814 in abort () from /lib/libc.so.6
    #2  0xb6de0dd0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
    #3  0xb6ddec1c in ?? () from /usr/lib/libstdc++.so.6
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb) bt 1
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    (More stack frames follow...)
    (gdb) bt 2
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    #1  0xb6b7a814 in abort () from /lib/libc.so.6
    (More stack frames follow...)
    (gdb) bt 3
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    #1  0xb6b7a814 in abort () from /lib/libc.so.6
    #2  0xb6de0dd0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
    (More stack frames follow...)
    (gdb) bt 4
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    #1  0xb6b7a814 in abort () from /lib/libc.so.6
    #2  0xb6de0dd0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
    #3  0xb6ddec1c in ?? () from /usr/lib/libstdc++.so.6
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb) bt 5
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    #1  0xb6b7a814 in abort () from /lib/libc.so.6
    #2  0xb6de0dd0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
    #3  0xb6ddec1c in ?? () from /usr/lib/libstdc++.so.6
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb) bt 6
    #0  0xb6b76d14 in raise () from /lib/libc.so.6
    #1  0xb6b7a814 in abort () from /lib/libc.so.6
    #2  0xb6de0dd0 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
    #3  0xb6ddec1c in ?? () from /usr/lib/libstdc++.so.6
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)


  • 0 in reply to Ondrej Kucharik
    TI__Guru**** 161600 points
    Hi,

    Do you think it is possible to share your binary, so I can try and recreate this on one of my platforms (AM335x Starter Kit or BBB)?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 40 points

    Hi,

    sorry for late response. I couldn't share the binary because it is too big and has many dependencies but I tried to make a simple example for you and there I could see the correct callstack. Then I investigated it and tried to fix it and the problem was on my side..between a chair and a keyboard. :) My signal handler could do a return and didn't call default signal handler at all. One line at the end of my signal handler fixed my problem:

    signal(sig, SIG_DFL);

    Thank you for your time and willingness,

    Ondro

  • 0 in reply to Ondrej Kucharik
    Prodigy 40 points

    Hi Yordan,

    I'm back with the same issue. I tested the app with abort() function and I fixed it. Now, I've tried to use assert() function and the coredump is corrupted or unusable. Both of them generate SIGABRT. I've uploaded binary and source codes and coredump of Test (example) application here: https://mega.nz/fm/BmxBwb5C

    It is simple application with one created thread where is a assert() in the main loop.

    BR,

    Ondro