This document describes how to debug i3 to send us useful bug +reports, even if you have no knowledge of C programming.
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
+If you are using a development version (see previous section), you don’t need +to do anything — skip to section 3.
If you are using a release version with a custom ~/.xsession (or xinitrc) +file, execute i3 with a line like this:
# Use 25 MiB of RAM for debug logs +exec i3 --shmlog-size=26214400+
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:
Exec=i3 --shmlog-size=26214400+
If you cannot restart i3 for some reason, you can enable debug logging on the +fly:
i3-msg 'debuglog on; shmlog on; reload'+
Reproducing the problem
+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:
-
+
-
+
+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. +
+
+
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.
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+
This command does not depend on i3 (it also works while i3 displays +the crash dialog), but it requires a working X11 connection.
After running it, you will get a URL to the logfile. Please include that URL in +your bug report.
On crashes: Obtaining a backtrace
+When i3 crashes, it will display a dialog stating “i3 just crashed”, offering +you to save a backtrace to a text file.
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+
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.
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.
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.
In Linux, if the backtrace just says No stack., that’s because gdb does not +have necessary permissions to attach to a running process. You can fix that by +running from a terminal (you can open a new tty, e.g. with ctrl-alt-F2):
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope+
Afterwards, try re-generating the stack trace. Note that this setting re-sets +after reboot, see more info at +https://www.kernel.org/doc/Documentation/security/Yama.txt.
Debugging i3bar
+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:
$ 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;+
There will now be i3bar.*.log files in your current directory that you can provide +in your bug report.