6. I found a bug in slrn!!!

First, please check whether the bug you discovered is already discussed here:

6.1 slrn hangs infinitely when I press the delete key

This is a known bug; however, it's not a problem in slrn, so I cannot fix it. slrn uses a library called S-Lang for its screen input/output and some Linux distributions (including RedHat) patch that library to get Unicode support. Unfortunately, the patch they use makes S-Lang unstable.

To get rid of this program, you can get the vanilla S-Lang sources from the public FTP space of its author, John E. Davis and compile them yourself.

However, simply uninstalling the S-Lang package that came with your distribution and replacing it with your own version might break dependencies in your system's package management - even if you build your own RPM package: Some packages explicitly depend on the patched version!

For this reason, you may have to install the unpatched version in a different directory than the patched one that came with your distro, e.g. in /usr/local/. To make sure slrn uses the right one, point the configure script to it using --with-slang-library=/path/to/lib and --with-slang-includes=/path/to/includes. Additionally, you either need to specify --enable-hardcode-libs or point the environment variable LD_LIBRARY_PATH to the library path when running slrn.

If you experience such a problem, please also report it as a bug to your distributor, so we will hopefully see no more broken S-Lang packages in the future. For RedHat, I got a report that it already got fixed in version 8.

Also, slang 2.0 includes Unicode support, so these kinds of problems are hopefully gone for good.

6.2 Non US-ASCII characters are displayed incorrectly.

Most such problems should disappear after upgrading to current versions of both slrn (0.9.9 or higher) and the S-Lang library (2.1 or higher).

6.3 The bug I found is not listed here. What do I do now?

The bug might already be fixed, so please consider upgrading to the latest release of slrn or at least check whether the problem is listed in the current changes file.

If you find that the bug is still unreported, send a bug report either to John E. Davis <davis@space.mit.edu> or to the slrn-user mailing list.

Please give a detailed description of what you did, how you expected slrn to behave and what slrn did instead; also include the exact error messages (in case you got any) and information that might be needed to reproduce the bug or that might make it easier to find it, such as

• Which actions make the bug appear
• The output of ``slrn --version''
• If a certain article caused the problem, the Message-ID of that article (or even the article itself, if it is not too long)
• Details of your configuration that might be relevant, like config files (after deleting personal data like passwords). The output of ``slrn --show-config'' would be especially useful here

Some additional notes for the advanced user

If you have an idea what piece of code is causing the bug and how to fix it, comments on this (or even a patch) are of course welcome, too.

If you think the problem might be on the server side, the command line switch --debug can be used to log the dialog with the server to a file. Note that the resulting file may become quite large and may contain your password! Keep this in mind when attaching it to bug reports: Delete personal data, shorten it to the significant portion (if you have some basic knowledge about NNTP) or use bzip2 and ask before sending large session transcripts.

If slrn crashes (i.e. gets terminated because of a segmentation fault), it may also be helpful if you can provide a stack backtrace. If you're willing to do this, try the following steps to get one (assuming you use a Unix-like environment and have script and gdb installed):

At the command line, type:

        script
        gdb slrn

        run [command line arguments here]
        [do whatever leads to the crash here]
        bt
        quit