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

reformat docs/debugging

This commit is contained in:
Michael Stapelberg 2010-03-10 13:01:27 +01:00
parent 5d4d9681a0
commit 593bff5ffd
1 changed files with 45 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
docs/debugging
View File

@ -3,19 +3,20 @@ Debugging i3: How To
Michael Stapelberg <michael+i3@stapelberg.de> Michael Stapelberg <michael+i3@stapelberg.de>
April 2009 April 2009
This document describes how to debug i3 suitably for sending us useful bug reports, even This document describes how to debug i3 suitably for sending us useful bug
if you have no clue of C programming. 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 First of all: Thank you for being interested in debugging i3. It really means
to us to get your bug fixed. If you have any questions about the debugging and/or need something to us to get your bug fixed. If you have any questions about the
further help, do not hesitate to contact us! debugging and/or need further help, do not hesitate to contact us!
== Enabling logging == Enabling logging
i3 spits out much information onto stdout. To have a clearly defined place where logfiles i3 spits out much information onto stdout. To have a clearly defined place
will be saved, you should redirect stdout and stderr in xsession. While you’re at it, where logfiles will be saved, you should redirect stdout and stderr in
putting each run of i3 in a separate logfile with date/time in it is a good idea to not xsession. While you’re at it, putting each run of i3 in a separate logfile with
get confused about the different logfiles later on. date/time in it is a good idea to not get confused about the different logfiles
later on.
-------------------------------------------------------------------- --------------------------------------------------------------------
exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1 exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1
@ -23,32 +24,35 @@ exec /usr/bin/i3 >/home/michael/i3/i3log-$(date +'%F-%k-%M-%S') 2>&1
== Enabling coredumps == Enabling coredumps
When i3 crashes, often you have the chance of getting a coredump (an image of the memory When i3 crashes, often you have the chance of getting a coredump (an image of
of the i3 process which can be loaded into a debugger). To get a core-dump, you have to the memory of the i3 process which can be loaded into a debugger). To get a
make sure that the user limit for core dump files is set high enough. Many systems ship core-dump, you have to make sure that the user limit for core dump files is set
with a default value which even forbids core dumps completely. To disable the limit high enough. Many systems ship with a default value which even forbids core
completely and thus enable coredumps, use the following command (in your .xsession, before dumps completely. To disable the limit completely and thus enable coredumps,
starting i3): use the following command (in your .xsession, before starting i3):
------------------- -------------------
ulimit -c unlimited ulimit -c unlimited
------------------- -------------------
Furthermore, to easily recognize core dumps and allow multiple of them, you should set Furthermore, to easily recognize core dumps and allow multiple of them, you
a custom core dump filename pattern, using a command like the following: should set a custom core dump filename pattern, using a command like the
following:
--------------------------------------------- ---------------------------------------------
sudo sysctl -w kernel.core_pattern=core.%e.%p 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 This will generate files which have the executable’s file name (%e) and the
(%p) in it. You can save this setting across reboots using +/etc/sysctl.conf+. process id (%p) in it. You can save this setting across reboots using
+/etc/sysctl.conf+.
== Compiling with debug symbols == Compiling with debug symbols
To actually get useful coredumps, you should make sure that your version of i3 is compiled To actually get useful coredumps, you should make sure that your version of i3
with debug symbols, that is, that they are not stripped during the build process. You is compiled with debug symbols, that is, that they are not stripped during the
can check whether your executable contains symbols by issuing the following command: build process. You can check whether your executable contains symbols by
issuing the following command:
---------------- ----------------
file $(which i3) file $(which i3)
@ -60,23 +64,23 @@ You should get an output like this:
linked (uses shared libs), for GNU/Linux 2.6.18, not stripped 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 Notice the +not stripped+, which is the important part. If you have a version
stripped, please have a look if your distribution provides debug symbols (package +i3-wm-dbg+ which is stripped, please have a look if your distribution provides debug
on Debian for example) or if you can turn off stripping. If nothing helps, please build symbols (package +i3-wm-dbg+ on Debian for example) or if you can turn off
i3 from source. stripping. If nothing helps, please build i3 from source.
== Generating a backtrace == Generating a backtrace
Once you have made sure that your i3 is compiled with debug symbols and that coredumps Once you have made sure that your i3 is compiled with debug symbols and that
are enabled, you can start getting some sense out of the coredumps. coredumps are enabled, you can start getting some sense out of the coredumps.
Because the coredump depends on the original executable (and its debug symbols), please Because the coredump depends on the original executable (and its debug
do this as soon as you encounter the problem. If you re-compile i3, your coredump might symbols), please do this as soon as you encounter the problem. If you
be useless afterwards. re-compile i3, your coredump might be useless afterwards.
Please install +gdb+, a debugger for C. No worries, you don’t need to learn it now. Please install +gdb+, a debugger for C. No worries, you don’t need to learn it
Start gdb using the following command (replacing the actual name of the coredump of now. Start gdb using the following command (replacing the actual name of the
course): coredump of course):
---------------------------- ----------------------------
gdb $(which i3) core.i3.3849 gdb $(which i3) core.i3.3849
@ -90,9 +94,11 @@ backtrace full
== Sending bugreports/debugging on IRC == Sending bugreports/debugging on IRC
When sending bugreports, please paste the relevant part of the log (if in doubt, please send us rather When sending bugreports, please paste the relevant part of the log (if in
too much information than too less) and the whole backtrace (if there was a coredump). 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 When debugging with us in IRC, be prepared to use a so called nopaste service
because pasting large amounts of text in IRC sometimes leads to incomplete lines (servers have line such as http://nopaste.info because pasting large amounts of text in IRC
length limitations) or flood kicks. sometimes leads to incomplete lines (servers have line length limitations) or
flood kicks.