Difference between revisions of "How to report a crash in a most useful way (with a backtrace)"

From Vifm Wiki
Jump to navigation Jump to search
(Initial version of the page)
 
(Update e-mail address)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
# Start debugging session with <code>gdb</code>. <br><i>Run <code>gdb vifm</code> or <code>gdb ./vifm</code> (if debugging executable that is not installed to system directory) in shell.</i>
+
This is not a requirement, but something that may speed up fixing the bug.
# Run vifm under debugger. <br><i>Execute <code>run</code> command in the command prompt of the <code>gdb</code>.</i>
+
 
# Make debugging process stop.  <br><i>Make vifm crash.</i>
+
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.
# Redirect output of <code>gdb</code> commands to a file. <br><i>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.</i>
+
 
# Output back trace with values of all local variables. <br><i>Execute <code>bt full</code> (<code>backtrace full</code> is full form of the command) in the command prompt of the <code>gdb</code>.</i>
+
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 <code>./configure CFLAGS='-g -O0'</code>), but backtrace from release version can be useful too):
# Quit <code>gdb</code>. <br><i>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>.</i>
+
 
# 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><i>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.</i>
+
# 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>Execute <code>run</code> command in the command prompt of the <code>gdb</code>.
 +
# Make debugging process stop.  <br>Make vifm crash.
 +
# 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>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>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@posteo.net xaizek@posteo.net]); 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.

Latest revision as of 12:06, 20 October 2020

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: ~/vifm-crash.bt.
    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. ~/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@posteo.net); 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.