Difference between revisions of "How to report a crash in a most useful way (with a backtrace)"
Jump to navigation
Jump to search
(Add some prolog text) |
(Update formatting) |
||
Line 3: | Line 3: | ||
In cases when crashes are hard to reproduce on another machine (for example, when user has relatively rare file system or specific operating system), stack trace can be very important to help fixing the bug. | In cases when crashes are hard to reproduce on another machine (for example, when user has relatively rare file system or specific operating system), stack trace can be very important to help fixing the bug. | ||
− | Here is how to make a backtrace and what to do with it ('''ideally debug version should be used to make a backtrace | + | Here is how to make a backtrace and what to do with it ('''ideally''' debug version should be used to make a backtrace, but backtrace from release version can be useful too): |
− | # Start debugging session with <code>gdb</code>. <br | + | # Start debugging session with <code>gdb</code>. <br>Run <code>gdb vifm</code> or <code>gdb ./vifm</code> (if debugging executable that is not installed to system directory) in shell. |
− | # Run vifm under debugger. <br | + | # Run vifm under debugger. <br>Execute <code>run</code> command in the command prompt of the <code>gdb</code>. |
− | # Make debugging process stop. <br | + | # Make debugging process stop. <br>Make vifm crash. |
− | # Redirect output of <code>gdb</code> commands to a file. <br | + | # Redirect output of <code>gdb</code> commands to a file. <br>Execute <code>set logging file {out-file}</code> in the command prompt of the <code>gdb</code>, where <code>{out-file}</code> can be for example: <code>~/vifm-crash.bt</code>.<br>Execute <code>set logging on</code> on the command prompt of the <code>gdb</code> to enable logging. |
− | # Output back trace with values of all local variables. <br | + | # Output back trace with values of all local variables. <br>Execute <code>bt full</code> (<code>backtrace full</code> is full form of the command) in the command prompt of the <code>gdb</code>. |
− | # Quit <code>gdb</code>. <br | + | # Quit <code>gdb</code>. <br>Execute <code>quit</code> command (or just <code>q</code>, or even <code>ctrl-d</code> shortcut) in the command prompt of the <code>gdb</code>. |
− | # Upload file with the logged output of the <code>bt</code> command (e.g. <code>~/vifm-crash.bt</code>) somewhere (e.g. on bug tracker, or make a [https://gist.github.com/ Gist] or to [http://pastebin.com/ pastebin]) or send as an attachment to the maintainer ([mailto:xaizek@openmailbox.org xaizek@openmailbox.org]); please do not include it in the message itself as it might make it unreadable. <br | + | # Upload file with the logged output of the <code>bt</code> command (e.g. <code>~/vifm-crash.bt</code>) somewhere (e.g. on bug tracker, or make a [https://gist.github.com/ Gist] or to [http://pastebin.com/ pastebin]) or send as an attachment to the maintainer ([mailto:xaizek@openmailbox.org xaizek@openmailbox.org]); please do not include it in the message itself as it might make it unreadable. <br>One might want to archive it, e.g. by running <code>gzip {file}</code>, which will replace <code>{file}</code> with <code>{file}.gz</code>, but it's not required. |
Revision as of 17:56, 29 March 2015
This is not a requirement, but something that may speed up fixing the bug.
In cases when crashes are hard to reproduce on another machine (for example, when user has relatively rare file system or specific operating system), stack trace can be very important to help fixing the bug.
Here is how to make a backtrace and what to do with it (ideally debug version should be used to make a backtrace, but backtrace from release version can be useful too):
- Start debugging session with
gdb
.
Rungdb vifm
orgdb ./vifm
(if debugging executable that is not installed to system directory) in shell. - Run vifm under debugger.
Executerun
command in the command prompt of thegdb
. - Make debugging process stop.
Make vifm crash. - Redirect output of
gdb
commands to a file.
Executeset logging file {out-file}
in the command prompt of thegdb
, where{out-file}
can be for example:~/vifm-crash.bt
.
Executeset logging on
on the command prompt of thegdb
to enable logging. - Output back trace with values of all local variables.
Executebt full
(backtrace full
is full form of the command) in the command prompt of thegdb
. - Quit
gdb
.
Executequit
command (or justq
, or evenctrl-d
shortcut) in the command prompt of thegdb
. - Upload file with the logged output of the
bt
command (e.g.~/vifm-crash.bt
) somewhere (e.g. on bug tracker, or make a Gist or to pastebin) or send as an attachment to the maintainer (xaizek@openmailbox.org); please do not include it in the message itself as it might make it unreadable.
One might want to archive it, e.g. by runninggzip {file}
, which will replace{file}
with{file}.gz
, but it's not required.