Reporting bugs

Since our developers are unable to test every hardware combination, nor every different way of interacting with the operating system, we are relying on users to give us some input on how things work at their end. Since Haiku is still quite young, it's very likely that you will encounter bugs. We thank you for taking the time to report these. Together we can improve Haiku, bit by bit.

To keep our bugtracker effective, it's essential to abide by the Bug Tracker Etiquette.

Getting a Trac account

To file a ticket, you need to have an account at Haiku's Bugtracker.
When creating a new account, be certain to provide your email address as it is necessary to obtain basic ticket modification privileges. Be sure to check your spam folder shortly afterwards, as the all important verification mail often ends up there.

Creating a bug report

Before reporting a bug, please make sure that it does not yet exist. You can also use the search function for this.
After you have established that it's a unique bug, make your information as accurate as possible:

• Include basic information such as how you are testing Haiku (on real hardware, on VMWare, on QEMU, etc.).

• Mention which revision from SVN you are running. You can find this information in 'About This System...' from the Deskbar menu.

• Describe the problem you are experiencing. Try to be as accurate as you can: describe the actual behavior, and the behavior you expected.

• Describe what steps you need to perform in order to expose the bug. This will help developers reproduce the bug.

• Attach as much information as you have. If it is a GUI bug, or a bug in one of the applications, try to make a screen shot (the PRINT key saves a PNG in /boot/home/).

Software Bugs

When an application crashed, you should invoke the debugger from the alert that pops up. Entering bt into the launched debug Terminal, you create a "backtrace" that you should copy into your bug report.

Hardware Bugs

When dealing with a hardware/driver related bug, you should attach the following information:

• listdev - a detailed listing of your hardware, including vendor and pci id's, similar to Linux' lshw and lspci.
• listusb -v - assuming its a USB related issue, similar to lsusb.
• open /var/log/syslog - the primary system log used by Haiku, akin to on screen debugging during boot. With the open command you can crop down the relevant part of the syslog in a text editor.
• listimage | grep drivers/ - lists all used drivers.
• ints - only available within Kernel Debugging Land (see below). Shows interrupt usage. There shouldn't be too many that are shared by different devices.

You enter these commands into Terminal. Add a > output.txt after a command, and it's piped into a text file called "output.txt" that you can attach to your bug report or email.

Kernel Debugging Land - KDL

When some very low level system component crashed, you may end up in the kernel debugger. It can also be entered deliberately with ALTSysReqD (SysReq being PRINT on most keyboards).

• co - will exit KDL and continue normal system operation, if possible.
• int - will show interrupt usage (as described above).
• bt - shows a backtrace, detailing where exactly the crash happened.

What's next?

After the bug has been reported, a developer will look at your bug and try to classify it. Remember, we are all volunteers, and as such, sometimes a bug report might go unanswered for a while. Adding new information when it becomes available usually helps getting a bug picked up quicker, but do not try to 'bump' the bug up by adding non-descriptive comments.

Remember, reporting a bug is not something you spend a little time on and then you are done. If you reported a bug, then you are part of the Haiku development process. Developers might come up with questions while they are trying to fix your bug. Please stay around to answer these. Consider your participation 'done' when the bug is marked as 'fixed'.