Symptom:
This technote provides information on how to interpret a Linux core
dump file when an application running on the system, terminates
unexpectedly, due to a segmentation fault and generates a core file.
Reason for the problem:
A segmentation fault generally occurs when a program attempts to access
a memory location that it is not allowed to, or attempts to access a
memory location in a way that is not allowed. The operating system will
then kill the program and create a core file that programmers can use
to figure out what went wrong. It contains detailed information about
the nature of the crash, such as what caused the crash and what the
program was doing when it happened.
Fix / Solution:
A core dump can be caused by any number of issues that may or may not
be related to a Dialogic® problem. This technical note describes how to
gather information to determine if a Dialogic® API call may be the
cause of a segmentation fault. Here are the basic steps to take in
determining the cause for the core dump:
1.
To determine what program a core file came from, use the file command:
<prompt> file core.1234
core.1234: ELF 32-bit LSB core file of “app” (signal 11), Intel 80386, version 1, from “app”
Note:
The above output shows that program “app”
is the executable which generated the core dump file.
2.
Then run GDB (The GNU Debugger) to view the contents of the core file with the following command line options:
<prompt> gdb app core.1234 (where “app” is the application executable and “core.1234” is the core dump file)
3.
Once GDB has loaded up, you can run the “bt” command to display backtrace of the program stack.
Example:
(gdb) bt
#0 0x40c8b6ec in s7_listen () from
