User Tools
tutorials:troubleshooting:coredumpfile
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
tutorials:troubleshooting:coredumpfile [2018/01/02 11:33] miconda created |
tutorials:troubleshooting:coredumpfile [2021/04/29 08:22] (current) miconda |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| - | [color=blue]Getting the backtrace from a core file dumped upon Kamailio crash[/color] | + | **Getting the backtrace from a core file dumped upon Kamailio crash.** |
| After a crash of the server it may generate a core file in its working directory, if the functionality is not disabled. This core file can be used to get the cause (or at least a hint) of the crash. The core file contains the memory of the process at the moment it crashes as well as the execution trace, so it could contain sensitive data. | After a crash of the server it may generate a core file in its working directory, if the functionality is not disabled. This core file can be used to get the cause (or at least a hint) of the crash. The core file contains the memory of the process at the moment it crashes as well as the execution trace, so it could contain sensitive data. | ||
| - | ===== Potential | + | ===== Potential |
| * Invalid input data, e.g. some messages or from the database | * Invalid input data, e.g. some messages or from the database | ||
| * Errors in the program code, e.g. null pointer access | * Errors in the program code, e.g. null pointer access | ||
| - | ===== What do do with a core file ===== | + | ===== Analyze Core File ===== |
| Core files can be examined with **gdb**, the GNU debugger. It can read the crash informations, | Core files can be examined with **gdb**, the GNU debugger. It can read the crash informations, | ||
| Line 19: | Line 19: | ||
| </ | </ | ||
| - | (Substitute the paths to match your installation.) | + | Substitute the paths to match your installation, for example: |
| - | After gdb finished to read its input type **backtrace**, gdb will then output the backtrace. This information should added to your bug report of the crash. Please don't delete the core files after the backtrace generation, as its really helpful for eventual further investigations. | + | < |
| + | gdb / | ||
| + | </ | ||
| + | |||
| + | After gdb finished to read the input and shows its prompt, execute: | ||
| + | |||
| + | < | ||
| + | backtrace | ||
| + | </ | ||
| + | |||
| + | or the short variant: | ||
| + | |||
| + | < | ||
| + | bt | ||
| + | </ | ||
| + | |||
| + | GDB will then output the backtrace. | ||
| + | |||
| + | More useful could be the full backtrace, that can be seen with: | ||
| + | |||
| + | < | ||
| + | bt full | ||
| + | </ | ||
| + | |||
| + | This information should added to your bug report of the crash. Please don't delete the core files after the backtrace generation, as its really helpful for eventual further investigations. | ||
| - | In order to get a meaningful backtrace gdb needs some debugging informations in its binary. If you compiled from the source, no additional steps should be necessary from you. If you install a binary package, e.g. from debian, you need to install the **-dbg** package too. | + | In order to get a meaningful backtrace gdb needs some debugging informations in its binary. If you compiled from the source, no additional steps should be necessary from you. If you install a binary package, e.g. from debian, you need to install the **-dbg** package too (e.g., kamailio-dbg...deb). |
| If you don't understand the information that gdb prints, some developer on the mailling list should be able to help you. | If you don't understand the information that gdb prints, some developer on the mailling list should be able to help you. | ||
| - | ===== How do get a core file ===== | + | ===== How To Get Core Files ===== |
| Sometimes the server don't write the core file after a crash. | Sometimes the server don't write the core file after a crash. | ||
| Line 41: | Line 65: | ||
| </ | </ | ||
| - | in the shell where you started the server. If you run from a init script it should normally already take care of this. If its still not create a core file then perhaps the server has no permissions to write into its working directory, check its permissions and the startup option " | + | in the shell where you started the server. If you run from a init script it should normally already take care of this. If its still not create a core file then perhaps the server has no permissions to write into its working directory, check its permissions and the startup option " |
| + | |||
| + | On some operating systems it may be required to run Kamailio as privileged user (e.g., root) or change the **fs.suid_dumpable** sysctl setting: | ||
| + | |||
| + | * https:// | ||
| To get per-process core file then you can use on Linux: | To get per-process core file then you can use on Linux: | ||
| Line 47: | Line 75: | ||
| < | < | ||
| echo " | echo " | ||
| + | </ | ||
| + | |||
| + | A similar command for FreeBSD: | ||
| + | |||
| + | < | ||
| + | sysctl kern.corefile=' | ||
| + | </ | ||
| + | |||
| + | ==== CentOS Core Dump Settings ==== | ||
| + | |||
| + | For CentOS 7, the following settings can be useful: | ||
| + | |||
| + | Edit **/ | ||
| + | |||
| + | < | ||
| + | kernel.core_pattern = / | ||
| + | kernel.core_uses_pid=1 | ||
| + | fs.suid_dumpable = 2 | ||
| + | </ | ||
| + | |||
| + | Run **sysctl --system** to reload kernel parameters. | ||
| + | |||
| + | Edit **/ | ||
| + | |||
| + | < | ||
| + | DUMP_CORE=yes | ||
| </ | </ | ||
tutorials/troubleshooting/coredumpfile.1514889197.txt.gz · Last modified: 2018/01/02 11:33 by miconda
Page Tools
