Collecting favorite bug stories

Mike Laman laman at ncr-sd.UUCP
Fri Jan 23 07:43:07 AEST 1987


In article <3669 at curly.ucla-cs.UCLA.EDU> levin at CS.UCLA.EDU (Stuart Levine) writes:
>I am collecting anecdotes of experiences, (real or imagined) 
>for a book to be titled:
>
>    MY FAVORITE BUGS: Humourous, and Horrible Experiences in Software
>                      Engineering.
>
>As one might tell from the title, the book will be filled with wonderful
>tales that programmers tell each other, over a few too many beers,
>after a long day at the keyboard.
>
>The book is meant to be read for entertainment, as well as for education. 
>In that light, I am asking that contributions include (when possible),
>a short description of the bug, some comments on why it was special,
>how the solution was found, and maybe (for the appendix of the book)
>a few lines of code.

Since you asked...

Back in my starting UNIX days, I was using a PDP 11/70 system running V6 UNIX
that had this fun game called rogue (3.6).  When I ran the game (on my
own time, of course), I noticed that once in a while the program would
start off my character with a higher level of strength (18 instead of 16).
I thought this was VERY desirable, so when I wanted a new game, I would
start up a new game and quit it until I found a game that had a strength
of 18 (I needed all the help I could get in those days).
After a while it dawned on me that I could write a program to do this.
I convinced myself that it would teach me how to use pipes, forks
and many basic UNIX system calls with which I should be familiar.  So I wrote
this nice "getgame" program that would fork off an inferior process of rogue,
look at its output in one pipe and send a reply down the other pipe to rogue
saying whether to save the game or exit.  Unfortunately, I didn't have
a "wait()" call to wait for the child process to exit.  Instead my program
would start up another rogue game without waiting for the last game to exit.
My "getgame" program would make rogue programs faster than they would
disappear.  So my program would cause rogue games to take up all of main
memory and all of the disk swap space.  Eventually, the kernel would then panic.

I didn't know why the system crashed.  After all, how could my little program
CRASH a system?  So after our System Guru (my boss) studied the crash,
he was "a bit annoyed".  It seems he had added code to the kernel to avoid
just such a crash, but hadn't really been able to test it.  He asked me to
KEEP the program around until he could fix the kernel.

Funny...  If he hadn't put in the code, he would have grumped at me REAL GOOD,
Instead the bug in his kernel fix put him on the defensive and
surprised me when he wanted me to run it again.

Strange...  I have never forgotten to wait on child processes since then.

Mike Laman



More information about the Comp.lang.c mailing list