Revision as of 15:38, 11 May 2008

 

Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch    Français

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 your 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).

I have deliberately resisted the temptation to quote specific mantis entries in this list in the interest of presenting them from a ground-level perspective, as they impact the end-user. (daTwitch/Hiro Protagonist)

1. Avatar Instability. As it's been described to me, some external condition (physics? just a guess) perturbates the 'PID Controller' or 'collision capsule' of the avatar, and causes the avatar to sink into the ground, twitch wildly, thrash, appear to have it's head spin (close examination shows that the avatar is actually rotating 180 deg rapidly and snapping back, the effect is the head trailing the body), or 'stick' in flying or running animations regardless of avatar's actually sitting/standing/running/flying state), or any combination of these effects - it generally gets worse with increasing session length

2. Inventory Reliability. Inventory reliability is as variable as the weather. One day it works fully, one day your permissions are scrambled, one day you cant see into subfolders....'nuff said

3. Asset Transfer Reliability - seems to suffer right along with inventory. Some days, I get every prim everywhere I go. Other days, terrain is missing big patches, prims dont rez but are physically present, etc.

4. Child Agents rezzing as the default (non-ruth) avatar at 128,128,70 in adjacent region

5. *possibly* connected to #4: Parcel Description from Adjacent Region Showing in Client Window instead of local region description

6.

7.

8.

9.

10. UNIQ3d69ade2065dfd2-cleanpage-00000000-QINU