A Bug’s Life

Ok, its a cheesy title but it fits. I was asked to write about the process with which we handle bugs. The following is roughly how i handle this. I can’t speak for Fred but i don’t think the approaches are too different. This post is also intended as a guide on how to write effective bug reports about PureBasic, as the report can make a big difference here.

Each bug starts its life when it is posted in the bug reports section. If you want your bug report to be seen, write it in the (english) forums.  People sometimes try to tell me about bugs when they meet me on IRC, but this is a very bad idea. If i am unable to address the issue immediately the report will be buried in the log files and most likely forgotten. I am usually busy while i am on IRC so the chance to get something fixed immediately is very slim. Post it on the forum and it won’t be forgotten. Then we can discuss further details on IRC if you happen to catch me. The english forums is where i manage the bug reports. Anything reported somewhere else (IRC, email, german forums) starts at a huge disadvantage.

The first stage after a bug is posted could be called the “initial viability test”. I read every bug report that is posted the next time i visit the forums. I am not on the forum to specifically fix bugs at this point though so this is just a quick check. The relatively obvious non-bugs get filtered here. For example when the behavior is intentional or somebody confused a feature request with a bug. There are also a number of things that people often think are wrong where it is really just a lack of understanding (every few months somebody thinks GetCurrentDirectory() is wrong for example).

At this point i also run any provided example code if possible (if i have a copy of PureBasic in reach). This is why providing an example code to show the bug is very important even if it is just 5 lines of code and you think it should be plainly obvious. Its not that i am lazy. Remember that in this first stage i am not concentrating on fixing bugs. I am just browsing the forum in the lunch break for example. I am not going to write any test code at this stage, however if i just have to fire up the IDE and run it then i usually do that. When a bug can be reproduced at this stage, it starts its life with a big head start compared to the other reports because once i actually get around to fixing bugs i tend to start with these as i already have a place to start looking.

I usually do not comment the bug report at this point (unless it falls in one of the non-bug categories above) so if you post a report and do not hear anything for a while don’t be alarmed. I did read it and it will not be forgotten. Sometimes it takes very long for a bug to get actually fixed, sometimes it is done really fast. This varies a lot as do the reason for why some bugs take longer to fix. Sometimes we just don’t have a solution. Sometimes the solution would require a larger redesign of a library and is therefore postponed to when other planned changes to that library will be implemented. Sometimes the required work just outweighs the usefulness of the bugfix. In the later category i tend to give priority to bugs that cannot be easily worked around by the user. If a bug can be easily worked around with a few lines of code (but may be would be much more work to fix internally) then it may take longer than others. There is really no general rule here.

This brings me to the issue of “bumping” bug reports. Our usual response is “don’t bump” and sometimes it sounds a bit angry which some people might not understand so i will explain it a bit. To me bumping comes across as a bit rude and i am often very annoyed by it (hence the response). Its like saying “stop working on other stuff and fix my specific problem”. I can understand that a certain bugreport may be important to you and the lack of feedback from our side can be frustrating at times. But try to see the whole thing from my point of view: I am confronted with a large list of bugreports (from multiple OS) and i am trying to get them fixed as best as i can. My time is limited and i can only work on one thing at a time. It may be that i just spent a lot of time trying to fix one or more other bugs and then a comment like “still not fixed” or simply “bump” on a bugreport is just frustrating. I am well aware of the status of that bug because as i said above, i read everything that is posted in the bugs section. Bottom line: if a bug really is important to you and you think it should get more attention then ask nicely, don’t just bump. Explaining your reasons why it is important to you also helps, because if something is really a showstopper for you i may try to make an extra effort to get it fixed. In any case it gets you much further than just making me angry with a “bump” post, thats for sure.

