git.sur5r.net Git - i3/i3.github.io/blob - _docs/debugging-release-version

   1 Debugging i3: How To (release version)
   2 ======================================
   3 Michael Stapelberg <michael@i3wm.org>
   4 February 2012
   5
   6 This document describes how to debug i3 suitably for sending us useful bug
   7 reports, even if you have no clue of C programming.
   8
   9 First of all: Thank you for being interested in debugging i3. It really means
  10 something to us to get your bug fixed. If you have any questions about the
  11 debugging and/or need further help, do not hesitate to contact us!
  12
  13 NOTE: This document is for the release version of i3. If you are using a
  14 development version, please see link:debugging.html[Debugging i3: How To]
  15 instead.
  16
  17 == Consider using the development version
  18
  19 This document is for the release version of i3. In many cases, bugs are already
  20 fixed in the development version of i3. If they aren’t, we will still ask you
  21 to reproduce your error with the most recent development version of i3.
  22 Therefore, please upgrade to a development version and continue reading at
  23 link:debugging.html[Debugging i3: How To].
  24
  25 If you absolutely cannot upgrade to a development version of i3, you may
  26 continue reading this document.
  27
  28 == Enabling logging
  29
  30 i3 logs useful information to stdout. To have a clearly defined place where log
  31 files will be saved, you should redirect stdout and stderr in your
  32 +~/.xsession+. While you’re at it, putting each run of i3 in a separate log
  33 file with date/time in its filename is a good idea to not get confused about
  34 the different log files later on.
  35
  36 --------------------------------------------------------------------
  37 exec /usr/bin/i3 >~/i3log-$(date +'%F-%k-%M-%S') 2>&1
  38 --------------------------------------------------------------------
  39
  40 To enable verbose output and all levels of debug output (required when
  41 attaching logfiles to bugreports), add the parameters +-V -d all+, like this:
  42
  43 --------------------------------------------------------------------
  44 exec /usr/bin/i3 -V -d all >~/i3log-$(date +'%F-%k-%M-%S') 2>&1
  45 --------------------------------------------------------------------
  46
  47 == Enabling core dumps
  48
  49 When i3 crashes, often you have the chance of getting a 'core dump' (an image
  50 of the memory of the i3 process which can be loaded into a debugger). To get a
  51 core dump, you have to make sure that the user limit for core dump files is set
  52 high enough. Many systems ship with a default value which even forbids core
  53 dumps completely. To disable the limit completely and thus enable core dumps,
  54 use the following command (in your +~/.xsession+, before starting i3):
  55
  56 -------------------
  57 ulimit -c unlimited
  58 -------------------
  59
  60 Furthermore, to easily recognize core dumps and allow multiple of them, you
  61 should set a custom core dump filename pattern, using a command like the
  62 following:
  63
  64 ---------------------------------------------
  65 sudo sysctl -w kernel.core_pattern=core.%e.%p
  66 ---------------------------------------------
  67
  68 This will generate files which have the executable’s file name (%e) and the
  69 process id (%p) in it. You can save this setting across reboots using
  70 +/etc/sysctl.conf+.
  71
  72 == Compiling with debug symbols
  73
  74 To actually get useful core dumps, you should make sure that your version of i3
  75 is compiled with debug symbols, that is, that the symbols are not stripped
  76 during the build process. You can check whether your executable contains
  77 symbols by issuing the following command:
  78
  79 ----------------
  80 file $(which i3)
  81 ----------------
  82
  83 You should get an output like this:
  84 ------------------------------------------------------------------------------
  85 /usr/bin/i3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
  86 linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
  87 ------------------------------------------------------------------------------
  88
  89 Notice the +not stripped+, which is the important part. If you have a version
  90 which is stripped, please have a look if your distribution provides debug
  91 symbols (package +i3-wm-dbg+ on Debian for example) or if you can turn off
  92 stripping. If nothing helps, please build i3 from source.
  93
  94 == Generating a backtrace
  95
  96 Once you have made sure that your i3 is compiled with debug symbols and that
  97 core dumps are enabled, you can start making sense out of the core dumps.
  98
  99 Because the core dump depends on the original executable (and its debug
 100 symbols), please do this as soon as you encounter the problem. If you
 101 re-compile i3, your core dump might be useless afterwards.
 102
 103 Please install +gdb+, a debugger for C. No worries, you don’t need to learn it
 104 now.  Start gdb using the following command (replacing the actual name of the
 105 core dump of course):
 106
 107 ----------------------------
 108 gdb $(which i3) core.i3.3849
 109 ----------------------------
 110
 111 Then, generate a backtrace using:
 112
 113 --------------
 114 backtrace full
 115 --------------
 116
 117 == Sending bug reports/debugging on IRC
 118
 119 When sending bug reports, please paste the relevant part of the log (if in
 120 doubt, please send us rather too much information than too less) and the whole
 121 backtrace (if there was a core dump).
 122
 123 When debugging with us in IRC, be prepared to use a so called nopaste service
 124 such as http://nopaste.info or http://pastebin.com because pasting large
 125 amounts of text in IRC sometimes leads to incomplete lines (servers have line
 126 length limitations) or flood kicks.