How to report a crash in a most useful way (with a backtrace)

From Vifm Wiki
Revision as of 12:06, 20 October 2020 by Xaizek (talk | contribs) (Update e-mail address)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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. If it's easy to reproduce, this can be skipped.

Here is how to make a backtrace and what to do with it (ideally debug version should be used to make a backtrace (e.g. configured as ./configure CFLAGS='-g -O0'), but backtrace from release version can be useful too):

  1. Start debugging session with gdb.
    Run gdb vifm or gdb ./vifm (if debugging executable that is not installed to system directory) in shell.
  2. Run vifm under debugger.
    Execute run command in the command prompt of the gdb.
  3. Make debugging process stop.
    Make vifm crash.
  4. Redirect output of gdb commands to a file.
    Execute set logging file {out-file} in the command prompt of the gdb, where {out-file} can be for example: ~/
    Execute set logging on on the command prompt of the gdb to enable logging.
  5. Output back trace with values of all local variables.
    Execute bt full (backtrace full is full form of the command) in the command prompt of the gdb.
  6. Quit gdb.
    Execute quit command (or just q, or even ctrl-d shortcut) in the command prompt of the gdb.
  7. Upload file with the logged output of the bt command (e.g. ~/ somewhere (e.g. on bug tracker, or make a Gist or to pastebin) or send as an attachment to the maintainer (; please do not include it in the message itself as it might make it unreadable.
    One might want to archive it, e.g. by running gzip {file}, which will replace {file} with {file}.gz, but it's not required.