X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fdebugging;h=35460847db49b7987abf604988b2d07b6a857b86;hb=06a9820b5f4b6172aa93758d245daa64dfd74887;hp=5dfd95ebed93e558e2781edb96119c6d8ab8a949;hpb=67d985ab8acd32c509c58d7205214a19221087cc;p=i3%2Fi3 diff --git a/docs/debugging b/docs/debugging index 5dfd95eb..35460847 100644 --- a/docs/debugging +++ b/docs/debugging @@ -1,124 +1,90 @@ Debugging i3: How To -================== -Michael Stapelberg -April 2009 - -This document describes how to debug i3 suitably for sending us useful bug reports, even -if you have no clue of C programming. +==================== +Michael Stapelberg +February 2012 -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! +This document describes how to debug i3 suitably for sending us useful bug +reports, even if you have no clue of C programming. -== Enabling logging - -i3 spits out much information onto stdout. To have a clearly defined place where logfiles -will be saved, you should redirect stdout 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. +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! ---------------------------------------------------------------- -exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') ---------------------------------------------------------------- +== Verify you are using the latest (development) version -== Enabling coredumps +Please verify that you are using the latest version of i3: -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): +--------------- +$ i3 --version +i3 version 4.1.2-248-g51728ba (2012-02-12, branch "next") +--------------- -------------------- -ulimit -c unlimited -------------------- +Your version can look like this: -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:: +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)]. ---------------------------------------------- -sudo sysctl -w kernel.core_pattern=core.%e.%p ---------------------------------------------- +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. -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+. +Development versions of i3 have several properties which make debugging easier: -== Compiling with debug symbols +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. -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) ----------------- +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. -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 ------------------------------------------------------------------------------- +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 +-------------------------------------------------------------------- -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. +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: -== Generating a backtrace +-------------------------------------------------------------------- +DISPLAY=:0 i3-dump-log | gzip -9c > /tmp/i3.log.gz +-------------------------------------------------------------------- -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. +== Obtaining a backtrace -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. +When i3 displays its crash dialog, do the following: -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): +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 ----------------------------- -gdb $(which i3) core.i3.3849 ----------------------------- +This is how you get a backtrace from a running i3 process: -Then, generate a backtrace using: +----------------- +I3PID=$(pidof i3) +gdb /proc/$I3PID/exe $I3PID \ + --batch --quiet \ + --ex 'backtrace full' > /tmp/i3-backtrace.txt 2>&1 +----------------- ---------- -backtrace ---------- +== Sending bug reports/debugging on IRC -Also, getting an overview of the local variables might help: ------------ -info locals ------------ +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. -If your backtrace looks like this: ---------------------------------------------------------------------------------------------------- -(gdb) backtrace -#0 0x041b1a01 in vfprintf () from /lib/libc.so.6 -#1 0x041b2f80 in vprintf () from /lib/libc.so.6 -#2 0x080555de in slog (fmt=0x8059ba0 "%s:%s:%d - Name should change to \"%s\"\n") at src/util.c:60 -#3 0x0804fa73 in handle_windowname_change_legacy (data=0x0, conn=0x42da908, - state=0 '\0', window=8389918, atom=39, prop=0x4303f90) at src/handlers.c:752 -#4 0x0406cace in ?? () from /usr/lib/libxcb-property.so.1 -#5 0x00000000 in ?? () ---------------------------------------------------------------------------------------------------- - -you need to find the first frame which actually belongs to i3 code. You can easily spot them, as -their filename starts with src/ and has a line number. In this case, frame 2 would be the correct -frame, so before getting the local variables, switch to frame 2: - ------------ -frame 2 -info locals ------------ - -== Sending bugreports/debugging on IRC - -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). - -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 +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.