-
Notifications
You must be signed in to change notification settings - Fork 7
Writing Useful Bug Reports
Adapted from the guide in the textmate/textmate repository
A good bug report must include the following four things:
-
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”)
-
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.
-
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.
-
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
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.
-
Install
qtox-dbg
package if you have installedqtox
, orqtox-alpha-dbg
if you have installedqtox-alpha
. -
Execute qTox under gdb:
$ gdb qtox
-
When the gdb prompt appears, run qTox and make it crash:
(gdb) run
-
When qTox crashes, return to the gdb prompt to acquire a backtrace:
(gdb) backtrace
-
If you want to collect info about all running threads:
(gdb) thread apply all backtrace full
-
Paste the backtrace somewhere (e.g. Gist or Pastebin), and provide a link to it in your bug report.
-
After you finish working with gdb, you may close it:
(gdb) quit
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*
- 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.
Some tips for troubleshooting qTox include:
- 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
If you'd like to read other articles describing methods for writing bug reports, the following list contains a few very good picks:
vruh