Debugging i3: How To

i3 spits out much information onto stdout. To have a clearly defined place where logfiles will be saved, you should redirect stdout and stderr 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.

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):

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:

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.

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:

You should get an output like this:

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.

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 don’t need to learn it now. Start gdb using the following command (replacing the actual name of the coredump of course):

Then, generate a backtrace using:

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.