i3/docs/debugging

105 lines
4.1 KiB
Plaintext
Raw Normal View History

2009-04-28 15:10:20 -04:00
Debugging i3: How To
====================
2009-04-28 15:10:20 -04:00
Michael Stapelberg <michael+i3@stapelberg.de>
2010-03-27 10:30:09 -04:00
March 2010
2009-04-28 15:10:20 -04:00
2010-03-10 07:01:27 -05:00
This document describes how to debug i3 suitably for sending us useful bug
reports, even if you have no clue of C programming.
2009-04-28 15:10:20 -04:00
2010-03-10 07:01:27 -05:00
First of all: Thank you for being interested in debugging i3. It really means
something to us to get your bug fixed. If you have any questions about the
debugging and/or need further help, do not hesitate to contact us!
2009-04-28 15:10:20 -04:00
== Enabling logging
2010-03-27 10:30:09 -04:00
i3 spits out much information onto stdout, if told so. To have a clearly
defined place where log files will be saved, you should redirect stdout and
stderr in xsession. While youre at it, putting each run of i3 in a separate
log file with date/time in it is a good idea to not get confused about the
different log files later on.
2009-04-28 15:10:20 -04:00
2009-04-28 16:25:51 -04:00
--------------------------------------------------------------------
2010-03-27 10:30:09 -04:00
exec /usr/bin/i3 -V -d all >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1
2009-04-28 16:25:51 -04:00
--------------------------------------------------------------------
2009-04-28 15:10:20 -04:00
== Enabling core dumps
2009-04-28 15:10:20 -04:00
When i3 crashes, often you have the chance of getting a 'core dump' (an image
of the memory of the i3 process which can be loaded into a debugger). To get a
core dump, you have to make sure that the user limit for core dump files is set
2010-03-10 07:01:27 -05:00
high enough. Many systems ship with a default value which even forbids core
dumps completely. To disable the limit completely and thus enable core dumps,
2010-03-10 07:01:27 -05:00
use the following command (in your .xsession, before starting i3):
2009-04-28 15:10:20 -04:00
-------------------
ulimit -c unlimited
-------------------
2010-03-10 07:01:27 -05:00
Furthermore, to easily recognize core dumps and allow multiple of them, you
should set a custom core dump filename pattern, using a command like the
following:
2009-04-28 15:10:20 -04:00
---------------------------------------------
sudo sysctl -w kernel.core_pattern=core.%e.%p
---------------------------------------------
2010-03-10 07:01:27 -05:00
This will generate files which have the executables file name (%e) and the
process id (%p) in it. You can save this setting across reboots using
+/etc/sysctl.conf+.
2009-04-28 15:10:20 -04:00
== Compiling with debug symbols
To actually get useful core dumps, you should make sure that your version of i3
2010-03-10 07:01:27 -05:00
is compiled with debug symbols, that is, that they are not stripped during the
build process. You can check whether your executable contains symbols by
issuing the following command:
2009-04-28 15:10:20 -04:00
----------------
file $(which i3)
----------------
You should get an output like this:
------------------------------------------------------------------------------
/usr/bin/i3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
------------------------------------------------------------------------------
2010-03-10 07:01:27 -05:00
Notice the +not stripped+, which is the important part. If you have a version
which is stripped, please have a look if your distribution provides debug
symbols (package +i3-wm-dbg+ on Debian for example) or if you can turn off
stripping. If nothing helps, please build i3 from source.
2009-04-28 15:10:20 -04:00
== Generating a backtrace
2010-03-10 07:01:27 -05:00
Once you have made sure that your i3 is compiled with debug symbols and that
core dumps are enabled, you can start making sense out of the core dumps.
2009-04-28 15:10:20 -04:00
Because the core dump depends on the original executable (and its debug
2010-03-10 07:01:27 -05:00
symbols), please do this as soon as you encounter the problem. If you
re-compile i3, your core dump might be useless afterwards.
2009-04-28 15:10:20 -04:00
2010-03-10 07:01:27 -05:00
Please install +gdb+, a debugger for C. No worries, you dont need to learn it
now. Start gdb using the following command (replacing the actual name of the
core dump of course):
2009-04-28 15:10:20 -04:00
----------------------------
gdb $(which i3) core.i3.3849
----------------------------
Then, generate a backtrace using:
2009-06-24 14:14:41 -04:00
--------------
backtrace full
--------------
2009-04-28 15:10:20 -04:00
== Sending bug reports/debugging on IRC
2009-04-28 15:10:20 -04:00
When sending bug reports, please paste the relevant part of the log (if in
2010-03-10 07:01:27 -05:00
doubt, please send us rather too much information than too less) and the whole
backtrace (if there was a core dump).
2009-04-28 15:10:20 -04:00
2010-03-10 07:01:27 -05:00
When debugging with us in IRC, be prepared to use a so called nopaste service
such as http://nopaste.info or http://pastebin.com because pasting large
amounts of text in IRC sometimes leads to incomplete lines (servers have line
length limitations) or flood kicks.