Since we are on the issue of bug reports (see last post), here is how we made the decision to put “[Done]” in the title of fixed bugreports:

[12:32] <fr34k> this is the point were a bugtracker would be more helpful. there we could filter all solved bugs easily :)
[12:35] <AlphaSND> we already talked about that
[12:35] <AlphaSND> btw, we could change the title of the topic with [Fixed] in it, no ?
[12:35] <fr34k> true
[12:36] <AlphaSND> ok, let's do that starting from now
[12:36] <fr34k> thats a good idea actually, as often people keep posting after the "fixed", so it is no longer obvious from the last post
[12:37] <fr34k> what do we do with stuff that we determine not to fix? (not a bug, not solvable)
[12:37] <fr34k> should be marked as well
[12:37] <AlphaSND> yes
[12:37] <AlphaSND> we could put [Issue] -
[12:37] <fr34k> issue ?
[12:37] <AlphaSND> and move that in Coding Question
[12:38] <AlphaSND> Issue :p
[12:38] <AlphaSND> or [Feature] -
[12:38] <fr34k> lets just put [done] ... its shorter than [fixed] anyway :D
[12:38] <AlphaSND> [Done]
[12:38] <AlphaSND> ok
[12:39] <fr34k> [done] :p
[12:39] <AlphaSND> [Done] Damit !
[12:39] <AlphaSND> :p
[12:39] <fr34k> why ?
[12:40] <AlphaSND> because
[12:40] <fr34k> lets do it differently, so we see who fixed it :D
[12:40] <AlphaSND> man, let's be consistent :p
[12:40] <fr34k> berikco has to write [donE] :D
[12:40] <AlphaSND> :D
[12:40] <fr34k> i noticed, you also always write "Fixed" in the posts, i write "fixed."
[12:41] <fr34k> its not the beginning of a sentence, so there is no reason to write it capital. and its one more key to press damit :p
[12:42] <AlphaSND> It's a full sentence !
[12:42] <AlphaSND> Fixed.
[12:42] <AlphaSND> Uppercase, verb and dot
[12:42] <AlphaSND> :p
[12:43] <fr34k> lol, where have you been when grammar has been tought at school? :D
[12:43] <fr34k> coding probably
[12:43] <AlphaSND> :)
[12:44] <fr34k> now what? :)
[12:44] <AlphaSND> now what what ?
[12:44] <fr34k> i just fixed a bug, what do i write ?
[12:44] <fr34k> the rebell in me wants to write [done] :D
[12:45] <AlphaSND> [Done] -
[12:45] <AlphaSND> i'm the older here :p
[12:45] <fr34k> lol
[12:46] <fr34k> why the " - " btw ? 3 more keys!
[12:46] <AlphaSND> mannnnn !
[12:46] <AlphaSND> to differentiate of the original topic :)
[12:47] <fr34k> hey, i am just trying to optimze here
[12:47] <fr34k> "[Done] - 4.10 and 4.20 Beta 2 - Odd bug"
[12:47] <fr34k> "[done] 4.10 and 4.20 Beta 2 - Odd bug"
[12:47] <fr34k> so much better
[12:47] <AlphaSND> if you fix the bug faster than typing 2 two keys, ok
[12:47] <AlphaSND> the first one is indeed much more sexy ;)
[12:48] <fr34k> compromize: either the D or the "-" has to go ;)
[12:49] <AlphaSND> man, you're damn cra
[12:49] <AlphaSND> zy
[12:49] <fr34k> oh well, i have to go, food time. we'll continue this! :)
[12:49] <AlphaSND> let's remove the - then
[12:49] <fr34k> ha, success :D
[12:49] <AlphaSND> and eidt the 3 i did
[12:49] <fr34k> ok
[13:00] <AlphaSND> http://www.purebasic.fr/english/viewtopic.php?t=30825
[13:00] <AlphaSND> could you look at it, i can't find what's wrong with it
[13:21] <fr34k> re
[13:28] <fr34k> the mdi one is "[donE]" :D
[13:29] <AlphaSND> mouarf :)

In the end, i am glad we dropped the ” – “, because i am already having a hard enough time putting the “[Done]” in some of the bugreport titles. People use too descriptive titles in the bug forum it seems. Anyway, we are usually very much on the same page when it comes to the direction that PureBasic should take so big discussions are quite rare. But if we disagree, it gets tough! 😀

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.

What a wierd title. Or may be not. Depending of your experience, you may or may not know these life-saver tools, when strange things happen to your program and you have absolutely no clue about what the hell is going on. No starting point to look at. It sometimes happens, sometimes not, as if the computer was an organic lifeform. Here enters purify like programs (‘valgrind’ on linux, ‘purify’ or ‘bound checker’ on Windows) , which adds realtime checks around almost every kind dynamically allocated memory block to detect the root of evils: buffer overflows.

You may think: “well that’s cool but i use PureBasic, and barely never dynamically allocated memory block, as all is managed by natives libraries”. You are right. But may be you use pointers, or even OS calls. And this is where things got a bit more complicated, as pointers is the ultimate power in programming. And as all power, it has to be used wisely. Are don’t get me wrong: you will use them wisely. Until something is changed in your code which impacts that and suddenly the pointer gets crazy, without any notification. On a big program, it could be very long to isolate the bug. I have some ‘souvenirs’ of very vicious cases which took me several days to fix. And as PureBasic executables uses a custom debugger format, it is not compatiable with any of the purifier tools. Too bad. Until now.

Before going further in the details, let’s try to really understand how a purifier works. Basically, it puts ‘cookies’ around every potientally dangerous code items: variables, arrays, strings, dynamically allocated memory block. What’s a cookie ? It’s just a predefined value (usually 32 bits), often something funny like $BADBEEF or $BADF00D. At every executed line, the purifier (which holds a list of all the installed cookies address) will check them, and if one is broken will stop. That means than something has erased this area which should never have been erased. Ever. That’s a bit like a code integrity check. As we could imagine, the bigger your program is, the slower the purifier will be. And it can be very very slow, that’s why it’s possible to tune it to check only some kind of data, and at which rate.

Consider this code:

Procedure a()

a.l = 10

*CrazyPointer.Long = @a
*CrazyPointer+1
*CrazyPointer\l = 152  ; stack corruption

EndProcedure
a()

This is an obvious error. But it does go unnoticed when running in standard release/debug mode. On some more retricrive OS, it could even crash. If you activate the purifier it catch it immediately and report a stack corruption. Let’s try another less obvious one:

*LocalDrive = AllocateMemory(#MAX_PATH)
GetModuleFileName_(0, *LocalDrive, #MAX_PATH)

This snippet uses Windows API, and get back the executable name. So far so good. Now what happen if you change the program mode from ASCII to Unicode ? You end up with a buffer which is twice smaller as requested, and chances are high than you will be hit with a nasty buffer overflow. Again the purifier will detect it as the ‘cookie’ put at the end of the allocated memory block will be overwritten.

And there is quite some cases where it can happen: a structure too small to recieve the expected data, wrong associated structure to a pointer, pointer manipulation error, wrong API call, etc. For most of them, the purifier will catch the error. There are some limitations tough: threaded program could report wrong line and  if a pointer is really filled with a random value, it won’t be noticed by it (but probably by the debugger as IMA – Invalid Memory Access).

The purifier is now available in PureBasic 4.50 !