How to report a crash in a most useful way (with a backtrace)
Jump to navigation
Jump to search
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.