History's Worst Software Bugs (2005) • Hacker News Board

Re: History's Worst Software Bugs (2005)

#11

Post by trsohmers » Sat, Aug 01, 2015, 4:46 PM UTC

lordnacho wrote: post #5

Seem to me this list needs to incorporate how easily these bugs could have been avoided/detected/fixed, rather than just how dire the consequences were. It doesn't say much about what people did to test their code. For instance the first one in the list is something unit testing would have fixed. Take the trajectory function, plug numbers in, see if it's correct. Some of these things were a lot more obvious than othe…

The non hardware based floating point bugs would not be an issue if using a variable precision floating point format, such as the in development Unum (previous HN discussion: https://news.ycombinator.com/item?id=9943589)

Re: History's Worst Software Bugs (2005)

#12

Post by trsohmers » Sat, Aug 01, 2015, 4:52 PM UTC

Another thing which should be in this list (relating to floating point rounding error):

"On 25 February 1991, a loss of significance in a MIM-104 Patriot missile battery prevented it intercepting an incoming Scud missile in Dhahran, Saudi Arabia, contributing to the death of 28 soldiers from the U.S. Army's 14th Quartermaster Detachment."

https://en.wikipedia.org/wiki/Floating_point#Incidents

Re: History's Worst Software Bugs (2005)

#13

Post by BinaryIdiot » Sat, Aug 01, 2015, 5:02 PM UTC

luso_brazilian wrote: post #6

No mention to Y2K and mankind can thank the millions of man/hours employed (and regally paid) to stamp out the majority of the occurrences of that bug. It could really be a game changer if it didn't get fixed and I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.

> I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.

I've been wondering the same. The Y2K bug was easy for many places to fix. Granted I wasn't a profressional developer at that time but I've looked at historical fixes at the companies I have worked at and all of their solutions were pretty easy (change application code to use 4 numbers instead of 2, run SQL update script to update existing data, done). But the 2038 bug? That one isn't near as obvious to fix in my opinion.

Re: History's Worst Software Bugs (2005)

#14

Post by perlgeek » Sat, Aug 01, 2015, 5:08 PM UTC

BinaryIdiot wrote: post #13

luso_brazilian wrote: post #6

No mention to Y2K and mankind can thank the millions of man/hours employed (and regally paid) to stamp out the majority of the occurrences of that bug. It could really be a game changer if it didn't get fixed and I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.

> I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting. I've been wondering the same. The Y2K bug was easy for many places to fix. Granted I wasn't a profressional developer at that time but I've looked at historical fixes at the companies I have worked at and all of their solutions were pretty easy (change application code to use 4 numbers instead of 2, run SQL update scr…

The obvious fix is to use a 64bit integer to hold timestamps.

Re: History's Worst Software Bugs (2005)

#15

Post by nickpsecurity » Sat, Aug 01, 2015, 5:12 PM UTC

trsohmers wrote: post #10

TillE wrote: post #4

The title said "software", so I assumed they were going to exclude the infamous Pentium FPU bug. But no, there it is. To me, the interesting thing about testing a CPU is that it's theoretically possible to comprehensively test all inputs and outputs, but the time required makes that totally impossible.

Not so much anymore... there has been a ton of work put in by the EDA companies to get companies to do formal verification (which they obviously sell very expensive tools for) even before you get to physical design and testing. For the chip my team is designing, we are formally verifying our ISA using a new domain specific language ( http://www.cl.cam.ac.uk/~acjf3/l3/ ) which really helps lock down the "gold model" w…

Exactly. You might like and keep handy this illustration from IBM's efforts. I think it nicely summarizes many of the tasks and issues in HW verification at various layers. At the least, it should give the impression to readers of how overwhelming the job can be without best-in-class tools. ;)

http://www.testandverification.com/DVClub/03_Jul_2014/DVClub...

I think we can do same for software, though. Just got to keep it simple, layered, and each layer building on one before it properly. I did it informally in a style that copied Wirth's Lilith work albeit special-purpose. Verisoft did quite a bit on full-stack for imperative. SAFE (crash-safe.org) is working on it for functional. I think a shortcut is to implement VLISP Scheme in hardware using hardware verification techniques along with previously verified I/O system. I've already seen LISP processors, VLISP for rigorous implementation, Shapiro made a security kernel, and the right hardware target can be reused for ML and Haskell code potentially. To counter hardware issues, run several in synch in same way as old Tandem NonStop architecture. Result should be flexible, fast enough for some workloads, enforce POLA, and have five 9's.

What you think of combining a verified LISP with hardware implementation as a time saver on goal to verification?

Note: Remember that, once we have that, building and verifying other toolchains is so much easier because we can work at high-level. Even highly-optimized systems such as yours could benefit from rigorously-verified systems maybe running same synthesis or checks overnight as a check against faster, possibly buggy implementations you use for iterations. Although, I mainly see them as a root-of-trust for other systems in network.

Re: History's Worst Software Bugs (2005)

#16

Post by nickpsecurity » Sat, Aug 01, 2015, 5:15 PM UTC

trsohmers wrote: post #10

TillE wrote: post #4

The title said "software", so I assumed they were going to exclude the infamous Pentium FPU bug. But no, there it is. To me, the interesting thing about testing a CPU is that it's theoretically possible to comprehensively test all inputs and outputs, but the time required makes that totally impossible.

Not so much anymore... there has been a ton of work put in by the EDA companies to get companies to do formal verification (which they obviously sell very expensive tools for) even before you get to physical design and testing. For the chip my team is designing, we are formally verifying our ISA using a new domain specific language ( http://www.cl.cam.ac.uk/~acjf3/l3/ ) which really helps lock down the "gold model" w…

Btw, thanks for the L3 tool. Might come in handy.

Re: History's Worst Software Bugs (2005)

#17

Post by luso_brazilian » Sat, Aug 01, 2015, 5:28 PM UTC

perlgeek wrote: post #14

BinaryIdiot wrote: post #13

Earlier quoted context omitted.

> I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting. I've been wondering the same. The Y2K bug was easy for many places to fix. Granted I wasn't a profressional developer at that time but I've looked at historical fixes at the companies I have worked at and all of their solutions were pretty easy (change application code to use 4 numbers instead of 2, run SQL update scr…

The obvious fix is to use a 64bit integer to hold timestamps.

That's the fix, of course, but what about all the embedded software that will last enough to cross that barrier but that won't be upgraded from its 32bits timestamps?

Re: History's Worst Software Bugs (2005)

#18

Post by scott_s » Sat, Aug 01, 2015, 5:41 PM UTC

The Morris worm is on that list; Robert Morris is a partner at Y Combinator. That incident is the source of the pg quote that would not stop kicking around in my mind through the latter half of grad school:

"The danger with grad school is that you don't see the scary part upfront. PhD programs start out as college part 2, with several years of classes. So by the time you face the horror of writing a dissertation, you're already several years in. If you quit now, you'll be a grad-school dropout, and you probably won't like that idea. When Robert got kicked out of grad school for writing the Internet worm of 1988, I envied him enormously for finding a way out without the stigma of failure."

From http://www.paulgraham.com/college.html

Morris is now also a tenured MIT professor, so things ended up okay for him.

Re: History's Worst Software Bugs (2005)

#19

Post by CookWithMe » Sat, Aug 01, 2015, 5:52 PM UTC

The Soviet Gas Pipeline explosion - if the whole CIA story is true at all - should not be labelled a bug... The code allegedly did exactly what it's creator intended ;-)

Re: History's Worst Software Bugs (2005)

#20

Post by Retric » Sat, Aug 01, 2015, 6:38 PM UTC

lordnacho wrote: post #5

Seem to me this list needs to incorporate how easily these bugs could have been avoided/detected/fixed, rather than just how dire the consequences were. It doesn't say much about what people did to test their code. For instance the first one in the list is something unit testing would have fixed. Take the trajectory function, plug numbers in, see if it's correct. Some of these things were a lot more obvious than othe…

Unit tests would be highly unlikely to catch most of those.

"a formula written on paper in pencil was improperly transcribed", "neglect to properly "seed" the program's random number generator, A HW bug that's not close to obvious numbers to check, intentionally inserted bugs, input outside of the intended design, etc.