Reporting Bugs

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 ..
p> cp -r widelands widelands-400
p> cd widelands-400
p/widelands-400> svn up -r 400
p/widelands-400> scons
p/widelands-400> ./widelands


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 ..
p/> cp -r widelands-400 widelands-600
p/> cd widelands-600
p/widelands-600> svn up -r 600
p/widelands-600> scons
p/widelands-600> ./widelands


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 ..
p/> mv widelands-400 widelands-700
p/> cd widelands-700
p/widelands-700> svn up -r 700
p/widelands-700> scons
p/widelands-700> ./widelands


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 ..
p/> cp -r widelands-600 widelands-650
p/> cd widelands-650
p/widelands-650> svn up -r 650
p/widelands-650> scons
p/widelands-650> ./widelands


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 ..
p/> mv widelands-600 widelands-675
p/> cd widelands-675
p/widelands-650> svn up -r 675
p/widelands-650> scons
p/widelands-650> ./widelands


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 buildable.
• 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 buildable 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.

The bugtracker is at sourceforge.