How to report a bug
It's Probably a Bug!
Some users are timid about submitting bugs. They might think that they "did" something to the program to cause it to misbehave. Don't be afraid! It probably is a bug, and if it's not that's ok too. In particular, the following are almost certainly signs of a bug:
- Ardour crashed with "Illegal Operation" or segmentation fault
- Ardour "freezes" and stops responding, or worse, causes your entire computer to "freeze".
- Ardour won't do X correctly (record, open a session, etc.)
Before making "usability suggestions ...
... you should read this first.How To Report A Bug
Ardour uses a system called Mantis to keep track of bugs. Mantis is easy to use and makes it easy to see how your bug has progressed, and when it is resolved.
If you insist on using email or the forums on ardour.org to report a bug (which is the wrong thing to do, but ...) then you should ALWAYS include the precise version of Ardour you are using (available in the "About" window, the version of JACK you are using (available using the command jackd --version, the type of audio interface you are using, and the platform (OS X Tiger/Leopard, Intel, PPC, Debian Sid, UbuntuStudio Lenny, PlanetCCRMA etc.). It would also be worth mentioning how much RAM you have installed, the capacity and rotational speed (7200,5400 etc) of your disk(s), and how much space you have on the disk(s). Failure to do this may result in your message being ignored.
To report a bug, you first must create a Mantis account (Link will open in new window). This is easy and only requires a valid email address. Once you create your account, a password will be mailed to the email address you specified. You only need to create an account once, and you can use it from then on out to report as many bugs as you can find.
Once you receive the password, you can enter a new bug report (new window). Be sure to add as many details as possible: if there's too few to reproduce the bug, it will be closed (no, we cannot read your mind!).
After you've submitted a bug, you can always go back and add more details. To do this, just go to Mantis's "Open and reported by me" link on the first page. You can then go into your bug and add additional "bugnotes". It is important to understand that when the bug is related to a particular session (i.e. it doesn't happen on other sessions), we need to get a copy of the session to be able to work on the bug: the conditions causing the bug may be very specific to your session - and recreating a similar session from a description is beyond what we can spend resources on. We are working on an easy to use tool to make this possible.
Crashing bugs
Bugs that crash Ardour are generally considered extremely serious and receive first priority in the queue (unless they are caused by things outside our control, in which case we try to document causes and workarounds). However, one of the problems with such bugs is that its often hard for developers to reproduce them, and so its important that you supply as much information as possible.
OS X specific information
OS X users are requested to enable the Crash Reporter (Your /etc/hostconfig file should contain: CRASHREPORTER=-YES-). If Ardour crashes and produces a crash report, then you should attach the contents of the crash log to your bug report as an attachment (or paste it directly into the "More Information" field).
Linux specific information
If you are a reasonably experienced programmer you could help us debug ardour. Otherwise, just submit a bug report and consider hanging out on our IRC channel in case we need more information from you.
What Should I Expect Afterwards?
Bugs generally move through the following stages:
- New
- this means that it's in Mantis, but nobody has done anything with it (except perhaps read it)
- Acknowledged
- often, a new bug will become acknowledged just to that we can tell you that we've seen it and are looking into it. Sometimes, this stage will be skipped.
- Feedback
- This means that we need more information from you (or other people) about the bug you've reported.
- Assigned
- This means that someone has taken on the responsibility of fixing this particular bug. No time frame for a fix is implied by a bug entering this stage.
- Resolved
- This means that the developer who worked on the fix believes that the problem is solved. Bugs remain in state once they enter it, right up until you, the reporter of the bug, mark them ...
- Closed
- This means that the bug reporter (you) has confirmed that the bug is fixed. In general, we rely on reporters to close bugs they reported. You can do this at any time, which can be useful if a new version of Ardour fixes the bug as a side-effect without any developer explicitly attempting to fix the bug. Just mark it closed if this happens, with a note on what happened.
You will generally receive email notifying you of any change in a bug's status, or when any new bugnotes are added to the bug.
How Long?
The time it takes for a bug to be fixed is largely dependent on how elusive the bug is. In general, you should receive some form of acknowledgement that your bug has been received.
In particular, if you included instructions on how to repeat the bug (recommended), then you will likely get some responses that say "I (was/was not) able to reproduce the bug." If other people can reproduce the bug, this is good and it will probably get resolved quickly. If the bug isn't reproducible, it may be awhile before it is cause is tracked down.
If the bug cannot be reproduced from the instructions provided, a deveoper will usually leave it in "feedback", with a bugnote asking for more information. This is a request for you to add more details or answer questions from the developer. If we don't hear from you within a reasonable time period, we will move the bug to "resolved", where it will remain until (and if) you do.
Recent Forum Comments
1 hour 3 min ago
8 hours 34 min ago
8 hours 43 min ago
17 hours 17 min ago
21 hours 7 min ago
22 hours 56 min ago
1 day 31 min ago
1 day 1 hour ago
1 day 8 hours ago
1 day 8 hours ago