🚀 go-pugleaf

In article <DAVEG.90S...@near.cs.caltech.edu>, da...@near.cs.caltech.edu (Dave Gillespie) writes:
> How many times have we all warned beginning programmers to cross their
> t's and dot their i's:  "Store through an uninitialized pointer, and
> the computer could do anything---it could even run amok and delete all
> your files!"
> 
> Okay, folks:  Have you ever had a bug in an innocent little program
> that really did delete all your files?  Reformat the hard disk?  Send
> rude mail to your mother?  (Well, probably not that.)

When I was at high school, we had an "assembler club" in which we learnt to
write assembler programs on Apple ]['s. N'way the teacher who ran this club
once wrote a program (can't remember what it was meant to do) that when run,
proceeded to trash the floppy and crash the machine. The latter was typical,
the former wasn't. A tad annoying when *everything* was on floppy. The error
boiled down to a TXA (transfer X register to Accumulator) where there should
have been a TAX - and do you think it was easy to find...

-- 
Alistair Veitch                      Phone: +64 071 562889 ext. 8768
Internet: coms...@waikato.ac.nz	    +64 071 562388 (home)
SNAIL: Computer Science Dept, University of Waikato, Hamilton, New Zealand
Laws of Documentation:
	1) If it should exist, it doesn't.
	2) If it does exist, it's out of date.
	3) Only documentation for useless programs transcends the
	    first two laws.

In article <DAVEG.90S...@near.cs.caltech.edu> da...@near.cs.caltech.edu
(Dave Gillespie) writes:
>[A cute story about a bug which formats a hard disk.  Makes it take a while
> to find.]

Not directly relevant, but I am reminded of the cardinal rule about writing
MS-DOS device drivers.

*ALWAYS* test your driver on a floppy before installing it on your hard disk.

Same basic idea.

-- 
This is a shared guest account, please send replies to
dbr...@nrao.edu (Internet)
Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801  (U.S. Snail)

In article <DAVEG.90S...@near.cs.caltech.edu> da...@near.cs.caltech.edu (Dave Gillespie) writes:
>Okay, folks:  Have you ever had a bug in an innocent little program
>that really did delete all your files?  Reformat the hard disk?  Send
>rude mail to your mother?  (Well, probably not that.)

In a previous incarnation I programmed an Apple II (or was that ][) in
Apple Pascal. It had the annoying habit of caching the disk directory in
(obviously) unprotected memory. Hence: a crazy pointer could corrupt the
directory with no obvious symptoms until you needed to do something important
with the disk, like save your work or something. Nice... The Apple also used
the extra few bytes on the edge of the memory for the screen image for various
data items in the OS (I think the printer was one). All I remember is that
when (not if) it came time to rewrite the screen I/O routines in assembler
it wasn't too hard to really mess the machine up in non-obvious ways simply
by having an off-by-one error in a screen-address calculation.  And then
there's the "intuitive" (to a TTL hacker) way that they mapped the video
memory that made those buggy address calculation routines so complicated in
the first place...  My Atari 800 was much more pleasant to work with...

da...@near.cs.caltech.edu (Dave Gillespie) writes:

>How many times have we all warned beginning programmers to cross their
>t's and dot their i's:  "Store through an uninitialized pointer, and
>the computer could do anything---it could even run amok and delete all
>your files!"

>Okay, folks:  Have you ever had a bug in an innocent little program
>that really did delete all your files?  Reformat the hard disk?  Send
>rude mail to your mother?  (Well, probably not that.)

While doing a CP/M80 BIOS, and generally bringing CP/M80 up and running,
my system suddenly decided that it was time to zero every bit in the
directory block on my work disk with all the source code on it. I
lost interest and bought another computer.... . I still haven't found the
bug (I stopped working  after the next identical incident...), but the
bug *is* probably very small and innocent.

	Jens
Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University
Snail mail: DIKU Universitetsparken 1 DK2100 KBH O
"It never runs around here; it just comes crashing down"
	apologies to  Dire Straits 

In article <DAVEG.90S...@near.cs.caltech.edu>, da...@near.cs.caltech.edu
(Dave Gillespie) writes:
|> Okay, folks:  Have you ever had a bug in an innocent little program
|> that really did delete all your files?
Well, we did have a new professor copy a Convex C1 executable to a Sun 3
and run it... it didn't DELETE any files, though. Quite the contrary.
It created several hundred files all with long names consisting of nothing
but random control characters interspersed with occasional gibberish.

\    /\    /\    /\/\/\/\/\/\/\.-.-.-.-.......___________
 \  /  \  /  \  /Dept of Geophysics, Stanford University \/\/\.-.-....___
  \/    \/    \/Joe Dellinger j...@hanauma.stanford.edu  apple!hanauma!joe\/\.-._
