Analysis of generated core dump

Hello everybody,

I am trying to understand the best way to analyse a generated core dump of my crashed application, due to the fact that the Apalis board will run at the customer site, and the only way to understand the source of the problem will be the generated core dump file.

The generation of the core dump works fine, and it is created when the application crashes.

I have some problems in analysing the generated core dump.

What I am doing is the following, on my host computer (TmuControlApp is my running application on the Apalis):

nlanfran@U30Jc:/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/arm-angstrom-linux-gnueabi$ ./arm-angstrom-linux-gnueabi-gdb /work/workspace/TmuControlApp/src/TmuControlApp /tmp/core-TmuControlApp-8-1000-1000-1232-1523349892
GNU gdb (GDB) 8.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
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-angstromsdk-linux --target=arm-angstrom-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /work/workspace/TmuControlApp/src/TmuControlApp...done.

warning: exec file is newer than core file.
[New LWP 1232]

warning: Could not load shared library symbols for .
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `/work/TmuControlApp'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x00265e28 in new_exp_0 (op=<optimized out>) at /usr/src/debug/glibc/2.26-r0/git/intl/plural.y:95
95	/usr/src/debug/glibc/2.26-r0/git/intl/plural.y: No such file or directory.

The cross compiled gdb is able to read the ARM executable (with debug symbols) and the generated core dump, and it gives me the correct reason of termination, but it is also looking for some shared libraries and I guess it is asking me to use the ‘set sysroot’ option. My ARM executable is compiled using static libraries, with:

/arm-angstrom-linux-gnueabi-g++  -march=armv7-a -mthumb -mfpu=neon  -mfloat-abi=hard --sysroot=/usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi

I tried to follow the toradex web page related to analysing core dumps, and it says to do:

In oe-core/build/out-glibc/sysroot/colibri-t30:

../x86_64-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gdb -ex 'set sysroot .' -ex 'core-file ./core-firefox-4-0-0-596-1402701200' usr/lib/firefox/firefox

but I am not sure I understand it correctly, as the instructions are for BSP releases prior to V 2.6.1.

Can somebody help me to do the last step (setting the sysroot when calling gdb) and be able to use backtrace and the full debug features of GDB ?

Thank you in advance !!

Best regards,

Hi @nlanfran

Could you update to Bsp 2.8b5 since the 2.8b2 is not supported anymore?

I think as you wrote in general GDB is working fine. Concerning your issue:

Can somebody help me to do the last step (setting the sysroot when calling gdb) and be able to use backtrace and the full debug features of GDB ?

Could you try the instructions on the following site?

Best regards,

It’s Perfect that it works. Thanks for the feedback.

Hello Jaski,

thank you for your answer.

I was able to fix the problem, which was caused by a slight misalignment between my SDK on the host and the image on the Apalis iMX6D.

After creating a new image in sync with the SDK, and after compiling my application, I was able to correctly analyse the core dump generated by the ARM executable created with both static libraries and shared libraries, when I made it deliberately crash.

With shared libraries, I just had to provide to gdb the path to the sysroot, using:

-ex 'set sysroot /usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi'

I will for sure update to 2.8b5.

Thanks for your help.

Best regards,