nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs/debugging: cover development version, add debugging-release-version

This commit is contained in:
Michael Stapelberg 2012-02-12 11:17:03 +00:00
parent 51728bab77
commit c3125b4424
3 changed files with 189 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/Makefile
View File

@ -1,7 +1,7 @@
# To pass additional parameters for asciidoc # To pass additional parameters for asciidoc
ASCIIDOC=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 hacking-howto.html: hacking-howto
$(ASCIIDOC) -a toc -n $< $(ASCIIDOC) -a toc -n $<
@ -9,6 +9,9 @@ hacking-howto.html: hacking-howto
debugging.html: debugging debugging.html: debugging
$(ASCIIDOC) -n $< $(ASCIIDOC) -n $<
debugging-release-version.html: debugging-release-version
$(ASCIIDOC) -n $<
userguide.html: userguide userguide.html: userguide
$(ASCIIDOC) -a toc -n $< $(ASCIIDOC) -a toc -n $<

139
docs/debugging
View File

@ -1,7 +1,7 @@
Debugging i3: How To Debugging i3: How To
==================== ====================
Michael Stapelberg <michael+i3@stapelberg.de> Michael Stapelberg <michael@i3wm.org>
July 2011 February 2012
This document describes how to debug i3 suitably for sending us useful bug This document describes how to debug i3 suitably for sending us useful bug
reports, even if you have no clue of C programming. 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 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! 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 Please verify that you are using the latest version of i3:
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.
---------------
$ i3 --version
i3 version 4.1.2-248-g51728ba (2012-02-12, branch "next")
---------------
Your version can look like this:
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)].
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.
Development versions of i3 have several properties which make debugging easier:
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.
== Obtaining the debug logfile
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.
To save a compressed version of the logfile (suitable for attaching it to a
bugreport), use:
-------------------------------------------------------------------- --------------------------------------------------------------------
exec /usr/bin/i3 >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 i3-dump-log | gzip -9c > /tmp/i3.log.gz
-------------------------------------------------------------------- --------------------------------------------------------------------
To enable verbose output and all levels of debug output (required when This command does not depend on i3 (it also works when i3 currently displays
attaching logfiles to bugreports), add the parameters +-V -d all+, like this: the crash dialog), but it requires a working X11 connection. When running it
from a virtual console (Ctrl-Alt-F1), use:
-------------------------------------------------------------------- --------------------------------------------------------------------
exec /usr/bin/i3 -V -d all >~/i3log-$(date +'%F-%k-%M-%S') 2>&1 DISPLAY=:0 i3-dump-log | gzip -9c > /tmp/i3.log.gz
-------------------------------------------------------------------- --------------------------------------------------------------------
== Enabling core dumps == Obtaining a backtrace
When i3 crashes, often you have the chance of getting a 'core dump' (an image When i3 displays its crash dialog, do the following:
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):
------------------- 1. Switch to a virtual console (Ctrl-Alt-F1) or login from a different computer
ulimit -c unlimited 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
Furthermore, to easily recognize core dumps and allow multiple of them, you This is how you get a backtrace from a running i3 process:
should set a custom core dump filename pattern, using a command like the
following:
--------------------------------------------- -----------------
sudo sysctl -w kernel.core_pattern=core.%e.%p I3PID=$(pidof i3)
--------------------------------------------- gdb /proc/$I3PID/exe $I3PID \
--batch --quiet \
This will generate files which have the executable’s file name (%e) and the --ex 'backtrace full' > /tmp/i3-backtrace.txt 2>&1
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 == Sending bug reports/debugging on IRC
When sending bug reports, please paste the relevant part of the log (if in When sending bug reports, please attach the *whole* log file. Even if you think
doubt, please send us rather too much information than too less) and the whole you found the section which clearly highlights the problem, additional
backtrace (if there was a core dump). information might be necessary to completely diagnose the problem.
When debugging with us in IRC, be prepared to use a so called nopaste service 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 such as http://nopaste.info or http://pastebin.com because pasting large

126
docs/debugging-release-version Normal file
View File

@ -0,0 +1,126 @@
Debugging i3: How To (release version)
======================================
Michael Stapelberg <michael@i3wm.org>
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.