git.sur5r.net Git - i3/i3/blob - docs/debugging

   1 Debugging i3: How To
   2 ==================
   3 Michael Stapelberg <michael+i3@stapelberg.de>
   4 April 2009
   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 == Enabling logging
  14
  15 i3 spits out much information onto stdout. To have a clearly defined place
  16 where logfiles will be saved, you should redirect stdout and stderr in
  17 xsession. While you’re at it, putting each run of i3 in a separate logfile with
  18 date/time in it is a good idea to not get confused about the different logfiles
  19 later on.
  20
  21 --------------------------------------------------------------------
  22 exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1
  23 --------------------------------------------------------------------
  24
  25 == Enabling coredumps
  26
  27 When i3 crashes, often you have the chance of getting a coredump (an image of
  28 the memory of the i3 process which can be loaded into a debugger). To get a
  29 core-dump, you have to make sure that the user limit for core dump files is set
  30 high enough. Many systems ship with a default value which even forbids core
  31 dumps completely. To disable the limit completely and thus enable coredumps,
  32 use the following command (in your .xsession, before starting i3):
  33
  34 -------------------
  35 ulimit -c unlimited
  36 -------------------
  37
  38 Furthermore, to easily recognize core dumps and allow multiple of them, you
  39 should set a custom core dump filename pattern, using a command like the
  40 following:
  41
  42 ---------------------------------------------
  43 sudo sysctl -w kernel.core_pattern=core.%e.%p
  44 ---------------------------------------------
  45
  46 This will generate files which have the executable’s file name (%e) and the
  47 process id (%p) in it. You can save this setting across reboots using
  48 +/etc/sysctl.conf+.
  49
  50 == Compiling with debug symbols
  51
  52 To actually get useful coredumps, you should make sure that your version of i3
  53 is compiled with debug symbols, that is, that they are not stripped during the
  54 build process. You can check whether your executable contains symbols by
  55 issuing the following command:
  56
  57 ----------------
  58 file $(which i3)
  59 ----------------
  60
  61 You should get an output like this:
  62 ------------------------------------------------------------------------------
  63 /usr/bin/i3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
  64 linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
  65 ------------------------------------------------------------------------------
  66
  67 Notice the +not stripped+, which is the important part. If you have a version
  68 which is stripped, please have a look if your distribution provides debug
  69 symbols (package +i3-wm-dbg+ on Debian for example) or if you can turn off
  70 stripping. If nothing helps, please build i3 from source.
  71
  72 == Generating a backtrace
  73
  74 Once you have made sure that your i3 is compiled with debug symbols and that
  75 coredumps are enabled, you can start getting some sense out of the coredumps.
  76
  77 Because the coredump depends on the original executable (and its debug
  78 symbols), please do this as soon as you encounter the problem. If you
  79 re-compile i3, your coredump might be useless afterwards.
  80
  81 Please install +gdb+, a debugger for C. No worries, you don’t need to learn it
  82 now.  Start gdb using the following command (replacing the actual name of the
  83 coredump of course):
  84
  85 ----------------------------
  86 gdb $(which i3) core.i3.3849
  87 ----------------------------
  88
  89 Then, generate a backtrace using:
  90
  91 --------------
  92 backtrace full
  93 --------------
  94
  95 == Sending bugreports/debugging on IRC
  96
  97 When sending bugreports, please paste the relevant part of the log (if in
  98 doubt, please send us rather too much information than too less) and the whole
  99 backtrace (if there was a coredump).
 100
 101 When debugging with us in IRC, be prepared to use a so called nopaste service
 102 such as http://nopaste.info because pasting large amounts of text in IRC
 103 sometimes leads to incomplete lines (servers have line length limitations) or
 104 flood kicks.