Analyzing Coredumps

From postmarketOS
Jump to navigation Jump to search

This article is about analyzing coredumps in postmarketOS. It's a stub, the part with analyzing doesn't seem to return an useful stack in most cases, expanding this and removing this sentence is most welcome.

Enabling Coredumps

Unlike your typical systemd based distribution, we don't use coredumpctl and coredumps are not enabled by default, so you need to do the following steps first.

1. Write to /etc/security/limits.conf:

# <domain> <type> <item> <value>
* soft core unlimited
* hard core unlimited

2. Set a pattern for writing the core dumps, e.g.:

$ echo '/tmp/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern

If you use a different directory, make sure all users can write to it by using chmod a+w.

3. Set ulimit before running the application that you want to debug. It is valid for the current shell session. If you want everything that runs in tinydm to create coredumps, put this in ~/.profile:

ulimit -c unlimited

Verifying that it works

If you are unsure whether this works, e.g. because the app you expect to crash doesn't create a coredump for some reason, build a simple C program that crashes:

$ echo '#include <stdlib.h>\nint main() { abort(); return 0; }' > /tmp/crash.c
$ gcc -o /tmp/crash /tmp/crash.c
$ /tmp/crash 
[1]    28898 abort      /tmp/crash

Analyzing Coredumps

Open the coredump in gdb and run "bt" to get a backtrace. This part here of the article is a stub, let's put the full output here etc.

$ gdb /tmp/crash /path/to/coredump

Install debug symbols to get function names and line numbers for all libraries in the trace, e.g. musl-dbg and glib-dbg. Alpine doesn't have these for all libraries due to the size they consume, but they can be enabled on demand in edge to debug issues.

See also