gri3-wm/docs/debugging

125 lines
5.1 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Debugging i3: How To
==================
Michael Stapelberg <michael+i3@stapelberg.de>
April 2009
This document describes how to debug i3 suitably for sending us useful bug reports, even
if you have no clue of C programming.
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!
== Enabling logging
i3 spits out much information onto stdout. To have a clearly defined place where logfiles
will be saved, you should redirect stdout in xsession. While youre at it, putting each
run of i3 in a separate logfile with date/time in it is a good idea to not get confused
about the different logfiles later on.
---------------------------------------------------------------
exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S')
---------------------------------------------------------------
== Enabling coredumps
When i3 crashes, often you have the chance of getting a coredump (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 high enough. Many systems ship
with a default value which even forbids core dumps completely. To disable the limit
completely and thus enable coredumps, use the following command (in your .xsession, before
starting i3):
-------------------
ulimit -c unlimited
-------------------
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:
---------------------------------------------
sudo sysctl -w kernel.core_pattern=core.%e.%p
---------------------------------------------
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+.
== Compiling with debug symbols
To actually get useful coredumps, you should make sure that your version of i3 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:
----------------
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
------------------------------------------------------------------------------
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.
== Generating a backtrace
Once you have made sure that your i3 is compiled with debug symbols and that coredumps
are enabled, you can start getting some sense out of the coredumps.
Because the coredump depends on the original executable (and its debug symbols), please
do this as soon as you encounter the problem. If you re-compile i3, your coredump might
be useless afterwards.
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 coredump of
course):
----------------------------
gdb $(which i3) core.i3.3849
----------------------------
Then, generate a backtrace using:
---------
backtrace
---------
Also, getting an overview of the local variables might help:
-----------
info locals
-----------
If your backtrace looks like this:
---------------------------------------------------------------------------------------------------
(gdb) backtrace
#0 0x041b1a01 in vfprintf () from /lib/libc.so.6
#1 0x041b2f80 in vprintf () from /lib/libc.so.6
#2 0x080555de in slog (fmt=0x8059ba0 "%s:%s:%d - Name should change to \"%s\"\n") at src/util.c:60
#3 0x0804fa73 in handle_windowname_change_legacy (data=0x0, conn=0x42da908,
state=0 '\0', window=8389918, atom=39, prop=0x4303f90) at src/handlers.c:752
#4 0x0406cace in ?? () from /usr/lib/libxcb-property.so.1
#5 0x00000000 in ?? ()
---------------------------------------------------------------------------------------------------
you need to find the first frame which actually belongs to i3 code. You can easily spot them, as
their filename starts with src/ and has a line number. In this case, frame 2 would be the correct
frame, so before getting the local variables, switch to frame 2:
-----------
frame 2
info locals
-----------
== Sending bugreports/debugging on IRC
When sending bugreports, please paste the relevant part of the log (if in doubt, please send us rather
too much information than too less) and the whole backtrace (if there was a coredump).
When debugging with us in IRC, be prepared to use a so called nopaste service such as http://nopaste.info
because pasting large amounts of text in IRC sometimes leads to incomplete lines (servers have line
length limitations) or flood kicks.