Support:How To extract backtrace from coredump

When a fault happens in toolpack, developers may need to get more useful information to fix the problem.

Running GNU Debuger (GDB)

How to give useful information related to a fault in the code:

1. Log to the primary server (ssh)
2. Type tbsetup

   Usually all core files goes into the application's working directory.

3. Type cd APPLICATION

   where:

   • APPLICATION is the application that crashes

   In this example, we'll suppose APPLICATION is toolpack_engine

4. Execute command:

   gdb -se "APPLICATION" -ex "bt full" -ex "thread apply all bt" --batch -c CORE > /tmp/backtrace.txt

   where:

   • APPLICATION is the application that crashes (Full path of the application)

   • CORE is the core file. (core.xxxx)

   for example:

   gdb -se "/lib/tb/toolpack/pkg/2.8.5/bin/release/x86_64-linux64/toolpack_engine" -ex "bt full" -ex "thread apply all bt" --batch -c core.17900 > /tmp/backtrace.txt

   In this specific example, the crash happened at:

   Program terminated with signal 11, Segmentation fault.
#0 0x000000000043ce59 in CallBridgingSampleDisplayMenu ()
#0 0x000000000043ce59 in CallBridgingSampleDisplayMenu ()
No symbol table info available.

5. Attach the file /tmp/backtrace.txt in the TBSupport Tracking System (ticket that you opened to report the problem).

Troubleshooting

Possible Error 1:

# gdb
-bash: gdb: command not found

This is because you did not install the gdb package. You can do:

yum install gdb

Possible Error 2:

warning: exec file is newer than core file.
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffa11ec000

This is because the core dump file (CORE) was not generated by the pointed application (APPLICATION). It was generated by an older version of toolpack application. Make sure the core dump file matches the application that you gave as an argument to GDB.

If you prefer to run the application in gdb, consult this page