Debugging i3: How To
-==================
-Michael Stapelberg <michael+i3@stapelberg.de>
-April 2009
+====================
+Michael Stapelberg <michael@i3wm.org>
+January 2014
-This document describes how to debug i3 suitably for sending us useful bug reports, even
-if you have no clue of C programming.
+This document describes how to debug i3 to send us useful bug
+reports, even if you have no knowledge 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!
+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
+process and/or need further help, do not hesitate to contact us!
+
+== Verify you are using i3 ≥ 4.10
+
+Only the latest major version of i3 is supported. To verify which version
+you are running, use:
+
+---------------
+$ i3 --moreversion 2>&- || i3 --version
+Binary i3 version: 4.7 (2013-12-22, branch "tags/4.7")
+Running i3 version: 4.7-84-gac74a63 (2014-01-01, branch "next") (pid 1995)
+---------------
+
+Your version can look like this:
+
+4.7 (release version)::
+You are using a release version. In many cases, bugs are already
+fixed in the development version of i3. Even if the bug is not a known fixed
+one, we will still ask you to reproduce your error with the most recent
+development version of i3. Therefore, please upgrade to a development version
+if you can.
+
+4.7-85-g9c15b95 (development version)::
+Your version is 85 commits newer than 4.7, and the git revision of your
+version is +9c15b95+. Go to https://github.com/i3/i3/commits/next and see if
+the most recent commit starts with the same revision. If so, you are using the
+latest version.
+
+Development versions of i3 have logging enabled by default and are compiled
+with debug symbols.
== 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 you’re 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.
+If you are using a development version (see previous section), you don’t need
+to do anything -- skip to section 3.
----------------------------------------------------------------
-exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S')
----------------------------------------------------------------
+If you are using a release version with a custom +~/.xsession+ (or xinitrc)
+file, execute i3 with a line like this:
-== Enabling coredumps
+----------------------------------
+# Use 25 MiB of RAM for debug logs
+exec i3 --shmlog-size=26214400
+----------------------------------
-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):
+If you are *NOT* using an +~/.xsession+ file but you just chose "i3" from the
+list of sessions in your desktop manager (gdm, lxdm, …), edit
++/usr/share/xsessions/i3.desktop+ and replace the +Exec=i3+ line with:
--------------------
-ulimit -c unlimited
--------------------
+------------------------------
+Exec=i3 --shmlog-size=26214400
+------------------------------
-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:
+If you cannot restart i3 for some reason, you can enable debug logging on the
+fly:
----------------------------------------------
-sudo sysctl -w kernel.core_pattern=core.%e.%p
----------------------------------------------
+---------------------------------------
+i3-msg 'debuglog on; shmlog on; reload'
+---------------------------------------
-This will generate files which have the executable’s file name (%e) and the process id
-(%p) in it. You can save this setting across reboots using +/etc/sysctl.conf+.
+== Reproducing the problem
-== Compiling with debug symbols
+Before submitting an issue, please make sure to close down on the problem as
+much as you can yourself. Here are some steps you should consider:
-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:
+* Find a deterministic, reliable way to reproduce the problem and provide it
+ with your bug report.
+* Try using the default i3 config to reproduce the problem. If the issue does
+ not appear with the default config, gradually adapt it to track down what
+ change(s) to the config introduce the problem.
+* Reproduce the problem with a minimal setup, i.e., only use as few applications,
+ windows and steps as necessary.
+* In addition, try to stick to applications that are common and, even more
+ importantly, free / open source.
+* Before obtaining the log file, restart i3 in-place, execute the steps to
+ reproduce the problem and then save the logs. This keeps the log file as
+ small as possible and necessary.
-----------------
-file $(which i3)
-----------------
+Please be aware that we cannot support compatibility issues with closed-source
+software, as digging into compatibility problems without having access to the
+source code is too time-consuming. Additionally, experience has shown that
+often, the software in question is responsible for the issue. Please raise an
+issue with the software in question, not 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
-------------------------------------------------------------------------------
+== Obtaining the debug logfile
+
+[CAUTION]
+================================================================================
+Logs may contain sensitive information, so please inspect the log before
+submitting it. Logs may be viewed by anyone, once posted. If you choose to
+redact the log, make an effort not to discard information which may be relevant
+to the issue you are reporting.
+
+The best way to avoid submitting such information is to only run the necessary
+steps to reproduce the behavior when saving the log file. This will also make
+analyzing the log file easier.
+================================================================================
+
+No matter whether i3 misbehaved in some way without crashing or whether it just
+crashed, the logfile provides all information necessary to debug the problem.
+
+To upload a compressed version of the logfile (for a bugreport), use:
+-------------------------------------------------------------------------------
+DISPLAY=:0 i3-dump-log | bzip2 -c | curl --data-binary @- https://logs.i3wm.org
+-------------------------------------------------------------------------------
-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.
+This command does not depend on i3 (it also works while i3 displays
+the crash dialog), but it requires a working X11 connection.
-== Generating a backtrace
+After running it, you will get a URL to the logfile. Please include that URL in
+your bug report.
-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.
+== On crashes: Obtaining a backtrace
-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.
+When i3 crashes, it will display a dialog stating “i3 just crashed”, offering
+you to save a backtrace to a text file.
-Please install +gdb+, a debugger for C. No worries, you don’t need to learn it now.
-Start gdb using the following command (replacing the actual name of the coredump of
-course):
+To actually get useful backtraces, you should make sure that your version of i3
+is compiled with debug symbols:
+
+------------------------------------------------------------------------------
+$ file `which i3`
+/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
+------------------------------------------------------------------------------
-----------------------------
-gdb $(which i3) core.i3.3849
-----------------------------
+Notice the +not stripped+, which is the important part. If you have a version
+which is stripped, please check whether 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.
-Then, generate a backtrace using:
+Once you have made sure that your i3 is compiled with debug symbols and the C
+debugger +gdb+ is installed on your machine, you can let i3 generate a
+backtrace in the crash dialog.
----------
-backtrace
----------
+After pressing "b" in the crash dialog, you will get a file called
++/tmp/i3-backtrace.%d.%d.txt+ where the first +%d+ is replaced by i3’s process
+id (PID) and the second one is incremented each time you generate a backtrace,
+starting at 0.
-Also, getting an overview of the local variables might help:
------------
-info locals
------------
+== Sending bug reports/debugging on IRC
-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 ?? ()
----------------------------------------------------------------------------------------------------
+When sending bug reports, please attach the *whole* log file. Even if you think
+you found the section which clearly highlights the problem, additional
+information might be necessary to completely diagnose the problem.
-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:
+When debugging with us in IRC, be prepared to use a so-called nopaste service
+such as https://pastebin.com because pasting large amounts of text in IRC
+sometimes leads to incomplete lines (servers have line length limitations) or
+flood kicks.
------------
-frame 2
-info locals
------------
+== Debugging i3bar
-== Sending bugreports/debugging on IRC
+To debug i3bar problems, use the +--verbose+ commandline parameter,
+or add +verbose yes+ to all +bar {}+ blocks in your i3
+config, reload your config and then restart all i3bar instances like this:
-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).
+---------------------------------------------------------------------
+$ i3 reload
+$ killall i3bar
+$ for c in $(i3-msg -t get_bar_config | python -c \
+ 'import json,sys;print("\n".join(json.load(sys.stdin)))'); do \
+ (i3bar --bar_id=$c >i3bar.$c.log 2>&1) & \
+ done;
+---------------------------------------------------------------------
-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.
+There will now be +i3bar.*.log+ files in your current directory that you can provide
+in your bug report.
projects / i3 / i3 / blobdiff