docs/debugging: cover development version, add debugging-release-version
Michael Stapelberg
parent
51728bab77
commit
c3125b4424
|
|
@ -1,7 +1,7 @@
|
|||
# To pass additional parameters for 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
|
||||
$(ASCIIDOC) -a toc -n $<
|
||||
|
|
@ -9,6 +9,9 @@ hacking-howto.html: hacking-howto
|
|||
debugging.html: debugging
|
||||
$(ASCIIDOC) -n $<
|
||||
|
||||
debugging-release-version.html: debugging-release-version
|
||||
$(ASCIIDOC) -n $<
|
||||
|
||||
userguide.html: userguide
|
||||
$(ASCIIDOC) -a toc -n $<
|
||||
|
||||
|
|
|
|||
139
docs/debugging
139
docs/debugging
|
|
@ -1,7 +1,7 @@
|
|||
Debugging i3: How To
|
||||
====================
|
||||
Michael Stapelberg <michael+i3@stapelberg.de>
|
||||
July 2011
|
||||
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.
|
||||
|
|
@ -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
|
||||
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
|
||||
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.
|
||||
Please verify that you are using the latest version of i3:
|
||||
|
||||
---------------
|
||||
$ 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
|
||||
attaching logfiles to bugreports), add the parameters +-V -d all+, like this:
|
||||
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:
|
||||
|
||||
--------------------------------------------------------------------
|
||||
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
|
||||
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):
|
||||
When i3 displays its crash dialog, do the following:
|
||||
|
||||
-------------------
|
||||
ulimit -c unlimited
|
||||
-------------------
|
||||
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
|
||||
|
||||
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:
|
||||
This is how you get a backtrace from a running i3 process:
|
||||
|
||||
---------------------------------------------
|
||||
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
|
||||
--------------
|
||||
-----------------
|
||||
I3PID=$(pidof i3)
|
||||
gdb /proc/$I3PID/exe $I3PID \
|
||||
--batch --quiet \
|
||||
--ex 'backtrace full' > /tmp/i3-backtrace.txt 2>&1
|
||||
-----------------
|
||||
|
||||
== 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 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.
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue