, X-NEWS: spcvxb alt.folklore.computers: 13584I Relay-Version: VMS News - V6.0 13.10.90 VAX/VMS V5.4; site spcvxb.spc.edu : Path: spcvxb.spc.edu!rutgers!ucsd!ucbvax!THEP.LU.SE!magnus" Newsgroups: alt.folklore.computers. Subject: The original _Hacking Horror Stories_+ Message-ID: <9109101415.AA03453@thep.lu.se> ' From: magnus@THEP.LU.SE (Magnus Olsson)  Date: 10 Sep 91 14:15:01 GMT" Sender: daemon@ucbvax.BERKELEY.EDU
 Lines: 948  G A few weeks ago, I mentioned Brad Allen's collection of "Hacking Horror F Stories" from 1982. I got quite a few email messages asking me to postF it. I've had some trouble finding the file, but here it is, by popular demand (below my .sig).   - Magnus Olsson                   | \e+      /_ - Dept. of Theoretical Physics    |  \  Z   / q 5 University of Lund, Sweden      |   >----<            2 Internet: magnus@thep.lu.se     |  /      \===== g- Bitnet: THEPMO@SELDC52          | /e-      \q     L ================================ CUT HERE ==================================    ( 		  ****** HACKING HORROR STORIES ******  H These are the responses to my ARPANET post of 27 October 82. If reading I any of the stories below inspires you to send your own, please do! I will F continue to update this file as long as macabre tales of men and their machines continue to come in.    					- Brad   ! ----Message 11 (1564 chrs) is---- 8 Mail-From: local user X400BC70 at 27-Oct-82 19:26:55-EDT Date: 27 October 1982 1917-EDT From: Bob Colwell at CMU-10A# Subject: Re: Hacking horror stories  To: Brad.Allen@CMU-10A   Brad: > 	When I was finishing my Master's here at CMU, we were using aI PDP-11/45 that was showing incipient senility.  One week before the final H demo, the RT-11 monitor stopped powering up properly and instead took to8 halting the machine at some incredibly non-obvious spot.? 	This was not acceptable performance, so we scratched our heads D faster and faster for about two days trying to fix it.  Finally, in I desperation, we single-stepped the RT-11 boot sequence, and found that it H was doing a memory check that it believed was failing.  It then tried toF jump to a "memory check failed" diagnostic that it expected to find inF memory, which of course was not there.  What was there, however, was aG random collection of bits that just happened to look like a jump to the F original totally bogus location that we could see on the lights of theG front panel.  (Incidentally, we could read and write the supposedly bad I memory location using the front panel).  The solution?  We powered up the H machine with the halt switch asserted.  Then we loaded in a "Return fromD Interrupt" instruction where the random bit collection was.  Presto.I By the way, until this problem occurred, we were competing for use of the F 11/45 with two other groups of students.  Since they all gave up when K this difficulty hit, we had sole use of the machine until it got officially  fixed. 	Bob  ----Message 12 (993 chrs) is----N Mail-From: ARPANET host USC-ISIB received by CMU-10A at 27-Oct-82 20:08:14-EDT Date: 27 Oct 1982 1708-PDT) From: Dave Dyer       <DDYER at USC-ISIB>  Subject: horrors To: allen at CMU-10A    D  On a tops-10 system I was responsible for, I made a typo installingE a bug fix to the monitor's file system code.  The result was that for I several days (until the file system began seriously degrading) a randomly B selected physical block of the disk was written with a copy of the8 retrieval information for the system's accounting files.  ?  Another, we had installed a new memory box, which unknon to us A was responding with the wrong word once in 10^8 or so operations. A We ran with this flake for about a month before the bit decay was @ tracked down to the culprit.  At that point, EVERYTHING that hadE been done during the bad time was "possibly" damaged, and quite a few E were in fact damaged.  It took about a year before the last artifacts " of that episode were filtered out.   -------   ----Message 13 (857 chrs) is----L Mail-From: ARPANET host MIT-ML received by CMU-10A at 27-Oct-82 20:37:13-EDT Date: 27 October 1982 20:40-EDT % From: Peter Szolovits <PSZ at MIT-ML>   Subject:  Hacking horror stories To: Brad.Allen at CMU-10A  cc: PSZ at MIT-ML   D My first paying programming job was to convert some FORTRAN programs@ from the 7094 to an IBM 360 in 1966 at UCLA.  Some of these wereE unbelievably hairy (doing memory management within Fortran, character G manipulation before there were characters in Fortran, etc.) and obscure ? (some of the code was in fact Fortran II code that first needed G conversion to Fortran IV).  The real horror was that my predecessor had D been taken away by the men in the white coats, and lived in a mentalG hospital; so there really was no way to get any additional info on much > of this code, and I had a graphic example of where my job led.! ----Message 14 (2082 chrs) is---- P Mail-From: CMUFTP host CMU-CS-VLSI received by CMU-10A at 27-Oct-82 20:44:03-EDT Date: 27 Oct 1982 20:30-EDT - From: James.Gosling at CMU-CS-VLSI at CMU-10A # Subject: Re: Hacking horror stories  To: Brad.Allen at CMU-10A + Message-Id: <82/10/27 2030.262@CMU-CS-VLSI>   G Several years ago I was doing some development work on a compiler for a @ language like Pascal.  And like most Pascal implementations, theA compiler was written in the same language and was used to compile B itself.  It was broken into many modules.  To make a change to theG compiler I would just recompile the affected module and link it back in F with the rest of the modules.  At some point, I took one of these testE versions of the compiler and replaced the production compiler with it F -- it seemed to be just fine.  In fact, it was fine for quite a while.A So long that this new version got onto the backups and all of the A backups of the production compiler were lost.  There was also the G problem that the old production compiler couldn't have compiled the new E compiler anyway, since the language had changed quite a lot.  Well... F In one of the modules that had never been through the new compiler wasF a piece of code that tickled a bug in the code generator.  The bug wasF a cooperative one between one of the new pieces of code and one of the> old one.  What I ended up with was a compiler which I couldn'tA recompile because fixing the bug involved compiling a module that E tickled the bug.  Because of the circularity in the compiler (that it G compiled itself) I was up the proverbial creek without a paddle.  There G was no way that I could recompile or shuffle anything to fix the beast. G All backups were either of the broken compiler or had been overwritten. F The solution was incredibly messy: I spent a long time doing intensiveC octal surgery on the object modules that I had.  This was made very E difficult because there was essentially no information left around to F correlate program text to compiled code and because the bug caused bad$ code to be generated in many places.  
 				James.! ----Message 15 (1169 chrs) is---- L Mail-From: ARPANET host MIT-XX received by CMU-10A at 27-Oct-82 22:29:30-EDT Date: 27 Oct 1982 2231-EDT% From: Larry Seiler <SEILER at MIT-XX>  Subject: Bug fix horror story  To: Allen at CMU-10A cc: Seiler at MIT-XX  C Maybe this is not quite what you have in mind, but in case it is...   D My most painful bug was a simple uninitialized variable (I had movedF the initialization statement to a position after the first reference).D This variable was a pointer, and its position in the call stack justF happened to contain an address in code space.  So running the program C caused certain instructions in a different procedure to be changed  C into noops, with bizarre results.  Loading the debugger caused the  H program to work correctly, by tranferring the target of the modificationI into an unused part of the debugger (I think).  Even after I discarded my E innocent assumption that the code I wrote was the code that was being E executed, I still had to guess what routine was writing to code space G (and by what mechanism).  Total time required to fix the bug:  8 hours.   = How embarrassing.  Why am I telling you this?  Well, why not?b   Larry Seiler -------1! ----Message 17 (1759 chrs) is----0M Mail-From: ARPANET host Utah-20 received by CMU-10A at 28-Oct-82 02:11:44-EDT! Date: 28 Oct 1982 0012-MDT/ From: JW-Peterson at UTAH-20 (John W. Peterson)i# Subject: Re: Hacking horror storiesg To: Brad.Allen at CMU-10Ah cc: JW-Peterson at UTAH-20/ In-Reply-To: Your message of 27-Oct-82 1516-MDT1  G In trying to learn the graphics/animation biz, I've run into a few.  InmF making some films this summer I wound up working strictly at night, toE help prevent any light from entering the room.  The filming had to be E completed entirly over the weekend, so it would interfere with normal.B bussiness activity (like turning the lights on...).  Worse yet theG old Bolex I was using had no way for the computer to trip it's shutter, I so I had to manually press the cable release every time the computer rangn1 the terminal bell; for several hours at a strech.=  H Some other animation stories: Before color graphics CRT's & framebuffersH were invented, the poor filmmaker had to sleep next to the camera.  WhenE the bell rang, he would wake up, change the color filter wheel to theiJ next primary color, backwind the film all the way, and go back to sleep...  F Perhaps best of all is Jim Blinn's "Korean Janitor" movie.  During theC creation of the DNA sequences for "Cosmos", they decided to let thelB camera run over night, with the computer tripping it every severalF seconds.  So the locked up the room and put a big "Filming in process:G Do Not Enter" sign on the door.  Unfortunatly, the Korean janitor could F not read the english sign but DID have a pass key.  The resulting filmD shows a DNA molecule twisting in space, a flood of light, and then aE jerkey sequence of the janitor cleaning the room at 200mph, seen as ad reflection in the screen.i jp -------e! ----Message 19 (1595 chrs) is---- L Mail-From: ARPANET host MIT-XX received by CMU-10A at 28-Oct-82 10:50:59-EDT Date: 28 Oct 1982 1054-EDT) From: Geoffrey H. Cooper <GEOF at MIT-XX>h# Subject: Re: Hacking horror stories  To: Brad.Allen at CMU-10At cc: geof at MIT-XX/ In-Reply-To: Your message of 27-Oct-82 1716-EDTp  F This is our favorite "what happens when people are taught higher levelC models before the lower level ones" story.  I get this second hand,lH so some of the details might be a little off.  It may not be of the sortB you had in mind, but it's amusing enough to bear repeating anyway.  C Around here, we teach a course in software engineering in which thelI students are taught and write programs in CLU (a language which lets user J defined abstractions work the same way that the language defined ones do).H One common final project for the course involved writing an assembler inH CLU.  The problem statement required that numbers be input and output in octal, rather than decimal.i  K Most of the students, I am told, defined an OCTAL abstraction, with all thebJ normal integer arthmetic operations, and with Parse and Unparse operations3 that converted strings into OCTAL's and back again.1  K This was implemented by representing an OCTAL as an array of integers, each I of which represented an octal digit.  The arithmetic operations simulatedtB octal arithmetic on this representation.  None of the students wasG apparently aware that the normal integer data abstraction that they hadeK been using was really just stored as bits, which were more easily convertedc to octal than decimal.   -Geof Cooper -------s! ----Message 20 (1069 chrs) is----hM Mail-From: ARPANET host CMU-20C received by CMU-10A at 28-Oct-82 10:57:26-EDTn* Date: Thursday, 28 October 1982  10:57-EDT  From: Jon Webb <Webb at Cmu-20c> To:   Brad.Allen at CMU-10A  Cc:   webb at CMU-20Cp Subject: Hacking horror storiesh  D Well, here it is: I was working as an undergraduate programmer at my< undergraduate university, and I basically had the run of theF time-sharing user interface (it was TSO, on an IBM 360/65).  I decidedG it would be nice if you could edit lines you'd typed, like the facilityUD in the C-shell on unix except more primitive.  Well, it was a prettyC trivial change to allow this, but unfortunately to be effective the H change had to be installed in the system, I couldn't test it in advance.A So I installed it one night, and TSO wouldn't work anymore.  VeryBA embarassing, especially as the backup method I thought would worknF didn't.  In fact one of the systems programmers had to be called in toE fix the system, in the middle of the night.  I gave up on editting in 1 TSO.  This is an argument for personal computers.i   Jono  ----Message 21 (910 chrs) is----M Mail-From: ARPANET host UCB-C70 received by CMU-10A at 28-Oct-82 11:57:13-EDTd Date: 28 Oct 1982 08:55:57-PDT From: CSVAX.bitar@Berkeley To: Brad.Allen@CMU-10A Subject: Hacking horror storyr  G I was working late one night developing a file under the Unix operatinglG system.  I was in a hurry at one point, and wanting to rename the file,E I executed the unix move cmd. . A moment later Unix complained of indigestion,@ and I noticed that instead of typing 'mv oldname newname', whichC is Unix's way of renaming a file, I had typed 'rm oldname newname'. E So Unix had executed 'rm oldname', then run into newname and vomited.c I nearly did the same.  F Fortunately I did have a backup copy of the file, which I subsequently# re-editted, bringing it up to date.k  F After that incident, though, I was very careful about slight cognitiveH mistakes, such as thinking 'move' (mv) and typing 'rm' (remove) instead.! ----Message 22 (1801 chrs) is----h8 Mail-From: local user C410RF60 at 28-Oct-82 12:06:03-EDT Date: 28 October 1982 1155-EDT" From: Robert Frederking at CMU-10A# Subject: Re: Hacking horror storiesh To: Brad.Allen@CMU-10A  D 	Yourdon's book on software engineering has a few of these.  Most ofI my really horrible experiences happened due to politics or manufacturer'sd screw-ups.  I 	(Example of first): CWRU was building a network, and had to pick between K DEC and Harris computers (Harris one because one of their VPs was a trusteewM at CWRU - they were clearly inferior machines).  Besides teaching their staffoM how to program, we had to constantly show them that feature X was broken, andhK how to fix it.  The project finally collapsed due to their crufty machines.tO The operating system was *not* virtual memory (altho user space was), and whileaG adding networking software to their OS, they ran out of room.  "Sorry".cB 	(Example of second): in trying to microprogram Intel's hack-of-a-P bit-slice-machine, you had to fit your instructions into a 2-dimensional addressL space!  Some instructions could only branch in rows, others only in columns,I yet others only to specific clusters of locations.  It was clearly a hackiJ to cover running out of instruction bits.  They even had to sell a programI designed to find a fit for your microcode to the available space (I thinka- the problem is NP-complete - 2d bin packing). B 	The best example is the interupt disable instruction on the 6800.K If the least significant bit of the *preceding* instruction is 1, the whole H processor hangs when you try to disable the interupt.  Also, some of theJ illegal opcodes (which aren't masked out) will cause the processor to hangG so badly, it can't be reset.  You have to turn it off, and wait for the ! dynamic RAM register to fade out!h   	Bob! ----Message 24 (1536 chrs) is---- R Mail-From: CMUFTP host CMU-CS-Speech received by CMU-10A at 28-Oct-82 14:51:46-EDT Date: 28 Oct 1982 14:47:27-EDT/ From: David.Cunnius at CMU-CS-SPEECH at CMU-10A  To: Allen@CMU-10Ad Subject: Hacking horrors  F 	The old 15-311, Software Engineering Methods, will probably be one ofL the more fertile sources of horror stories. The semester I took this course,I Spring '80, one of the tasks was a database implementation for a science-.L fiction wargame. Looking back now, I think our project group was doomed fromN the start. Of the original five-man team, one dropped the course before anyoneM else even met him, one had to take some time off to deal with a family crisis8O around mid-term, and one simply disappeared for a period of three weeks, comingrK back without even a memory of where he'd been. Despite all that, we did getsM something together for the final demo. We were using a modular design and had2J divided the task into thirteen subtasks. At the demo, four of the thirteenK modules worked properly, two that had tested out perfectly the previous dayRL didn't work at all at the demo, and most of the other seven hadn't even beenK coded yet. Of the four modules that worked, the most impressive one was theoG display package; unfortunately, that was also the only module which wasgG optional in the original specification. Two of the members of the groupoN somehow managed to pull 'D's as our final grade; to this day I haven't had the2 nerve to ask the other two what their grades were.% 					Dave Cunnius (dac@CMU-CS-Speech)r! ----Message 25 (2873 chrs) is----cP Mail-From: ARPANET host Washington received by CMU-10A at 28-Oct-82 16:18:31-EDT Date: 28 Oct 1982 1318-PDT' From: Bob Bandes <JUGGLE at WASHINGTON>R# Subject: Re: Hacking horror storiese To: Brad.Allen at CMU-10Ap/ In-Reply-To: Your message of 27-Oct-82 1416-PDTl    @ As a senior project when I was going to school at UC Santa Cruz,= I put together a real-time voice controlled operating system.p@ The entire thing was written in assembly language on a PDP-11/32? running RT11.  Since this was a single user system with a fixedh@ disk, it was necessary to make a tape backup at the end of every session.  A Well, after one particularly furious day of hacking, I decided tooB write my backup tape and go home for the day.  My normal procedure< was to mount my backup tape and use ROLLIN to copy an entire> disk-image to the tape.  Unbeknownst to me, the procedure that; I used had the effect of first initializing the tape beforeh making the backup.  @ This had always worked just fine.  But on this particular day, IC had been working on my disk I/O routines and apparently had somehowA= managed to write garbage on some unknown portion of the disk.eA I had no idea that anything was wrong as I went to make my backupr@ tape.  As usual, first the tape was initialized, then, as ROLLIN= began to write the disk image, the program hung!  There I wash> with no backup tape and having major problems making a backup.  A My next move was to panic.  After settling down somewhat, I triedd; rebooting the operating system and making the backup again. < Still the same problem.  Then I remembered about the DECtape@ drive on the machine.  If I could only find a DECtape and manage? to individually tranfer the files that I needed I would be home  free.e  F I ran over to the cabinets and began frantically looking for DECtapes.@ AHA!  I found one!  As I ran back over to the computer, I took a> bounding step and landed on the side of my ankle.  I proceeded@ to lie on the floor writhing and screaming in agony for the nextD fifteen minutes.  "This just isn't my day,"  I was saying to myself.B When the pain began to subside I tried to get up.  I couldn't walkD on the ankle since it hurt so much.  So I hopped over to the DECtapeA drive and mounted the DECtape.  Then I hopped over to console and,	 sat down.w  A At least something went right that day, as the machine allowed metC (without hanging) to individually transfer all my files to DECtape. A I then read a clean version of the operating system onto the disk ? and proceeded to tranfer all of my files from DECtape back ontoeB the disk.  This time all went normally with the magtape backup and, the world was safe again for future hacking.  B Fortunately my ankle wasn't broken.  It was only severly sprained.< For the next few weeks I was forced to do my hacking with an$ ace-bandage wrapped around my ankle.   --Bob Bandes --------  ----Message 29 (721 chrs) is----M Mail-From: ARPANET host UCB-C70 received by CMU-10A at 28-Oct-82 23:30:51-EDTn Date: 28 Oct 1982 20:26:51-PDT From: Kim.norvig@Berkeley  To: brad.allen@cmu-10a# Subject: Re: Hacking horror storiesI  P Lucky for me, most of the stories I remember are happy ones, not horror stories.M My favorite story about someone else is when Jim Meehan was writing TALESPIN,hC his AI program that generated stories, mostly about birds and bearsdG running around the forest.  One story started off fine, then started toa* slow down, and finally ended with the line/ 	Joe Bear thinks that FREE STORAGE IS EXHAUSTEDu# Oh well, @b(I) thought it was cute.t  E Can I be put on the mailing list to see your collection of anecdotes?   
 program to! ----Message 33 (1413 chrs) is---- L Mail-From: ARPANET host MIT-MC received by CMU-10A at 30-Oct-82 16:38:45-EDT Date: 30 Oct 1982 1635-EDT# From: RG.JMTURN at MIT-OZ at MIT-MCe# Subject: Re: Hacking horror stories- To: Brad.Allen at CMU-10A5/ In-Reply-To: Your message of 27-Oct-82 1832-EDTl  I The experience that still makes my skin crawl is the time I was debuggingvK some Lisp Machine board at the MIT AI lab. I had spent several hours tryingiM to isolate a noisy signal which seemed to be tied to another one, but I couldlO not find a common wire and I had replaced all the common chips. In desperation,dJ I pulled out the the board and yanked the extender, about to give up hope.H As I stared down at the extender, I muttered some curse to the designersI of the machine...and noticed a solder splash on the extender shorting twoyI lines! For ghu's sake, if you can't trust your tools, what can you trust.   H On the other hand, for an example of the other extreme, this week, I wasE in Montreal doing an installation for Lisp Machine, Inc. A crufty Bus-E Interface seemed to be making the machine go 1/2 speed, and sometimesOK fail entirely. The person I was working with and I decided to call it a daytN around 5, and go to our hotel. When we came back the next morning, the machineH worked perfectly. The best we can figure it, the machine wanted us to beC able to have a night in Montreal, and the afternoon the next day...e    
 					JAmes -------r! ----Message 38 (1003 chrs) is----nL Mail-From: ARPANET host UCB-C70 received by CMU-10A at 1-Nov-82 23:02:54-EST Date: 30 Oct 1982 03:44:28-PDT From: CSVAX.fishkin@Berkeley To: Allen@CMU-10At Subject: painful hacks  
 	Hi there,H My name is Ken Fishkin, and I'm a grad at Berkeley. My most painful hackD occured while hacking a 6K line C database program at the UniversityH of Wisconsin-Madison as an undergrad.  My program worked perfectly, withD all debug prints on.  When I set my 'const' debug to false, however,D the program would crash!  To make things even more fun, if I deletedE 1 debug print the program would still run correctly, but if I deletedmH another instead it wouldn't!  I wound up doing a sort of tree traversal,F individually deleting some 200! debug prints individually, finding theC proper sequence of delete-compile-delete that would keep my programTA intact. To this day, I still have no idea what was wrong with ther program.8 	If possible, could you mail me your final collection of horrible hacks?    			Ken! ----Message 40 (1981 chrs) is----nL Mail-From: ARPANET host CMU-20C received by CMU-10A at 2-Nov-82 11:29:15-EST Date:  2 Nov 1982 1128-EST From: MASON at CMU-20C Subject: horror stories  To: brad.allen at CMU-10A   @ Many roboticists have reported the following demo problem:  whenA filming or demonstrating, we often raise venetian blinds, turn on > the lights, or bring in floods.  The increase in ambient light= may cause optical-interrupt type sensors on the robot to stopiA functioning, and the heat from floods may affect other components7A of the system.  Thus a system which has functioned flawlessly forMA months begins to malfunction the very minute the generals arrive.e  @ Real-time programming has its special frustrations, but the most@ difficult bugs arise from difficulties in the timing of process F interactions.  Most of these are too complicated to make good stories.@ One of the most confusing PDP11 bugs I had may be worth telling.A When a byte is pushed onto the stack, the stack pointer is first f> incremented to keep the pointer at word boundaries.  Hence theB odd byte is garbage, left over from no-longer-active stack frames.F I had a program which pushed a byte, but popped a word, thus accessingA this garbage.  Even careful inspection of the code didn't turn upf@ this violation of stack discipline.  The worst part is that the C manifestation of the bug would vary depending on which process last = used the stack.  In particular, the bug became invisible whenpL single-stepping with our symbolic debugger---the debugger (im)providentially> cleared the relevant byte in the act of saving some registers.  A This reminds me of another PDP11 bug.  Our 11/40 had a micro-codeaK error.  The SOB instruction (subract one and branch, used for simple loops)fI didn't test the TRAP bit, which is used by debuggers for single-stepping.;I Hence, when single-stepping, the programmer was not shown the instructionsM following the SOB.  It was executed "in secret", with very confusing results.-   -------o  ----Message 32 (621 chrs) is----K Mail-From: ARPANET host MIT-XX received by CMU-10A at 3-Nov-82 15:20:23-EST  Date: 2 Nov 1982 17:19:35-EST  From: jfw at mit-vax at mit-xx To: allen@cmu-10an# Subject: Programming horror storiesg  M Two summers ago, while I was working on an improvement to our UNIX at LL-ASG,CK I fired up a test version a little too fast, and watched with puzzlement as L the filesystem check program started printing out random things.  I wound upO killing a 100Mb filesystem full of useful things.  After 2 weeks of poring overaK the code I wrote which did that, I found the bug:  " = " instead of " |= ".y One character did all that...d  ! ----Message 37 (1934 chrs) is----o7 Mail-From: local user C410MS40 at 4-Nov-82 00:37:41-ESTk* Date:  4 November 1982 0036-EST (Thursday) From: Mark.Sherman at CMU-10An To: Brad.Allen at CMU-10At# Subject: Re: Hacking Horror Storiesi) Message-Id: <04Nov82 003626 MS40@CMU-10A>.  D As an undergrad I worked as a systems staff on a time sharing systemD that resembled Multics (called DSL/TSS - think of it as Unix on HP21G series machines).  On such systems, the login program is like any othere= program; when a user sits down he "calls" this program from aAC predefined file system path to gain access to the system.  For somei? unrememberable reason, I had to make some modifications to thispE program, did so, and installed the new version.  The only real way to H try this program out was to log out and then log back in.  Having loggedE out, I tried to log back in.  To my chagrin, I had accidently set theeA protection on the new login program to read instead of its normalnD read-execute.  Thus the system refused to run the login program.  ByG S.O.P., this would not be a problem - when doing such a drastic change,cB we always made sure that at least one other systems programmer wasB logged in so that he could patch anything that was necessary, likeC changing access control on the login program.  Before my attempt togB change the login program, there were two other systems programmersB logged in.  After my mistake, I walked over to the two other staffG people only to find that they had both logged out - after all each knew C that the other was logged in and so saw no reason to stay on as the F "protection".  Thus there was no way to log into the system and no wayE to patch it while it ran.  We had to move the system to a spare disk,mB boot a backup system, bring up the extra disk with the file systemF containing the bogus protection as a "raw" disk and use a special diskG utility to set the one necessary bit giving execute access to the logina program.   Mark! ----Message 38 (3657 chrs) is----.L Mail-From: ARPANET host CMU-20C received by CMU-10A at 4-Nov-82 01:40:45-EST* Date: Thursday, 4 November 1982  01:39-EST% From: Skef Wholey <Wholey at CMU-20C>m To:   Brad.Allen at CMU-10A- Subject: Horrorful horrors  O CMU's 15-311 is indeed a source of horrors, and I experienced a rather horrible5M in that class last year.  There were five of us in our group, which we calledlL "SPAM", each of us competent hackers.  Our project was a 68000 simulator andN debugger, which would run 68000 machine code and let you look at registers andK memory and so forth.  Our work progressed on schedule (with the aid of manyeM all-nighters), and we were able to run simple assembly language programs just  about a week before the demo.a  K Being a rather noisy bunch, wanting our demo to be as slick as possible, weEO decided that we'd run a backgammon program written in C compiled with cc68.  WehO had used small programs compiled with cc68 to test the simulator.  The programs3N were small enough to compile and assemble on a Vax, print the hex object code,M and type it into file which we would load into our simulator.  The backgammonTK program was too large for this, obviously, so the object code was FTP'ed topM another machine, put on tape, and brought to the Computation Center, where weyK pulled it off of tape and loaded it into our simulator.  The program didn'tA. work.  It didn't work the day before the demo.  M We found a few bugs in our simulator, but worst yet we found bugs in the cc68dN compiler, now N machines away.  Fixing these we found bugs in the game playingM program itself.  Compiling the program on the Vax and transporting the objecteM code was out of the question at this point -- too little time left before the.L demo (we had all announced that we'd appear in coat and tie).  So we ever soH carfully patched the hex files, and voila!  The program ran beautifully.  J That year Comp Center gave each undergrad who needed a computer account anN account on each undergrad machine (TOPS-D and TOPS-E).  These machines were onN Comp Center's DECnet: not a reliable network at that time.  We had the currentO version of our system and the patched hex files on TOPS-D, because the load waseO lower there that night, but were scheduled to demo on TOPS-E terminals.  DECneteH was, of course, down for quite a while, but finally came up.  We quicklyM transferred the current system to the E and ran back to our rooms or homes tor shower and dress.o  M We marched triumphantly into the terminal room and sat at our terminals whiletO our SPAMmascots fed cookies to the waiting crowd and our professor.  The systemiN came up fine, and we demonstrated how to deposit into and read from memory andM registers before moving onto the demo programs.  We loaded the hex files, setnH breakpoints at our test locations, and lo!  IT DIDN'T WORK.  We were allN somewhat bummed and embarrassed, and managed to muddle through at the mercy ofI this mysterious adversary that had destroyed a system that worked an houruO before.  The professor suggested that we get our act a little more together and @ have a somewhat less flashy demo in his office a few days hence.  M The problem: we had neglected to copy the patched hex files from the D to thefM E.  We were demoing buggy 68000 code.  The second demo went a bit better.  WelK now laugh about the first.  Comp Center no longer gives out accounts to onel- student on more than one machine.  Good idea.    --Skef  H [What be your motive for knowin' this stuff, eh?  Doo ye like to feed onN  stories o' suffrin'?  Are ye writin' a book?  I enjoyed reading those sent to;  you so far and enjoyed sending you this one.  Good topic.]   ! ----Message 39 (1236 chrs) is----eO Mail-From: CMUFTP host CMU-CS-VLSI received by CMU-10A at 4-Nov-82 09:40:16-EST  Date: 4 Nov 1982 8:36-ESTs( From: Ed.Frank at CMU-CS-VLSI at CMU-10A Subject: Hacking horror storiese To: Brad.Allen@cmua + Message-Id: <82/11/04 0836.841@CMU-CS-VLSI>   A While working on the software for a Graphics terminal we built ateG Stanford, I ran into the following problem. The software was written invA assembly language, and was burnt into EPROMS. For a long time thepM software easily fit in four 2708 (1K x 8) EPROMS. Well, one week after adding G the graphics support code to the terminal, I simply could not get it toaG work. I spent literally dozens of hours going over at most 500 assembly C language statements, to no avail. Things were so bad in fact that IfF seriously began to question my abilities as a programmer.  One eveningE while I was checking the output of the assembler (for at this point IaF was convinced  it was an assembler bug) I noticed that that one of theE target addresses of a jump was greater than FFF (hex). I didn't thinkoE anything of it, until a few seconds latter when it occured to me that 7 addresses > 4K required 5 proms. I quickly went back tos? work, burned the extra eprom, and the program worked perfectly!g 	Ede    ----Message 40 (731 chrs) is----7 Mail-From: local user C410RK40 at 4-Nov-82 09:58:20-EST * Date:  4 November 1982 0955-EST (Thursday)( From: Richard.Korf at CMU-10A (C410RK40) To: Brad.Allen at CMU-10A. Subject: hacking horror storyo) Message-Id: <04Nov82 095535 RK40@CMU-10A>n   Brad,hP  My favorite bug of all time concerned an ASR35 Teletype. I was trying to formatO some output and found that directly after printing a long line, the second linesP was indented by one space. Naturally, the bug went away when I ran the debugger.M It finally turned out that the printing head was physically bouncing off the 2M left hand stop. If it didn't have to print again immediately, it would have a 3 chance to settle back to the beginning of the line.e                -rich! ----Message 41 (1799 chrs) is----e7 Mail-From: local user C410SS40 at 4-Nov-82 11:42:32-ESTi* Date:  4 November 1982 1134-EST (Thursday)) From: Steven.Shafer at CMU-10A (C410SS40)i To: brad.allen at CMU-10A  Subject: Horrors! ) Message-Id: <04Nov82 113429 SS40@CMU-10A>t   Brad --o@    I had a nasty experience with an old PDP-11/40E running UNIX.L    I had written a program which juggled several processes, one of which wasK the largest core-image of any program in existance on the machine (<64K, of * course).  One day, it died a sudden death.K    I started tracking it down with print statements.  At first, the problemiK looked like something being set to 0; then, as I added more debugging code,gJ the 0's jumped around.  I never knew which routines they would crop up in,K or whether global data structures were affected, or even if code itself washD being overwritten.  Sometimes, the program would die even though the, debugging code showed nothing extraordinary.K    I eventually gave up and rewrote the program from scratch, using smallerbK processes and succeeding.  Several months later, a paging bug was fixed: itsI was responsible for writing 0's on pages when the core-image of a process  was beyond a certain length.M    What makes this a horror story is a UNIX vagary tickled by the bug: withineJ the code being executed, there was a statement to close a file.  The file,L like all UNIX files, was indexed by a small integer.  When the zeroes struckL this variable, the effect was to close file 0, i.e. disconnect the keyboard!J So, not only did the program die, but it refused to talk to me long beforeH the actual moment of death, leaving me to watch helplessly as it writhedI in agony, unable to talk to it, unable to interrupt it, and never knowing 9 where the Flying Fickle Finger of Fate would strike next!s    -- Steved  ----Message 43 (390 chrs) is----7 Mail-From: local user C410BL50 at 4-Nov-82 12:30:02-EST * Date:  4 November 1982 1214-EST (Thursday)' From: Bruce.Lucas at CMU-10A (C410BL50)o To: brad.allen at CMU-10Ao Subject: horrors) Message-Id: <04Nov82 121457 BL50@CMU-10A>r  G On Unix, I once meant to type "rm *.BAK" but instead typed "rm * .BAK".nJ Fortunately, I hadn't made too many changes since the last backup to tape.   Bruced  ! ----Message 46 (1054 chrs) is----o7 Mail-From: local user C410EL80 at 4-Nov-82 14:26:58-ESTo Date: 4 November 1982 1411-EST  From: Ellen Lowenfeld at CMU-10A# Subject: Re: Hacking Horror Stories  To: Brad Allen  B This one's kind of embarrassing, looking back on it...  When I wasF a sophomore at Brown, I took a course which had a big project, I guessK like 311 here, except that the groups were pairs.  So that I and my partnernE could test pre-compiled code separately (IBM 370, batch mode) we each J had a dummy main routine.  Mine printed its name, and then called whateverI routine(s) I wanted to test.  Unfortunately, I left out the quotes aroundoI its name, and sent it into infinite recursion.  IBM's great error messagesD once I found it after looking in 3 manuals, and poring over pages ofD IEFH01X (or something like that), was "user error".  Not until I hadD spent most of a day looking for a wizard did I go back and just lookE at the code I had written.  Was my face red when all the people I hadnG talked to while trying to find out the problem asked what it turned out8 to be!! ----Message 47 (1310 chrs) is----eN Mail-From: CMUFTP host CMU-RI-FAS received by CMU-10A at 4-Nov-82 14:38:21-EST Date: 4 Nov 1982 13:09:55-ESTd* From: Neil.Swartz at CMU-RI-FAS at CMU-10A
 To: ba0c@cmua  Subject: Horror stories,  I Several stories come to mind.  At Princeton, they had WATFIV on a 360/91. I You got 2 seconds of computer time and 600 lines of output.  One job camenG out in WATFIV that printed a line of characters and then overstruck theoH characters again and again.  The computer counted this as one line so itJ would do this forever.  The print heads tore through the paper, the ribbonL and started in on the carriage.  The system was down for more than 12 hours.  L Another good one which I have heard about- (If anybody knows more about thisJ I would like to hear about it)  The Phantom Teletype Program.   The way itI worked was this: At a random time interval the program would start up andhL pick a teletype on the system.  It would print "The Phantom Teletype StrikesI Again!!" and then it would copy itself somewhere else on disk, set up theOA parameters for its re-execution, and delete the old copy.  SystemeB programmers could find out where it had been, but not where it wasF currently.  Because it was too difficult to track, they left it on the system.   3 There are lots of good(bad) stories running around.e 	Neilo  ! ----Message 49 (2598 chrs) is---- N Mail-From: ARPANET host UTexas-20 received by CMU-10A at 4-Nov-82 16:41:21-EST Date:  4 Nov 1982 1538-CST From: CMP.LSMITH at UTEXAS-20h Subject: some horror stories To: brad.allen at CMU-10Am  8 My first hacking horror story goes back to my very first@ programming course. My program kept exceeding its time limit andA aborting. I checked my code carefully and decided it was correct,m> but only needed a little more time to finish. So I confidentlyA upped my limit from 7 seconds to a CPU minute of CDC 6600 time. Ia? was really horrified when it timed out again, blowing my entirehA semester's allotment. A sharp consultant found my bug. I made thesA FORTRAN equivalent of "FOR X = 1.0 BY 0.1 TO 10.0," with my finalg> test an equal. Since 0.1 is a repeating fraction in binary, it5 never equaled 10, so it went past and on to infinity.:  @ Years later I was working on a PDP11/45 Unix system.  The system> began crashing some time after we retrieved something from theA backup tapes, using Unix's raw mode access to the tape. In cookedi? mode, things worked right, so we knew it couldn't be a hardware > problem.  After some months of trying to debug the problem, we> modified the tape device handler so that it spun and monitored@ its registers until the transfer completed. One of the high bits> in the address register was sticking off. In cooked mode, Unix> read into its system buffers in low core and everything worked= because that bit stayed off anyway. In raw mode, it read intor7 user space directly.  Whenever the address register wash? incremented past that bit boundary, the DMA transfer would drop8< down and wipe out some random locations and the system would slowly collapse.  = The worst horror stories are when you spend days hacking at awA program, only to discover that you've invoked a compiler bug.  We A are extremely fortunate to have the ELISP system. I had a probleme@ with a lengthy computation sometimes returning NIL from compiled< code. Between the (RETURN RESULT) in the called function and> (SETQ X (CALLED ...)) in the caller, the value was being lost.A Interpreted, it worked. If I traced the function, it worked. If IaA traced any function in a chain below it, it worked.  It turns outa> that if you have a chain of calls about 10 deep, then a MAPCAR= over a list of at least 3 values, then about three more callsf@ down, and all the functions are compiled, then the time bomb NIL9 is stuck up on the stack. If any function in the chain is > interpreted, for example by tracing it, then the behavior goes9 away. As far as I know, this bug still hasn't been found.g -------d! ----Message 50 (1130 chrs) is----0N Mail-From: CMUFTP host CMU-CS-IUS received by CMU-10A at 4-Nov-82 21:16:47-EST Date: 4 Nov 1982 20:08-EST0 From: Victor.Milenkovic at CMU-CS-IUS at CMU-10A# Subject: Re: Hacking Horror Storiesj To: Brad.Allen at CMU-10A * Message-Id: <82/11/04 2008.913@CMU-CS-IUS>  A One version of the PL/I debugger at Yorktown had no provision for F displaying the hex values of pointer variables.  However, it would, onG request, display the hex address of any other type of variable, as well = as its value.  And so, in my program, I would create records,hD containing a single float variable, based at the pointer I wanted toB see, and recompile.  By requesting the address of these records, I) could determine the value of the pointer.   G In PL/I one can allocate an area of memory and declare offset variables:G into it.  One can freely assign offset variables into pointer variables3E and back again -- or so I thought.  If a pointer to offset assignmentaE results in a negative offset, nothing complains (although it should),CC but if one assigns the offset back to the pointer, it gets garbage.4- This peculiarity caused a very tenacious bug.i  ----Message 51 (304 chrs) is----7 Mail-From: local user C410BL03 at 4-Nov-82 21:52:38-ESTi* Date:  4 November 1982 2151-EST (Thursday) From: Bruce.Leverett at CMU-10A  To: Brad.Allen at CMU-10Aw# Subject: Re: hacking horror storiesh* In-Reply-To: <04Nov82 210911 BA0C@CMU-10A>) Message-Id: <04Nov82 215100 BL03@CMU-10A>g   Don't remember.o! ----Message 52 (2968 chrs) is----h7 Mail-From: local user C425EC0F at 4-Nov-82 22:12:20-ESTe Date:  4 November 1982 2210-ESTl From: eddie caplan at CMU-10Ae To: brad allen at CMU-10Ae Subject: hacking horror storiess  @ i was doing research in the computer music lab.  i was trying toA generate emotional responses in subjects by producing sympatheticSC vibrations from the 64 loudspeakers surrounding the listening room. C normally, we would add sub- and ultrasonic frequencies to classicalc0 "standards", and then play them to the subjects.  ? now, usually we just use frequency modulation to synthesize thee< instruments of the classic orchestras.  but one day as i was> making an undergraduate volunteer retch to beethoven's seventhB symphony, a thought struck me.  if i changed to additive synthesisB for the instruments, i could elicit REALLY BIG responses!  i mean,@ i had been having pretty good results up 'til then, and i wasn'tA complaining.  but, with FM there was lots of data lost.  additivebE synthesis would make the music itself generate an emotional response.oF full fidelity beethoven combined with me could convert hasidic jews to catholicism!  ? so, i spent the next week redoing the beethoven.  i finished at9A 2:30am, and the only other person around was my officemate, dana.oB i asked her if she had heard beethoven's seventh recently.  i told@ her that i had a recording of boston symphony conducted by klausD tennstedt.  i still remember her eyes lighting up at the prospect. iE hated to lie to  her, but she couldn't be told the  truth or the datarE would be tainted.  i had to  expose her to it without her suspecting.a? i put dana into the listening room and turned on the music withu) my sub- and ultrasonic frequencies added.d  A i watched through the soundproof glass from the observation room.nA during the first movement, dana cried uncontrollably.  she curledcB up in the chair and wimpered.  dana laughed insanely, and had what appeared to be several orgasms.p      "i've done it!", i cried.  B but then, the second movement began.  i shudder still when i thinkC of it.  i looked in at dana.  she was sitting upright in the chair,t@ staring straight ahead, her hands gripping her knees.  there was> blood starting to drip from her fingernails.  she was becomingD catatonic and starting to shake.  i had to halt the processor before@ permanent damage was done.  but before i was able to stand, danaD let out an excrutiating scream.  she shook violently and fell to the> floor.  then, dana began to float into the air.  i pulled openD the door and rushed into the listening room.  dana was screaming far= above my head.  beethoven was screaming from the 64 speakers.   ; then, i called her name.  it was too much.  dana dissolved.a  ? i think that the added sound of me yelling to her exceeded the UA threshold.  i know now that i am to blame for her dissolving, andoC that i'm responsible for bringing her back.  perhaps it can be donee' with bartok.  dana always liked bartok.u   eddiee! ----Message 53 (2694 chrs) is----tP Mail-From: CMUFTP host CMU-CS-Spice received by CMU-10A at 4-Nov-82 22:58:54-EST Date: 4 Nov 1982 22:08-EST/ From: Rob.MacLachlan at CMU-CS-SPICE at CMU-10Ae Subject: Hacking Horrors To: Brad.Allen@cmuar, Message-Id: <82/11/04 2208.881@CMU-CS-SPICE>  L I ran into my most obsure bug last summer when I was working on a boot imageI builder for Accent to run under Accent.  What I had to do was convert theeK original program, which had POS filesystem calls that read and wrote randommK things scattered throughout it to use the Accent primitives, which are readnH and write an entire file.  After factoring this code out into a separateG module I found that the program died the same way about one time out oflJ five.  Since the debugger was virtually non-existant I proceeded to put inH debugging code.  First I put in a check where it was dying for the fatalH condition, which would print various information.  I found that when theI error occured the cause was that the Pascal Get intrinsic was returning asF random value instead of the correct one, but no particular pattern wasG observable.  I then put in code to dump the contents of the pascal filerD object after every value read from the file to see if it was gettingJ clobbered; with this code in place the program died with an illegal memoryH reference inside the system print routine inside of one of the debuggingF WriteLn's.  At this point it was obvious that something earlier in theE program was damaging the environment somehow, so I tried successivelyiK commenting out earlier parts of the program to find the offending code, andrH I found that if I did not read an earlier file, than the problem did notC occur.  This caused me to suspect my file handling module, so I puttL debugging code in it to check that all of the pointers it was returning wereK valid.  When this debugging code was inserted the program then died earlieraJ in the program, but this time consistantly during the reading of the thirdK microcode file.  Insertion of debugging code at this point revealed that to,I a point the buffer contained the correct data, but the rest was zero.  AtnH this point I felt reasonably sure that I had found a bug in Accent, so IL called in the wizards, who looked at the address of the buffer and said: 'OhJ that crosses a 64k boundry'.  Evidently it was a "Known" bug that a pascalK object could not cross a 64k boundry, because the address calculations wrapaL around, and the ReadFile routine I was calling read the file into a place inJ memory such that it crossed a 64k boundry.  The Execution of the debuggingL code I put in caused storage to be allocated, thus causing the heap to cross% a 64k boundry earlier in the program.i! ----Message 54 (1784 chrs) is----a7 Mail-From: local user C410TL19 at 5-Nov-82 01:22:19-ESTp( Date:  5 November 1982 0122-EST (Friday) From: Tom.Lane at CMU-10Aa To: Brad.Allen at CMU-10Ay# Subject: Re: Hacking Horror Storiesf) Message-Id: <05Nov82 012212 TL19@CMU-10A>U  @   Well, after reading your accumulated file I felt like I should contribute one of my own. G   I have spent too many years of my life hacking systems which tried todE enlarge a processor's address space by using software-controlled bankoE switching (C.mmp/Hydra & Cm* locally, Hewlett-Packard 9845 out in the E real world; personal computing CP/M systems seem to be going down thenE same garden path). These machines extend a processor with (say) a 64KyD address space to handle megabytes, by dividing the processor addressH space into two to 16 blocks. Each block is mapped to a block of physical@ memory by means of an associated processor register. Accessing aG particular memory location requires loading up one of the map registers D with the block number of the location, then accessing the processor-A visible address "register number * block size + location's offset  within block".C   This scheme is a LOSER. The majority of bugs found in each systemk@ I have worked with have been directly related to bank switching;? it's just too easy to forget to load or restore a map register.sC This leads to reading or clobbering semi-random locations in blocksyC other than the one wanted. Worse, the bugs are often very difficulteD to duplicate, since they only show up when two data structures beingB manipulated at once happen to reside in different physical blocks.B HP's testing records showed that 75% of the bugs discovered duringF system testing were of this ilk; many of them required an unreasonable amount of effort to track down.n 				tom laneA ======================== END OF FILE ============================f