From OpenSimulator
Contents |
Testing Report
See Testing.
Reporting Bugs
OpenSim is alpha software, this means that there are frequent bugs in the codebase, and many features that still need implementing. You can help us find and fix these problems by reporting bugs to us, our bug tracker also accepts patches if you are able to fix the bug.
Steps for reporting a bug
- Visit opensimulator.org/mantis and search to see if your bug already exists. If it does, please add a note with any technical assistance such as steps to reproduce, symptoms, etc.
- A good bug report has the following properties
- Succinct and to the point, IE: "Duplicating a primitive while sitting on it, crashes the region.".
- Contains as much debug information as possible, if OpenSim threw an error before crashing it, a copy of this error is helpful. If not, pasting the last 50 lines from your opensim.log when appropriate is also potentially helpful.
- If you can reproduce the bug, steps to reproducing it is a must.
- Please do not submit bugs such as "OpenSim eats a lot of CPU time" without including information about your setup, and anything you or we may have done to trigger this, unfortunately we are not psychic and cannot guess what may have happened.
- Create an account on the opensim mantis website, and hit 'Report new issue'. Please note that some free email providers may take a while for the confirmation email to appear.
Bug States in Mantis
One of the goals is to get as many issues out of the new state as possible and get turned into good bugs that can be acted upon. Below is a lightweight state diagram that should help in deciding what state is appropriate for bugs in mantis.
Some comments on states:
- Bugs don't have to flow through all states to land somewhere. For instance, if a bug starts with a well written up description, and the person triaging the bug has seen the same issue, it can be moved straight to confirmed. As with everything, these are rough guidelines, use your judgement.
- A bug will be marked Resolved if the person working the bug believes it is fixed even if there isn't final confirmation from the reporter. If the reporter finds it is not fixed, please just reopen the bug and add comments accordingly.
- Please leave closing of bugs to core team. A closed bug means we think it's gone forever, or the bug report is invalid.
Submitting Patches
You can submit your patch as a unified diff (`diff -u`) as a .patch file on any issue on Mantis. You should also move the bug into the Patch Included state to let us know there's a patch waiting to be applied. If you are using TortoiseSVN on Windows, you can right-click in the opensim directory and select "Create patch" to create a unified diff.
Please submit patches with diffs from the root OpenSim directory rather than in the directory of the source file/s you're changing.
If you patch is not applied within approximately a week, please let a developer know on the -dev mailing list, or IRC channel and we will take a look at it. Please note not every patch is accepted - sometimes a solution may not be appropriate (and could break other things).
Top Ten Bugs
This is the place to concentrate on the top 10 bugs of the current week. It will change from week to week, but hopefully will allow some focus for testing and resolution. In order to be in this list, a bug should be really serious, that is, causes a crash or loss of data and keeps more then one group from moving forward. It also must be a Mantis entry. In addition, notes added to any of these top 10 bugs that confirm (or deny) across Windows/Linux/Mac/Standalone/Grid environments will help to duplicate and resolve.
I will attempt to add clarity to this list from time to time, but others are encouraged to add up to a total of 10 bugs to be used to focus our current weeks efforts. (Charles Krinke).
1. Mantis#305 Region Silence, Caps handler but no Agent/Circuit created. This but precludes new logins to a heavily used region and the console tends to deny additional connections.
2. Mantis#641: Replace BlockingQueue with better solution. Replace "BlockingQueue PacketQueue<QueuePacket>" with real class based solution to the releasing of just one thread per enqueue. We have to have the external lock because under Mono (untested on win) the BLockingQueue Monitor.Pulse(m_queueLock) causes all threads to release, which triggers all threads but one to attempt a dequeue for the same entry.
3.
4.
5.
6.
7.
8.
9.
10. UNIQ3e71c24452916944-cleanpage-00000000-QINU
