Jump to: navigation, search


The aMSN Bug Database

Developers can visit http://www.amsn-project.net/bugs to view the bug reports sent in by users. When a bug occurs, amsn asks users to send the bug report to our database, this is where you can view and admin those bugs. You need a username and password to view this part of the website, if you're a developer, ask for it on the amsn-devel mailing list.

This is a valuable database providing system information, status log, protocol log and any comments the user might have added to the report. The latter could be an indication how to reproduce the bug (the user comment often says something like I did this and this then I got this bug).

Arriving at this site, you see three links: Main Window, Bugs and Wild Bug Reports. The Main Window is empty at the moment, so let's skip it. That leaves Bugs and Wild Bug Reports to be discussed later in this guide, but first some definitions.

A bug is a fault in aMSN. To quote opera's bug reporting website: "Bugs are unexpected defects, faults, flaws or imperfections in a computer program".
On this site a Bug is used to group many Bug Reports together that are related to the same bug.
Bug Report
A Bug Report is what is sent in by the users.
Wild Bug Report
A Wild Bug Report is a Bug Report that does not have a Bug describing it.

We will have a closer look to Wild Bug Reports and Bugs.

Wild Bug Reports

The Wild Bug Reports are sorted by decreasing ID by default. This means the latest bug reports submitted are listed first here. You can click a column name to sort according to this column. Hey, you can even click it again to sort in reversed order!

Another nice thing is you can set filters. You could show reports only with OS == Windows, or only with Version = 0.96rc1. This works kind of straightforward.

By opening a Wild Bug Report (simply click on it), you can see the error stack, some information about the system of this user. And hopefully, a useful user comment. Below is also the status log and the protocol log.

As was already mentioned above, a Wild Bug Report does not yet have a Bug describing it. The goal of the site is to create those Bugs that group as much Wild Bug Reports together, to create some structure in all those wild reports. The Parent Bug field you can see at the top of a Bug Report (or a Wild Bug Report) is the identification number of the Bug that it belongs to.

To avoid having to enter Bug information from scratch (see the next section), here is what should be done to create a new Bug given a Wild Bug Report:

  1. Click on the Change link at the top, next to Parent Bug
  2. Select New in the window that pops up
  3. A new Bug is created then with many information already filled in.


Perhaps the trickiest part is a Bug. Like mentioned above, a Bug groups a set of Bug Reports together. This is done by two regular expressions, the Error Text RegExp and the Stack RegExp.

Stack RegExp
This regular expression is matched against the multiple-line Stack trace in a Bug Report.
The Stack trace specifies the call sequence of procedures that was done to arrive at the point where the bug occurred.
Error Text RegExp
This regular expression is matched against the single-line Error Text in a Bug Report.
Usually, the Error Text is the first line of the Stack trace.

If you followed the advice above (creating a new Bug using an existing Wild Bug Report), the regular expressions are already filled in for you. You probably have to make some extra changes to the Stack RegExp though, to make it match more Wild Bug Reports. To learn about regular expressions, you could read this site: http://regular-expression.info/. In short, characters like ( ) { } [ ] $ have to be escaped, .* matches 0 or more characters, .+ matches 1 or more characters, .? matches a character 0 or 1 times (optional).

The Stack RegExp contains multiple lines, each line is a separate regular expression. Each line of the Stack RegExp must match the corresponding line of the Stack trace in the Bug Report. You can remove lines at the end of the Stack RegExp, but not from the beginning! Usually strip the last lines, because the same bug might be reached via a different stack trace. However, make sure you leave in the Stack RegExp what is necessary to identify this bug.

A small example: suppose there's a procedure "foo_bar" line 28 somewhere in the Stack RegExp. Because aMSN is continuously getting better, some developer might have added a line of code before this line (independently, without fixing this bug). New Bug Reports sent in by users will now have procedure "foo_bar" line 29 in their Stack traces! Hence, you would want to change 28 into the regular expression [0-9]+ so that it matches any line number (more general). Another example: If there's some user specific information like "dummy@hotmail.com" or automatic variable names like foo_class_instance001, you could replace by ".*@.*" or foo_class_.* respectively.

Then, first Save your Bug, and after that click Search. If you have changed one of the regular expressions, first click Preview to check whether you did not screw up a regular expression. Do not click Search after that, or you will lose your changes. The correct sequence after changing a regular expression is: Preview -> Save -> Search.

When the search finished and Bug Reports were found, some statistics are shown. First, the number of Bug Reports that match your Bug. It probably gives you a good feeling if this number is large. Note that the links to Bug Reports shown here are sorted by the length of the user comments. The first ones might have interesting user comments!

Other useful statistics that follow:

  • Tcl/Tk versions for this Bug: this could indicate a Tcl/Tk 8.4 bug, for example,
  • OS version: might affect only Windows,
  • aMSN version: we could classify a bug as fixed if it only occurs in old aMSN versions (after trying to reproduce with the new version).

Managing Bugs

When you create a bug in the bug report system, you can assign it to someone and / or put it as "FIXED". It is important to do so, because other developers (should) use our bug report system when they feel inspired to improve aMSN, but, at the very moment, do not have some creative issues to improve themselves.

Now, the system also does something else, if we receive a new bug report for that same bug and the svn version is later than the svn fix version then a mail is sent to the author of the bug telling him that the bug was not correctly fixed (since we received a new bug report of the same bug after the fix was applied).

The email is sent to the author of the bug. It is noticed that many of us entered their name in the author field instead of entering their email address, so the mail is sent to the name not the email, which causes it to fail. Please, anyone using the bug report system, enter your email address in the field.

Things to take into account

  • If you delete a Bug, all wild reports linked to it are also deleted, so be careful!
  • Flag Bugs to be FIXED when they are FIXED, also the old ones. It can be demotivating to try to fix something that's already fixed. Actually, it's even quite difficult to do so.
  • In the developer field, enter your email address and not your name. You will receive email if a new wild report arrives matching your Bug with a newer revision of aMSN if you do so.
  • For new Wild Bug Reports it is not automatically checked if they belong to an existing Bug already. This means Search has to be clicked for Bugs sometimes to get them up-to-date.
  • If you click Search when viewing a Bug, you might link wild reports that were linked to another Bug before. This is likely the case when the number of wild reports does not decrease (which you expected thanks to your new bug).
  • SourceForge is very slow from time to time. The Bug database is also quite big. If weird things happen, it could be because of time-out values being violated, you could best try again at some later time :(

--JeeBee 03:12, 16 September 2006 (PDT)

Personal tools