X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fdebugging;h=dd26f98d924b3783a79a09fb9b0e64ce15a25d94;hb=161db6f17d734ac9deb0a20e81b78d4b2a92ce68;hp=d32329d4e2d635a849a390f2ce8db6c51a340b44;hpb=9a931079fdc94fa54b5d1f50d59f0a409dc0a0fd;p=i3%2Fi3 diff --git a/docs/debugging b/docs/debugging index d32329d4..dd26f98d 100644 --- a/docs/debugging +++ b/docs/debugging @@ -1,98 +1,176 @@ Debugging i3: How To -================== -Michael Stapelberg -April 2009 +==================== +Michael Stapelberg +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 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. +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 +---------------------------------- --------------------------------------------------------------------- -exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1 --------------------------------------------------------------------- +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: -== Enabling coredumps +------------------------------ +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 cannot restart i3 for some reason, you can enable debug logging on the +fly: -------------------- -ulimit -c unlimited -------------------- +--------------------------------------- +i3-msg 'debuglog on; shmlog on; reload' +--------------------------------------- -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: +== Reproducing the problem ---------------------------------------------- -sudo sysctl -w kernel.core_pattern=core.%e.%p ---------------------------------------------- +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: -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+. +* 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. -== Compiling with debug symbols +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. -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) ----------------- +[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: -You should get an output like this: ------------------------------------------------------------------------------ +$ 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 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. - -== Generating a backtrace +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 that coredumps -are enabled, you can start getting some sense out of the coredumps. +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. -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. +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. -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): +== Sending bug reports/debugging on IRC ----------------------------- -gdb $(which i3) core.i3.3849 ----------------------------- +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. -Then, generate a backtrace using: +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. --------------- -backtrace full --------------- +== Debugging i3bar -== Sending bugreports/debugging on IRC +To debug i3bar problems, 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.