Analyzing Coredumps

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 :

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

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

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 :

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:

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.

Install debug symbols to get function names and line numbers for all libraries in the trace, e.g.  and. 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.