************** Reading News again, when I should be writing my thesis... *******

In article <DAVEG.90S...@near.cs.caltech.edu>,
da...@near.cs.caltech.edu (Dave Gillespie) writes:
|> How many times have we all warned beginning programmers to cross their
|> t's and dot their i's:  "Store through an uninitialized pointer, and
|> the computer could do anything---it could even run amok and delete all
|> your files!"

Here's mine:

I was working on a Pascal program on a PC, with lots of pointers here
and there.  I was running the program to test some new functions, but
of course it didn't work right the first time.  But at least it exited
cleanly.

Or so I thought.  About an hour later, I was copying some large files
over to diskette, and was puzzled by the speed of copying.  So I
decided to check before I deleted the files on the hard disk.

It turned out that every time I had copied a file for the last hour,
the copy was created with a length of 0 bytes....

_______________________________________________________________________
Bj|rn Munch                  | Div. of Comp. Science & Telematics,
bjo...@idt.unit.no          | Norwegian Institute of Technology (NTH),
PhD Student (well, soon...)  | Trondheim, Norway

In article <DAVEG.90S...@near.cs.caltech.edu>
da...@near.cs.caltech.edu (Dave Gillespie) writes:

| How many times have we all warned beginning programmers to cross their
| t's and dot their i's:  "Store through an uninitialized pointer, and
| the computer could do anything---it could even run amok and delete all
| your files!"
| 
| Okay, folks:  Have you ever had a bug in an innocent little program
| that really did delete all your files?  Reformat the hard disk?  Send
| rude mail to your mother?  (Well, probably not that.)

I posted this about a year ago.....

The first internal revision of the Data General 32-bit AOS/VS PL/1
compiler had a bug where it would sometimes delete your source file.
Options under AOS/VS are VMS-ish, ie:

	COMMAND/OPTION1/OPTION2=VALUE ARGUMENT1 ARGUMENT2 ARGUMENT3/OPTION4

Also, the equalivant option to UNIX's ./ for specifing a file in the
current direction was '=' in front of the filename and you tended to
use it more, since normal files had path expansion done on them (not
just executables like in UNIX).  Anyay, to create a listing file in
the current directory, you would do:

	PL1/L==FILE.LS FILE.PL1

If you mistyped it as:

	PL1/L===FILE.LS FILE.PL1

it would delete your source.  The networking folks were none too
amused by this behavior when they accidently typed it.
--
Michael Meissner	email: meis...@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Do apple growers tell their kids money doesn't grow on bushes?

In article <MEISSNER.9...@osf.osf.org> meis...@osf.org (Michael Meissner) writes:
>In article <DAVEG.90S...@near.cs.caltech.edu>
>da...@near.cs.caltech.edu (Dave Gillespie) writes:
>
>| How many times have we all warned beginning programmers to cross their
>| t's and dot their i's:  "Store through an uninitialized pointer, and
>| the computer could do anything---it could even run amok and delete all
>| your files!"
>| 
>| Okay, folks:  Have you ever had a bug in an innocent little program
>| that really did delete all your files?  Reformat the hard disk?  Send
>| rude mail to your mother?  (Well, probably not that.)
>
>I posted this about a year ago.....
>
>The first internal revision of the Data General 32-bit AOS/VS PL/1
>compiler had a bug where it would sometimes delete your source file.

   And so did Borland's TASM. The option to turn on symbol-table generation
for the debugger is /zi. One day, I accidentally typed /vi. According to
the manual, the /v option was included "for compatibility" and actually did
nothing.
   Well, what actually happened was that I got a message "I.ASM not found"
and TASM exited. Fine so far... but my source file was mysteriously
missing.
   Borland was able to reproduce the problem and it's fixed in TASM 2.0 --
that was one of the first things I checked when I got it. :)


   Of course, that's only the beginning of the story. I wanted my source
file *back*, after all. I didn't have Norton or anything, but I had a PD
uneraser. So I decided to use that.
   My hard drives were, at that point in time, all partitioned into 10M
chunks (for complicated reasons relating to the presence of an original
Plus 10M Hardcard in the system). A 10M drive normally uses a 12-bit FAT,
but I had hacked them all to use 16-bit FATs (to cut down on cluster
quantization waste). HOWEVER, the uneraser didn't bother to check what size
the FAT was. It assumed a 12-bit FAT and "repaired" it as such, which wrote
a lot of garbage all over the FAT.
   The next stupid thing I did was to run CHKDSK, which noticed that the
FAT was trashed and tried to repair it by truncating directories, files,
etc., thereby wiping out the entire partition.
   At which point I went out and bought Norton (which I should have done to
begin with) and spent two days repairing the disk by hand, since there were
some things on that drive which were unique. I'm much better about making
backups since then... :/