Ok, back to the life of a PB bug. I do most of my bugfixing in larger batches at once (recently fixed 30 bugs for the OSX version in one weekend). You will notice this by a lot of [Done] appearing in the bugreport section. Sometimes Fred and I even have a kind of race about it to see who can dominate the bugs form (i own the OSX one right now obviously). For this i make a list of what i want to get fixed from the forum, sort it by priority and get to work on it. The method for fixing a bug is always the same, even for the very obvious ones: I first have to see the effects of the bug in action. Even if it is pretty clear from the bug description where the problem is in the actual code, i still have to make sure i can see whatever the problem is myself. This is the only way to really know that i fixed the bug afterwards.

This reproduction-phase is the most important (and often most difficult) one. Once again, if you provided a working code example that i could verify when i first read your report this problem is already solved, which is why i tend to fix such bugs first. If not then here is where the testing begins. You can make this alot easier for me by providing as much information as possible, such as the exact OS you are using. GUI related bugs are very often specific to some OS, or even to a specific set of settings. So include this information in your post.

My development PC runs Vista 64bit, but I also run VMWare and have a lot of different Windows versions set up for testing. The same thing goes for Linux: Linux distributions are so many and released so frequently that I usually cannot keep up with the latest release of the popular distributions. I am not somebody to install updates all the time. I do my development on OpenSUSE 11 right now. However, if you include your exact distribution and version, then i will download that and setup a VM for it in no time for testing (thanks to fast internet and VMWare this is really no big deal). With all this VM testing there is one common thing: If i have to test on a specific OS version, i most likely test in a clean install with just enough stuff installed to run PB. So if you have made any large changes (especially on Linux) from the base install which you might think could have an influence on the problem then please include that information.

The most important thing however in the whole reproduction-phase is to know what i am trying to reproduce. It may be plainly obvious to you what the bug you post about is, but it may not be to me, so always tell us what you think the problem is (don’t just post code). I have to know what i am looking for after all. It may also be that the bug does not appear with my testing configuration at all, so the code alone is no help here. Always include these two things in your report: What do you see when you run the code, and what do you think should happen instead. The clearer the report is the easier it is to work on it.

If i cannot reproduce it, i will post asking for more information or feedback from others. Here it helps if others respond with their results and also their system configuration. This usually helps a lot in figuring out bugs that are OS or configuration specific. I have seen posters who did not want any feedback from other users, probably because they feared that the existence of a workaround for their problem may diminish their chances of getting their problem fixed. It is the opposite actually: It would not be the first time that a posted workaround helped a lot in fixing a bug or implementing a new feature. Although it must be said that the existence of a workaround does not necessarily mean that it is a good idea to do it that way in the PB library. In any case, feedback on bugreports or feature requests is always welcome as long as it adds extra information. A simple “+1” is usually not helpful (except when the question was “can anybody else reproduce this”). A bug generally does not get fixed based on how much people provide feedback, but especially when we have trouble reproducing the problem then more information from others certainly helps.

If everything fails and i simply cannot get the bug to appear on any of my systems then things get tricky. I can do things like build special debug versions of libraries or the IDE so the user can help me track it down, but it involves a lot of back and forth. I try to avoid this if possible, but  from time to time there is just no other way.

When the bug is successfully reproduced, it is time to hunt down the cause and fix it. There is really not much to say about this part. It really depends on the kind of problem at hand. It is usually a back and forth between modifying the PB code that shows the problem and the code of the library in question until the problem is found.

When the problem is finally fixed, i do the same steps/run the same code i used to see the bug in the first place once again to make sure it is gone. Depending on the kind of bug, i may add a routine to our unit tests (which are run by Fred’s build script before every release) to make sure it does not come back. I don’t do that too often though, as most of the times it does not really make sense. For example, a bug in any of the many GUI libraries cannot be automatically tested because they need user interaction. Also, many bugs are quite unique and not very likely to appear again, so unittests are a bit of a waste of time here. Its different for the compiler. Here it is much easier to have work in a different area cause bugs that were once fixed to reappear, so Fred maintains a set of unittests for many compiler features. Anyway, this is the end of the PB bug. Now its the obligatory “fixed.” post (or “Fixed” as Fred would write :)) and that is it. One more bug in the “[Done]”-category.

Leave a Reply