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