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.
+====================
+Michael Stapelberg <michael@i3wm.org>
+February 2012
-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!
+This document describes how to debug i3 suitably for sending us useful bug
+reports, even if you have no clue of C programming.
-== 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.
+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!
----------------------------------------------------------------
-exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S')
----------------------------------------------------------------
+== Verify you are using the latest (development) version
-== Enabling coredumps
+Please verify that you are using the latest version of i3:
-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):
+---------------
+$ i3 --version
+i3 version 4.1.2-248-g51728ba (2012-02-12, branch "next")
+---------------
--------------------
-ulimit -c unlimited
--------------------
+Your version can look like this:
-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:
+4.1.2::
+You are using a release version. Please
+upgrade to a development version first, or read
+link:debugging-release-version.html[Debugging i3: How To (release version)].
----------------------------------------------
-sudo sysctl -w kernel.core_pattern=core.%e.%p
----------------------------------------------
+4.1.2-248-g51728ba::
+Your version is 248 commits newer than 4.1.2, and the git revision of your
+version is +51728ba+. Go to http://code.i3wm.org/i3/commit/?h=next and see if
+the line "commit" starts with the same revision. If so, you are using the
+latest version.
-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+.
+Development versions of i3 have several properties which make debugging easier:
-== Compiling with debug symbols
+1. Shared memory debug logging is enabled by default. You do not have to enable
+ logging explicitly.
+2. Core dumps are enabled by default.
+3. If you are using a version from the Debian/Ubuntu autobuilder, it is
+ compiled without optimization. Debug symbols are available in the i3-wm-dbg
+ package. When compiling i3 yourself, debug mode is the default.
-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:
+== Obtaining the debug logfile
-----------------
-file $(which i3)
-----------------
+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.
-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
-------------------------------------------------------------------------------
+To save a compressed version of the logfile (suitable for attaching it to a
+bugreport), use:
+--------------------------------------------------------------------
+i3-dump-log | gzip -9c > /tmp/i3.log.gz
+--------------------------------------------------------------------
-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 when i3 currently displays
+the crash dialog), but it requires a working X11 connection. When running it
+from a virtual console (Ctrl-Alt-F1), use:
-== Generating a backtrace
+--------------------------------------------------------------------
+DISPLAY=:0 i3-dump-log | gzip -9c > /tmp/i3.log.gz
+--------------------------------------------------------------------
-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.
+== 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 displays its crash dialog, do the following:
-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):
+1. Switch to a virtual console (Ctrl-Alt-F1) or login from a different computer
+2. Generate a backtrace (see below)
+3. Switch back to the crash dialog (Ctrl-Alt-F7)
+4. Restart i3 in-place (you will keep your session), continue working
-----------------------------
-gdb $(which i3) core.i3.3849
-----------------------------
+This is how you get a backtrace from a running i3 process:
-Then, generate a backtrace using:
+-----------------
+I3PID=$(pidof i3)
+gdb /proc/$I3PID/exe $I3PID \
+ --batch --quiet \
+ --ex 'backtrace full' > /tmp/i3-backtrace.txt 2>&1
+-----------------
----------
-backtrace
----------
+== Sending bug reports/debugging on IRC
-Also, getting an overview of the local variables might help:
------------
-info locals
------------
+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.
-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
+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.
projects / i3 / i3 / blobdiff