3 Michael Stapelberg <michael+i3@stapelberg.de>
6 This document describes how to debug i3 suitably for sending us useful bug
7 reports, even if you have no clue of C programming.
9 First of all: Thank you for being interested in debugging i3. It really means
10 something to us to get your bug fixed. If you have any questions about the
11 debugging and/or need further help, do not hesitate to contact us!
15 i3 spits out much information onto stdout. To have a clearly defined place
16 where log files will be saved, you should redirect stdout and stderr in
17 xsession. While you’re at it, putting each run of i3 in a separate log file
18 with date/time in it is a good idea to not get confused about the different
21 --------------------------------------------------------------------
22 exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1
23 --------------------------------------------------------------------
25 == Enabling core dumps
27 When i3 crashes, often you have the chance of getting a 'core dump' (an image
28 of the memory of the i3 process which can be loaded into a debugger). To get a
29 core dump, you have to make sure that the user limit for core dump files is set
30 high enough. Many systems ship with a default value which even forbids core
31 dumps completely. To disable the limit completely and thus enable core dumps,
32 use the following command (in your .xsession, before starting i3):
38 Furthermore, to easily recognize core dumps and allow multiple of them, you
39 should set a custom core dump filename pattern, using a command like the
42 ---------------------------------------------
43 sudo sysctl -w kernel.core_pattern=core.%e.%p
44 ---------------------------------------------
46 This will generate files which have the executable’s file name (%e) and the
47 process id (%p) in it. You can save this setting across reboots using
50 == Compiling with debug symbols
52 To actually get useful core dumps, you should make sure that your version of i3
53 is compiled with debug symbols, that is, that they are not stripped during the
54 build process. You can check whether your executable contains symbols by
55 issuing the following command:
61 You should get an output like this:
62 ------------------------------------------------------------------------------
63 /usr/bin/i3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
64 linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
65 ------------------------------------------------------------------------------
67 Notice the +not stripped+, which is the important part. If you have a version
68 which is stripped, please have a look if your distribution provides debug
69 symbols (package +i3-wm-dbg+ on Debian for example) or if you can turn off
70 stripping. If nothing helps, please build i3 from source.
72 == Generating a backtrace
74 Once you have made sure that your i3 is compiled with debug symbols and that
75 core dumps are enabled, you can start making sense out of the core dumps.
77 Because the core dump depends on the original executable (and its debug
78 symbols), please do this as soon as you encounter the problem. If you
79 re-compile i3, your core dump might be useless afterwards.
81 Please install +gdb+, a debugger for C. No worries, you don’t need to learn it
82 now. Start gdb using the following command (replacing the actual name of the
85 ----------------------------
86 gdb $(which i3) core.i3.3849
87 ----------------------------
89 Then, generate a backtrace using:
95 == Sending bug reports/debugging on IRC
97 When sending bug reports, please paste the relevant part of the log (if in
98 doubt, please send us rather too much information than too less) and the whole
99 backtrace (if there was a core dump).
101 When debugging with us in IRC, be prepared to use a so called nopaste service
102 such as http://nopaste.info or http://pastebin.com because pasting large
103 amounts of text in IRC sometimes leads to incomplete lines (servers have line
104 length limitations) or flood kicks.