levin@CS.UCLA.EDU (01/10/87)
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.
You don't need to write anything long; a page should do it. All
contributors are thanked in advance, and will be credited in the book
for their contributions.
Soon in a bookstore near you...
(apologies if you see this message on ten different newsgroups)
Stuart LeVineskajihar@udenva.UUCP ("Lord of Sith" Kajihara) (01/12/87)
In article <3669@curly.ucla-cs.UCLA.EDU> you write: >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. > Sorry about posting this, but we do not support ARPA here. I don't know that this qualifies for what you ask, but the following comes from an inexperience with C and file processing. I had a program that would read from n text files and write to an output file. The first time that I ran the program, I exceeded the amount of disc quota I had on the system. The problem: in using command-line arguments to identify my files, I had inadverdently included my output file as input. Result: an endless loop. In the following code, argc is the number of arguments to the program, argv is an array of character pointers. argv[argc-1] is the output file. . . . for (inc = 1; inc <= argc-1; ++inc) process(argv[inc],argv[argc-1]); . . . The solution is to make the condition of the for loop '<' rather than '<='. I am only an undergraduate physics major so forgive me for my modest and possibly trivial solution. Scott Kajihara -- ________________________________________________________________________________ Me? A CS major? Now, I know that either you are joking or LAKking. -- Scott Kajihara UUCP: ...!udenva!skajihar Disclaimer: the above quote is not meant to insult computer science types; it is just that I could never become CS and remain my usual insane self (they have always said that we are strange but have charm). ________________________________________________________________________________
greg@utcsri.UUCP (Gregory Smith) (01/15/87)
In article <2722@udenva.UUCP> skajihar@udenva.UUCP ("Lord of Sith" Kajihara) writes: >I had a program that would read from n text files and write to an output file. >The first time that I ran the program, I exceeded the amount of disc quota I >had on the system. > >The problem: in using command-line arguments to identify my files, I had >inadverdently included my output file as input. Result: an endless loop. > Try 'cat * >foo' in a directory not containing foo. [4.2 BSD newcsh]
adam@gec-mi-at.co.uk (Adam Quantrill) (01/16/87)
In article <2722@udenva.UUCP> skajihar@udenva.UUCP ("Lord of Sith" Kajihara) writes: > >I don't know that this qualifies for what you ask, but the following comes ~ ~~~~~ ~~~~ ~~~~~~~~~ ~~~ ~~~~ ~~~ ~~~ >from an inexperience with C and file processing. > I had a program that would read from n text files and write to an output file. >The first time that I ran the program, I exceeded the amount of disc quota I >had on the system. > The problem: in using command-line arguments to identify my files, I had >inadverdently included my output file as input. Result: an endless loop. > [] YAWN I thought the original poster wanted HUMOROUS bugs. [ Article eater food ]
ddd@thumper.UUCP (01/19/87)
> YAWN > > I thought the original poster wanted HUMOROUS bugs. Please don't waste our time for the sole purpose of being nasty. Let the original poster decide what he does and doesn't want.
cmcmanis@sun.uucp (Chuck McManis) (01/21/87)
Of course there was a time when you could right a Fortran program for
TOPS-10 like so :
FOO(0.0,10)
SUBROUTINE FOO(A,B)
A = B * 3
RETURN
END
And when executed the compiler generated constant for zero was a pointer
to some known word with zero in it was changed. This affected all subsequent
references to the constant 0.0 by your program or anyone elses on the
system!
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.laman@ncr-sd.UUCP (Mike Laman) (01/23/87)
In article <3669@curly.ucla-cs.UCLA.EDU> levin@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