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  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
 * 1) !/bin/sh

You may want to use permanent directory instead. For example.

Alternatively you can handle a directory using utils from.

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


 * I have emailed the QA team. Hopefully they can look this over and (potentially) fix up the article... --Maffblaster (talk) 09:16, 5 March 2017 (UTC)

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.

Article description property
I would add an "Article description" property right at the beginning of this article, so we can use the See also templates in other articles linking to this one. Fturco (talk) 16:56, 12 April 2018 (UTC)


 * Done. Thanks, Fturco! --Maffblaster (talk) 18:46, 12 April 2018 (UTC)

Using compiler flags with portage
There is content in the package.env wiki article that illustrates building packages with custom compiler flags. This article suggests these happen, but has no practical examples on how to achieve this, either manually, using ebuild or with portage (emerge).

Should that content be replicated here, or linked to if it is useful?

kde-plasma/drkonqi instead of kde-base/drkonqi
In the paragraph Project:Quality_Assurance/Backtraces, it is said "KDE-based applications runs [or better "run" ??] by default with their own crash handler, which is presented by the user by the means of "Dr. Konqi" if it's installed (the package is either kde-base/kdebase or kde-base/drkonqi". It seems to refer to older versions of kde packages since currently kde-base/kdebase and kde-base/drkonqi kde-plasma/drkonqi do not match with emerge, and on the contrary kde-plasma/drkonqi and kde-apps/kdebase-meta do. Akar (talk) 15:21, 26 June 2020 (UTC)

system-wide ulimit that works even when ssh-ing to it
Just place a line in /etc/rc.conf like rc_ulimit="-c unlimited" assuming you don't want to UsePAM yes in /etc/ssh/sshd_config. Now it doesn't show 0 when I run ulimit -c after ssh-ing to the box. Note: /etc/security/limits.conf would work with PAM, but /etc/limits.conf had no effect either way. --Okwtwnow (talk) 19:23, 3 December 2020 (UTC)