From: Michael Stapelberg Date: Sun, 12 Feb 2012 11:17:03 +0000 (+0000) Subject: docs/debugging: cover development version, add debugging-release-version X-Git-Tag: 4.2~82 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=c3125b44242c5e28e4ad49d6f81169e18e69e281;p=i3%2Fi3 docs/debugging: cover development version, add debugging-release-version --- diff --git a/docs/Makefile b/docs/Makefile index d1e0768a..514e1def 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -1,7 +1,7 @@ # To pass additional parameters for asciidoc ASCIIDOC=asciidoc -all: hacking-howto.html debugging.html userguide.html ipc.html multi-monitor.html wsbar.html refcard.pdf testsuite.html +all: hacking-howto.html debugging.html debugging-release-version.html userguide.html ipc.html multi-monitor.html wsbar.html refcard.pdf testsuite.html hacking-howto.html: hacking-howto $(ASCIIDOC) -a toc -n $< @@ -9,6 +9,9 @@ hacking-howto.html: hacking-howto debugging.html: debugging $(ASCIIDOC) -n $< +debugging-release-version.html: debugging-release-version + $(ASCIIDOC) -n $< + userguide.html: userguide $(ASCIIDOC) -a toc -n $< diff --git a/docs/debugging b/docs/debugging index 5e71ecf0..35460847 100644 --- a/docs/debugging +++ b/docs/debugging @@ -1,7 +1,7 @@ Debugging i3: How To ==================== -Michael Stapelberg -July 2011 +Michael Stapelberg +February 2012 This document describes how to debug i3 suitably for sending us useful bug reports, even if you have no clue of C programming. @@ -10,100 +10,79 @@ 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! -== Enabling logging +== Verify you are using the latest (development) version -i3 logs useful information to stdout. To have a clearly defined place where log -files will be saved, you should redirect stdout and stderr in your -+~/.xsession+. While you’re at it, putting each run of i3 in a separate log -file with date/time in its filename is a good idea to not get confused about -the different log files later on. +Please verify that you are using the latest version of i3: --------------------------------------------------------------------- -exec /usr/bin/i3 >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 --------------------------------------------------------------------- - -To enable verbose output and all levels of debug output (required when -attaching logfiles to bugreports), add the parameters +-V -d all+, like this: - --------------------------------------------------------------------- -exec /usr/bin/i3 -V -d all >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 --------------------------------------------------------------------- - -== Enabling core dumps +--------------- +$ i3 --version +i3 version 4.1.2-248-g51728ba (2012-02-12, branch "next") +--------------- -When i3 crashes, often you have the chance of getting a 'core dump' (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 core dumps, -use the following command (in your +~/.xsession+, before starting i3): +Your version can look like this: -------------------- -ulimit -c unlimited -------------------- +4.1.2:: +You are using a release version. Please +upgrade to a development version first, or read +link:debugging-release-version[Debugging i3: How To (release version)]. -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-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. ---------------------------------------------- -sudo sysctl -w kernel.core_pattern=core.%e.%p ---------------------------------------------- +Development versions of i3 have several properties which make debugging easier: -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+. +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. -== Compiling with debug symbols +== Obtaining the debug logfile -To actually get useful core dumps, you should make sure that your version of i3 -is compiled with debug symbols, that is, that the symbols are not stripped -during the build process. You can check whether your executable contains -symbols by issuing the following command: +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. ----------------- -file $(which 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 ------------------------------------------------------------------------------- - -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. +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 +-------------------------------------------------------------------- -== Generating a backtrace +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: -Once you have made sure that your i3 is compiled with debug symbols and that -core dumps are enabled, you can start making sense out of the core dumps. +-------------------------------------------------------------------- +DISPLAY=:0 i3-dump-log | gzip -9c > /tmp/i3.log.gz +-------------------------------------------------------------------- -Because the core dump 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 core dump might be useless afterwards. +== Obtaining a backtrace -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 -core dump of course): +When i3 displays its crash dialog, do the following: ----------------------------- -gdb $(which i3) core.i3.3849 ----------------------------- +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 -Then, generate a backtrace using: +This is how you get a backtrace from a running i3 process: --------------- -backtrace full --------------- +----------------- +I3PID=$(pidof i3) +gdb /proc/$I3PID/exe $I3PID \ + --batch --quiet \ + --ex 'backtrace full' > /tmp/i3-backtrace.txt 2>&1 +----------------- == Sending bug reports/debugging on IRC -When sending bug reports, 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 core dump). +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. 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 diff --git a/docs/debugging-release-version b/docs/debugging-release-version new file mode 100644 index 00000000..71aa7737 --- /dev/null +++ b/docs/debugging-release-version @@ -0,0 +1,126 @@ +Debugging i3: How To (release version) +====================================== +Michael Stapelberg +February 2012 + +This document describes how to debug i3 suitably for sending us useful bug +reports, even if you have no clue 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! + +NOTE: This document is for the release version of i3. If you are using a +development version, please see link:debugging.html[Debugging i3: How To] +instead. + +== Consider using the development version + +This document is for the release version of i3. In many cases, bugs are already +fixed in the development version of i3. If they aren’t, we will still ask you +to reproduce your error with the most recent development version of i3. +Therefore, please upgrade to a development version and continue reading at +link:debugging.html[Debugging i3: How To]. + +If you absolutely cannot upgrade to a development version of i3, you may +continue reading this document. + +== Enabling logging + +i3 logs useful information to stdout. To have a clearly defined place where log +files will be saved, you should redirect stdout and stderr in your ++~/.xsession+. While you’re at it, putting each run of i3 in a separate log +file with date/time in its filename is a good idea to not get confused about +the different log files later on. + +-------------------------------------------------------------------- +exec /usr/bin/i3 >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 +-------------------------------------------------------------------- + +To enable verbose output and all levels of debug output (required when +attaching logfiles to bugreports), add the parameters +-V -d all+, like this: + +-------------------------------------------------------------------- +exec /usr/bin/i3 -V -d all >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 +-------------------------------------------------------------------- + +== Enabling core dumps + +When i3 crashes, often you have the chance of getting a 'core dump' (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 core dumps, +use the following command (in your +~/.xsession+, before starting i3): + +------------------- +ulimit -c unlimited +------------------- + +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: + +--------------------------------------------- +sudo sysctl -w kernel.core_pattern=core.%e.%p +--------------------------------------------- + +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+. + +== Compiling with debug symbols + +To actually get useful core dumps, you should make sure that your version of i3 +is compiled with debug symbols, that is, that the symbols are not stripped +during the build process. You can check whether your executable contains +symbols by issuing the following command: + +---------------- +file $(which 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 +------------------------------------------------------------------------------ + +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 + +Once you have made sure that your i3 is compiled with debug symbols and that +core dumps are enabled, you can start making sense out of the core dumps. + +Because the core dump 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 core dump 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 +core dump of course): + +---------------------------- +gdb $(which i3) core.i3.3849 +---------------------------- + +Then, generate a backtrace using: + +-------------- +backtrace full +-------------- + +== Sending bug reports/debugging on IRC + +When sending bug reports, 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 core dump). + +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.