-- 
---
James W. Birdsall        jwbi...@amc.com         71261...@compuserve.com
          Compu$erve: 71261,1731            GEnie: J.BIRDSALL2
For it is the doom of men that they forget. -- Merlin

>>>>> On 4 Sep 90 02:33:31 GMT, meis...@osf.org (Michael Meissner) said:

> The first internal revision of the Data General 32-bit AOS/VS PL/1
> compiler had a bug where it would sometimes delete your source file.

I remember we once tried a new CAD tool here.  I don't remember the
details, but the idea was you wrote a file with a symbolic description
of the chip you want to build and it compiles it into layout.

So we typed in our first test file, ran the compiler, and it crashed
half way through with some weird error message.  No big surprise.

We looked back in our source file and found the compiler had changed
all the identifiers in the file into numeric ID's of some sort.
Kind of like that C obfuscator that was posted somewhere a while ago.
Presumably it had been planning to change them back afterwards...

Anyway, we decided not to use that CAD tool.  :-)

								-- Dave

--
Dave Gillespie
  256-80 Caltech Pasadena CA USA 91125
  da...@csvax.cs.caltech.edu, ...!cit-vax!daveg

In article <DAVEG.90S...@near.cs.caltech.edu> da...@near.cs.caltech.edu (Dave Gillespie) writes:
 >How many times have we all warned beginning programmers to cross their
 >t's and dot their i's:  "Store through an uninitialized pointer, and
 >the computer could do anything---it could even run amok and delete all
 >your files!"
 >
 >Okay, folks:  Have you ever had a bug in an innocent little program
 >that really did delete all your files?  Reformat the hard disk?  Send
 >rude mail to your mother?  (Well, probably not that.)

The previously mentioned disk editor aside, it was very, VERY easy to have
an assembler program start writing bytes to the memory locations containing
DOS 3.3 on an Apple ][, resulting in disk motor noise and more often than
not a scrambled, if not completely re-initialized disk.  Sometimes you
were lucky, though, and only the disk's VTOC would be trashed :-(.  Funny
how if you trashed a disk sector, it was usually track $11, sector 0...
--
===============================================================================
| Internet:   kuch...@Solbourne.COM	      |	William Kucharski             |
| uucp:	...!{boulder,sun,uunet}!stan!kucharsk |	Solbourne Computer, Inc.      |
=== The sentiments expressed above are MY opinions, NOT those of Solbourne. ===

When I have to use DOS, I sometimes get punished for beeing used to UNIX.
Last time I had to delete some files ending with "X". This is simple:

	DELETE *X.*

            Niels Elgaard Larsen            | 
            Institute of Datalogy,          | Long before Europe
            University of Copenhagen        | became the focus of world attension,
            E-mail: elg...@freja.diku.dk   | it was a focus for The Economist

Not really related, but my favourite ``bug'':

A while back, a team of us were `porting' Unix (TM) to an i386 based machine.
This machine had an intelligent SCSI controller card (couple of megs of cache,
i186 processor, that sort of thing) that handled the winis, the floppies, and
the SCSI tape. Wonderful piece of engineering, accelerated throughput quite
nicely. The only bitter bit being the tape interface - you had to pass the
tape device a list of disk blocks, and a SCSI device number. You then passed
the device a ``GO'' command, and the card would then set its busy bit, start
up the tape, and copy blocks from the disk to the tape (or vice versa).
While it was doing this, you polled the tape unit to see when it had finished,
and then sent a ``STOP'' command. Between the GO and the STOP the hard disk
was SCSI reserved, so you couldn't access it and change the data.

Well, we wrote a wonderful backup program called Eccup (named after a reservoir
just north of Leeds, a place of great beauty, unlike the program). Eccup
walked filesystems, building block lists, and ran the tape backup. Unfortunately
it had this nasty habit of hanging. Sometimes. If you added just *one* printf
to the code, it would stop hanging. If you added another, it might hang again.

After a lot of messing around with debuggers and the such, a stroke of
inspiration hit me. I got an assembler dump of Eccup, and lo and behold, the
test for the tape having finished and the sending of the STOP command where
in different memory pages, so the test would complete, and the process would
ask for the next page to be faulted in, but the disk is reserved, so instead
of the SCSI controller giving an error (which would at least give some
indication of what was going on), it queued the request, waiting for the tape
STOP command.

We could have spent months chasing a bug like that...

Jon.
-- 
Here I speak neither for Specialix, nor myself. What you see is all you get.
Jon Brawn, jo...@specialix.co.uk  (or for you bangers: ..!mcsun!ukc!slxsys!jonb)
  ``Once upon a time, not so very long ago, in a place not so very far away''