Copyright © 2018-2021,2022 by Thomas E. Dickey

Bug reports


A good bug report will give me enough information that I can see the same problem that you see. Once I can see it, and repeat the conditions which show the bug, I can narrow it down to find the cause.


Identify the configuration

Not all computers are the same. I want to know which system in case I am able to run the program on a comparable machine. That includes

Since the mid-1990s, my programs use autoconf configuration scripts with a number of options. If you are using a package for one of my programs, I will find the options used by the packager. If you are compiling it yourself, I will need the same information. In this case, I would also like to see

Use attachments (a standard feature of email since the late 1990s) and avoid using HTML-mail, if you really want people to read your report.

Has the bug been fixed?

Verify if the bug has been fixed in current development. If you found a problem in a packaged version, it may have been fixed (sometimes, this may be a few years ago).

Identifying the configuration is the first step toward verifying if the bug has been fixed.

If you have found a bug in an older version, that may be important to the packagers, e.g., to alert them to the need for updating the package, or to apply a patch.

Provide a test-case

If the problem did not lie in configuring or building the program, then you must be able to run it. A script or small test-program which demonstrates the problem is valuable. Others have elaborated on the topic (though it is fair to point out that these are relatively recent episodes in a long story):

Do I already have a test?

I may already have a test-case. For example:

If an example is interesting enough, I add or adapt it to my collection.

Please: no core dumps

Some people offer to send the core file generated when a program dies unexpectedly. I have received unsolicited core dumps as part of a problem report (sometimes not even as an attachment, but pasted into the message).

I delete the core dumps, finding them not useful. Instead, a traceback using a debugger is often helpful:

# myprogram
Segmentation fault (core dumped)
# gdb myprogram core
(gdb) tb
#0  0x00007f868d718337 in kill () at ../sysdeps/unix/syscall-template.S:81
#1  0x000055f0d8442a1f in mch_exit ()
#2  <signal handler called>
#3  0x00007f868d7c4893 in select () at ../sysdeps/unix/syscall-template.S:81
#4  0x000055f0d8443f63 in ?? ()
#5  0x000055f0d8444433 in ?? ()
#6  0x000055f0d84446bb in mch_inchar ()
#7  0x000055f0d84c39f8 in ui_inchar ()
#8  0x000055f0d83d329f in inchar ()
#9  0x000055f0d83d534e in ?? ()
#10 0x000055f0d83d5b13 in vgetc ()
#11 0x000055f0d83d5f89 in safe_vgetc ()
#12 0x000055f0d842461f in normal_cmd ()
#13 0x000055f0d850896d in main_loop ()
#14 0x000055f0d834a2e1 in main ()
(gdb) quit

A traceback using a debugger is often useful, but not always:

If you have compiled my program, then the bug report's traceback should show line-numbers for a debug-executable. Prepackaged programs are a different matter altogether (there will be no line-numbers). Given the distributor, package version, I may investigate by compiling that configuration.

Patching sources

Suggested improvements should be sent as a source patch:


Dead systems

Until 2010, most of my development (aside from $dayjob) was on PCs using a multiboot configuration. At one point I had more than 80 systems set up in this way. Since 2010, I have used mostly virtual systems with different tools, and increased the number of systems somewhat. I also have had development access to a number of Unix systems for quite a while, but none of that is under my control.

If the system you are using is not something that I can set up in a virtual machine, there is little (aside from advice) that I can offer for support.

Given those considerations, these operating systems are defunct:

Apollo, CLIX, IRIX, IRIX64, OSF/1, Tru64,
OS/2 EMX environment, BeOS, QNX,
Windows before 7 (2003, 2000, NT, 98, 95, 3.1),

These versions of Unix operating systems also are defunct:

AIX 4 and before,
HPUX 10 and before,
Solaris 9 and before,
SunOS 4 and before.

Inaccessible systems

Some viable systems may have users, but if I have no access, I cannot support programs. My experience with no-access guarantees that I'll only accept trivial build-fixes. There is no point in having features in a program that I cannot test.

BeOS survives, more or less as Haiku. I can build and test programs with that system.

OS/2 lingers on as eCOMStation. Around 2010 I set up a development system with Parallels, which died due to an upgrade. But it works with VirtualBox and possibly VMware.

Until 2008, I was able to use VMS in the HP test-drive. That went away. Some people have reported success with simh. Perhaps sometime I will too.

Other systems

I occasionally see bug reports for Gentoo, but my involvement with those is limited to advice and comparison with other systems. Gentoo (like Linux From Scratch) assumes that the user compiles everything. No one has time for that, unless it is the only system they use.

Most of the reports which I get through a bug tracking system are via Debian; the Redhat system is a distant second. Systems derived from Debian (in particular, Ubuntu) which contribute very little to my projects fall at the other end of the spectrum. If you want to report a bug in one of the Debian-derived systems, you are best advised to open a bug report in the Debian bug reporting system.

Further reading

While the MCVE/SSCCE pages are interesting, Usenet FAQs used to give similar information during the 1980s/1990s. These pages for instance were written by others based on that environment: