How and where to report bugs

Since there's no perfect program in the Earth - every human programmers can fail -, it's obvious that you might experience bugs in both UnrealIRCd and my modules. (A bug is a small fault in a machine or computer program which stops it from working properly). However, if you find a bug in one of my modules and inform me about it, I'll do my best to fix it. This page describes some things to do so I can get bugs fixed very quickly and efficiently. Please read it carefully! You can also use the page as a checklist to see what things you should include in your bug reports.

1. The kinds of bugs

1.1. User mistakes

This is the case when you think you've found a bug, but actually it isn't. That's why you should always read the documentations carefully, and when you install a new release of a module, also read the change log. Sometimes you have to reread specific parts of the documentation.

An other user mistake is, when you modify the code of either the ircd or one or more modules. With modified codes, no code authors can be sure in the origin of the bug, that's why altered codes are not supported.

1.2. Simple bugs

These are the easiest kind of bugs to solve, when you can immediately see what things cause them, and they are most of the time always reproducable. If you find such a bug, most likely no additional informations are required in your report. On the other hand, these kind of bugs occur very rarely.

1.3. Strange bugs

When a bug appears, you don't always know what caused it. It might be a bug either in UnrealIRCd or one or more loaded modules. If you can reproduce the bug with no modules loaded, then you may report the bug to the UnrealIRCd Team, because it's sure the bug is in the ircd. Otherwise both cases can happen, and you shouldn't contact the Unreal coders first, rather the author of the modules.

1.4. Crash bugs

These are the bugs which you experience in a sudden shutdown of your IRC server. No warnings or notices, merely the ircd stops from running. Many IRC clients which have been connected to the server before the shutdown, indicates the accident with a message like 'Connection reset by peer'. These are called crash bugs (programmers also name them as segmentation faults).

So, when your server crashes, usually a core file is dumped into the main directory of your UnrealIRCd installation. Core files are important to debug crashes and fix them. They contain useful information about the crash. Below you can read how to get the debug info.

1.4.1. Crashes on Windows systems

All you have to do is to attach the wircd.[somenumber].core file in your bug report. (See the exact filename in the popup window, or, if you run the ircd as a service, then check service.log.)

1.4.2. Crashes on Linux and UNIX systems

If you have a core file, also send me the output of gdb (it's a C/C++ debugger program) and the backtrace info (provided by gdb) which you can obtain by typing the following commands in the main directory of Unreal:
gdb src/ircd core
bt
(Obviously, the second command belongs to the gdb prompt.) It's recommended to report all the information these commands return. Some systems usually rename core files to core.<number> or ircd.core, so if yours do, then type that instead. You can exit from the gdb prompt with pressing CTRL+D or typing the 'q' command (it's an abbreviation for 'quit').

If your server gets crashed and doesn't dump a core file, probably your default ulimit configuration has a low core size limit. You can check this setting by typing the following shell command:
ulimit -c
If it says a very low number (ie. 0), try setting the maximally allowed size of core files to 'unlimited', like this:
ulimit -c unlimited
If there were no errors and 'ulimit -c' returns the new limit, restart ircd and reproduce the crash, if you can. You should get the core file.

Note: the backtrace info might not be complete if you get a message like this:
tmp/<number>.<modulename>.so: No such file or directory.
This generally happens when you restart ircd after the crash. In that case copy Unreal3.2/src/modules/<modulename>.so into directory Unreal3.2/tmp with the name <number>.<modulename>.so.

2. Things you should include in your reports

2.1. The version of UnrealIRCd

The same module may produce different results runned in different versions of UnrealIRCd, therefore it's very important to know what version you've used to compile a module which has bugs. There are a few ways to find out the correct information, that you can include in your reports. Some examples:
In the case you have downloaded UnrealIRCd from CVS (more exactly, its devel branch), I need to know more: please also tell me the release ID of your download. This can be done with one of the following steps:
There are some cases when I need the version information of all servers on your IRC network, but they are rare. Most of the time only the version of one server with a reproducable bug in a module is pretty enough.

2.2. A list of used modules and their versions

At least please tell me the version of the module you are going to make a report on. If you are unsure what modules causes the problem, then I can say, I always gladly accept a full list of module names and versions.

Since I use a revision control system (which makes me handle version info a lot easier), in my modules you can see revision numbers. Actually I also use those revision numbers as version numbers. In other words, if I ask the version of a module, I mean the revision number.

You can find out the versions of modules by:
The first method always provides good information, the second one only when you haven't updated or deleted the source file.

Oh, and please never say 'latest' as a version number. 'Latest' is a word that has no exact reference for version numbers. What people think of latest version can be different and change from time to time.

2.3. A description about the bug

This is the step when you should write a clear and very informative description about the bug. I don't mean you have to know what is causing it, it's also enough to tell me how you've experienced it, how it has appeared, and if you can reproduce it or not. They are all very helpful to me to find the bug and fix it. Every details and examples are welcomed.

3. Where to report bugs

On my bugs reporting site, angrywolf.clanintern-irc.de, a very convenient, PHP based bug tracking system is runned, which is also easy to use (both for reporters and developers), however you need a user account to log in, so you have to register one when you visit the site for the first time. (It's for free, no personal questions, only those ones which are absolutely needed.) I don't know any better environments to handle bug reports than this one. For example, a simple forum/board is designed for informal discussions, and doesn't offer the same features. So if you can't use my bug tracking system or you want to contact me first before reporting a bug, writing to the forum or sending me an email is okay.