Skip to content

Writing Useful Bug Reports

Jump to bottom
zetok edited this page Oct 12, 2015 · 12 revisions

##What To Include Adapted from the guide in the textmate/textmate repository

A good bug report must include the following four things:

  1. The steps to reproduce the bug: Give detailed steps on how to reproduce the problem.

    • Start from scratch
    • Explicitly mention every action involved, and how you invoked it (e.g., rather than “delete the text”, say “Select Cut from the context menu”)

  2. The expected behavior of the application: It’s important to include the result you’re expecting, as it might differ from how the program was designed to work.

  3. The observed behavior of the application: This is also important, since it’s possible that following your steps on a different system doesn’t reproduce the issue.

    • Include the data found in your qtox.log file. You can find the log in ~/.config/tox/ on UNIX-like platforms, and in %APPDATA\tox\ on Windows. Do not paste the log directly into the report. Post it somewhere else (e.g. Gist or Pastebin) and link to it.

  4. Information about your environment/platform

    • Include the operating system name/version
    • Include the version of qTox you are using. You can find a commit hash in the About tab in the settings menu.
    • If you are able to test multiple operating systems, do so
    • If your problem involves hardware, include information about that hardware
    • If your problem involves a crash, provide a backtrace

Providing Backtraces

If you are using a UNIX-like platform, and your bug involves qTox crashing, some of the most useful info you can provide would be found in a backtrace.

To acquire a backtrace, you will need to use gdb. You will also need to use the latest debug build of qTox. Debug binaries are available, but you don't have to use them if you know how to compile qTox with debugging symbols included.

####Acquiring The Backtrace

  1. Download a debug build of qTox: 32 bit or 64 bit

  2. Extract the binary:

    $ unxz qtox.xz

  3. Execute the binary under gdb:

    $ gdb ./qtox

  4. When the gdb prompt appears, run qTox and make it crash:

    (gdb) run

  5. When qTox crashes, return to the gdb prompt to acquire a backtrace:

    (gdb) backtrace

  6. If you want to collect info about all running threads:

    (gdb) thread apply all backtrace full

  7. Paste the backtrace somewhere (e.g. Gist or Pastebin), and provide a link to it in your bug report.

  8. After you finish working with gdb, you may close it:

    (gdb) quit

Bug Report Template

When reporting bugs, you may choose to use the following template, either in its entirety, or with non-applicable sections left out.

Brief Description:

Operating System: Windows / OS X / Linux (include version and/or distro)
qTox version: (shown on `About` page in settings)
Hardware: 
…

Reproducible: Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce


Steps to reproduce:
1. 
2. 
3. 
…


Observed Behavior:


Expected Behavior:


Additional info:
(links, images, etc go here)

If your issue includes images, upload them to github. Don't use imgur, etc.

If you're using multiple embedded images, be sure to include a description for every image, preferably using the following format:

++++++++
+IMAGE1+
++++++++
↑ *Description of Image 1*

++++++++
+IMAGE2+
++++++++
↑ *Description of Image 2*

##Misc. Bug Reporting Tips

  1. Always include text in English. If your English is not very good, you may optionally include text in your native language, so that someone else may attempt to translate it more appropriately for you.

##Misc. Troubleshooting Some tips for troubleshooting qTox include:

  1. Use Echobot for testing audio. If you start a voice/video call with Echobot, it will echo back all audio you send it with a 1-2 second delay. Echobot's ID can be found at Toxme

Reading Material

If you'd like to read other articles describing methods for writing bug reports, the following list contains a few very good picks:

vruh

Clone this wiki locally