Project Talk:Quality Assurance/Backtraces

Core dump naming and save path
Written:

«…a core file that might be called either "core" or "core.pid" (where pid is replaced with the actual pid of the program that died).»

Should be written something like:

By default core dump file is written to the current directory (usually, but not always — $HOME of user, running program). The name of core dump file is managed by "kernel.core_pattern" sysctl setting. The default value is "core". Rememeber: if you want to perform permanent change, you should put your value into /etc/sysctl.conf.

The second notable setting is the clearest, but not only, way to add pid suffix: the "kernel.core_uses_pid", by default disabled (so, if process provides several crashes in the same directory, see bug #504760 as example, you'll see only the last one).

There is another, better way to customize core dump file name.

I prefer the following value, specifying not only crashed program name and signal killed in filename, but writing cores into dedicated directory, not to search for cores, that also allows to catch otherwise missed crashes (again see, and maybe follow bug #504760):

kernel.core_pattern = /tmp/cores/core_%e-%s.%p

see man 5 core for detailed explanation and alternatives. The dedicated directory for cores must have full access for everybody (if user has no write access to the current directory, core dump probably willn't bew written). To create it in /tmp I use the following script: /etc/local.d/mk_core_dir.start mkdir -m 0777 /tmp/cores You may want to use permanent directory instead. For example /var/tmp/cores.
 * 1) !/bin/sh

After configuring you could (and probably should) want to verify its correctness. To do it just run a program (for example — text editor), terminate it with followed with writing core signal, for example 6 (see man 1 kill and man 7 signal for details and alternatives) and see the result core file.

Performing described check I was wondered with the fact of necessity of execution bit on dedicated core dump directory (needed for cd?).

--Anarchist 2014

systemd/coredumpctl
If anyone gets around to do it: some instructions and details on how to configure and use systemd's coredump handling and coredumpctl would fit in nicely here.

--Eliasp (talk) 18:07, 29 December 2014 (UTC)

Getting useful backtraces for X errors  [Please add this as a section]
X errors have the problem, that the program that uses X likely just exits normally or with an exit code. This makes it not obvious how to get a real backtrace in GDB. To achieve this, a number of additional steps have to be performed.

Also, a table of X error codes and request codes might come in handy.

As normally, make sure your program contains debug symbols:
( is used to save time. It is assumed the package has been installed normally, and does not lack any dependencies.)

Run gdb as follows:
(Using hexchat as an example.)

Setting a breakpoint at  is the key!

As you can see, the backtrace might not be particularly useful yet, due to the libraries not having been compiled with debug information yet.
The simplest way to solve that, is by finding the packages those libraries belong to, with (e.g. for libpulse):

and then re-emerging all those libraries with debug information too:

Of course,  can be used too.