Jump to content

Analyzing Coredumps: Difference between revisions

From postmarketOS Wiki
put my notes of getting coredumps into a wiki article stub
 
Haui2 (talk | contribs)
 
(7 intermediate revisions by 3 users not shown)
Line 26: Line 26:
</pre>
</pre>


==== Verify it works ====
==== 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:
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:


Line 32: Line 32:
$ echo '#include <stdlib.h>\nint main() { abort(); return 0; }' > /tmp/crash.c
$ echo '#include <stdlib.h>\nint main() { abort(); return 0; }' > /tmp/crash.c
$ gcc -o /tmp/crash /tmp/crash.c
$ gcc -o /tmp/crash /tmp/crash.c
/tmp/crash.c: In function 'main':
/tmp/crash.c:1:23: warning: division by zero [-Wdiv-by-zero]
    1 | int main() { return 1 / 0; }
      |
$ /tmp/crash  
$ /tmp/crash  
[1]    28898 abort      /tmp/crash
[1]    28898 abort      /tmp/crash
Line 41: Line 37:


=== Analyzing Coredumps ===
=== Analyzing Coredumps ===
Install gdb (apk add gdb)


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.
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.
Line 49: Line 47:


Install debug symbols to get function names and line numbers for all libraries in the trace, e.g. <code>musl-dbg</code> and <code>glib-dbg</code>. 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.
Install debug symbols to get function names and line numbers for all libraries in the trace, e.g. <code>musl-dbg</code> and <code>glib-dbg</code>. 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 ==
* [[Debugging the GNOME stack]]
* [https://www.cogitri.dev/posts/05-introducing-corecollector/ Cogitri's blog: Introducing corecollector]


[[Category:Guide]]
[[Category:Guide]]

Latest revision as of 08:25, 30 July 2024

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

Install gdb (apk add gdb)

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