Latest Posts

Changes in ReportingBugs

Editor Comment

A bit more about reporting bugs, especially from the website.


Revision Differences of Revision 1

# Reporting Bugs ¶

## For Widelands ¶

The link in the bottom of this section is for bugs in the game itself. Do **not** use it for the website. ¶

### How can it be reproduced? ¶

Describe step by step how to reproduce the bug. If it only happens when loading a certain file, attach that file to the report. ¶

### Is it a regression? ¶

A regression is a bug that did not exist in some previous version. When reporting a regresssion you should tell which version was the last where the bug is not reproducible and which revision is the first where it is reproducible. To find out, use SVN and interval halving. Here is an example: ¶

Suppose you have a SVN checkout (called widelands) at revision 800 and find a bug: ¶


p/widelands> cd.. ¶


Now you try if the bug is there. Suppose you find out that revision 400 is free from the bug. Then you do: ¶


p/widelands-400> cd.. ¶


Now you try if the bug is there. Suppose you find out that revision 600 is free from the bug. Then you do: ¶


p/widelands-600> cd.. ¶


Now you try if the bug is there. Suppose you find out that revision 700 has the bug. Then you do: ¶


p/widelands-700> cd.. ¶
edge. ¶

Now you try if the bug is there. Suppose you find out that revision 650 is free from the bug. Then you do: ¶


p/widelands-650> cd.. ¶


Now you try if the bug is there. Suppose you find out that revision 675 has the bug. Then you know that the bug appeared somewhere between revision 650 and 675. You continue to narrow the interval as much as possible. You could for example find out that the bug did not happen with revision 664 but with revision 665. This is what you should report. The developers can then do something like_svn diff -r 664:665|kompare -_and_svn log -r 665_to start searching for the cause of the bug. ¶

Sometimes you will get a revision that you can not test because it can not be built or it crashes before you can get to the point where your bug happens. Then try another revision. This can of course also be the case for revisions close to where the bug appeared. Then you may have to report something like this: ¶

* Revision 1134 was the last where the bug was not reproducible. ¶
* Revision 1135 to 1137 were not build-able. ¶
* Revision 1138 ended immediately with "Segmentation fault". ¶
* Revision 1139 is the first revision where the bug happens. ¶
Sometimes when trying an old revision with a recent compiler, it will not be build-able because the compilers that were used when that revision was written were less strict. It could still be the case that you can test that revision by fixing the piece of code that does not compile. Keep in mind that really old revisions do not have the_scons_buildsystem. You may have to build them with_make_instead. ¶

If a bug is reproducible and is a regression, it will almost certainly be fixed relatively soon. ¶

### Where to report ¶

The bug-tracker is at [Sourceforge](https://sourceforge.net/tracker/?group_id=40163&atid=427221). ¶


## For the Website ¶

Use the link after, for reporting bugs from the website, and **only* from the website. Remember - to fix a bug, we need to know how can it be reproduced, where (in what part of the website) it happens and if it's a problem with style (look) of the page, what browser do you use. ¶

### Where to report ¶

The bug-tracker for the website is at [Launchpad](https://bugs.launchpad.net/widelands-website).