Reporting bugs in software/programming
Posted on 2003-11-29 by ivo :: /programming :: link
For free software to work, it is essential that people report any bugs they may find to the authors. When the feedback is accurate and correct enough, they can then fix their software.
However, when you've finally tracked down a bug in a software package, it's sometimes a lot of very frustrating work to find out what exactly is causing the software to break. This is essential information to the programmers, without this they usually wouldn't know where to start looking for the cause of this problem (there are exceptions of course).
As a Debian developer, I know that having incomplete information in a report for a bug that doesn't manifest itself on my system can be extremely frustrating and annoying. Asking the user for more information can help, maybe he needs to be guided a little, for example by providing a way to get a gdb backtrace.
Here's the tale of my latest adventure in this area, as a user. About two weeks ago, a CGI script written in Perl was failing mysteriously on a production server. I had checked everything, even changed the locale the script was running in. The code was pretty simple:
if ($value =~ /^$allowed$/m) {
$allowed is .*, and $value
contained some UTF-8 text, with an ä in it.
Nothing out of the ordinary, but it wouldn't work. The match
statement would always be false. After hours of debugging, it
turned out that when $allowed was compared to
.*, it wasn't equal. We could set it to
.*, in which case the expression was true. (Using
$allowed = join('', split('', $allowed)) didn't help
either, but maybe perl optimized that a bit.)
So, we looked at the perl bugs. The system I was developing this on was running Debian stable (woody), which has perl 5.6. So you have to look at bugs in perl 5.6. Or Debian bugs for the stable release. The bug under examination may or may not have been fixed already, either in new releases, CVS code, Debian patches, mailing list posts, or somewhere else entirely.
On the other hand, the bug might not even be in perl. The value
of $allowed is passed on via a complicated structure
of hashrefs and arrays from a parsed XML file, using XML::Simple.
So maybe that module is at fault. XML::Simple gets its data from
expat, so it might even be expat.
All these little bits of information make it pretty hard to find out if a bug has been fixed or not. I have been trying to see if the bug exists in more recent versions of perl, but so far I haven't been able to reproduce the situation well enough. For one thing, I would have to setup a system that is exactly the same as the production platform, which may take up quite a bit of time. And of course, time is money.
So, what do you do, report the bug or not, knowing that the information you have is incomplete, probably inconsistent and maybe even incorrect; knowing that the developers may ignore or flame you for your report?
I didn't. Hacking around the problem by replacing
ä with ä was much
easier.
