Slashdot Mirror
Examples of Programming Gone Wrong?
LightForce3 asks: "I'm a beginning CS student, and in my studies I've come across examples of programmer error causing very large problems, such as the Ariane 5 failure and the Therac-25 accidents, often as tales of caution to beginner programmers such as myself. My (morbid?) curiosity has been piqued, and I'm looking for other examples of programmer error leading to serious problems. After all, it is better to learn from the mistakes of others than from your own, right? ;) What programming-related accidents, incidents, and failures, both well-known and obscure, do Slashdot readers know about, and are there any good resources for researching these?"
When Programming goes Wrong 2! Thrill to our latest reality TV series where we show REAL LIFE footage of poorly thought out database schemas, unchecked buffers and even explicit shots of forbidden goto statements.
This book is devoted to just that. It's what you're looking for...go get it and read it.
http://slashdot.org/articles/99/09/30/1437217.shtm l
-- Kircle
1.) Patriot missile failure
2.) Intel f*cking up floating-point calculations in one of their chips
3.) High-tech toilet glitch (no, really!)
4.) Windows ME
If you celebrate Xmas, befriend me (538
What happened to Challenger wasn't a programming mistake, but rather a case of not following policy. The solid rocket boosters were never designed to operate in cold temperatures. The result of working outside of design specs was catastrophic failure, yes, but that wasn't the result of a programming error.
In the 80's, Robert T Morris accidentally released a worm that exploited problems in sendmail and other common internet daemons that took down most of what was the internet at that time. This was expecially bad since about half of it was military.
...wherein a technique to save memory on older computers resulted in a massive media panic twenty years later. Oh, and it caused a couple glitches
Co-founder of GerbilMechs
A Central Office (CO) switch is basically a mainframe-class computer programed in assembler. A few years back, a newly-installed switch failed due to a bug in the code, causing a cascading failure of the phone system for a few hours.
Incorrect: This was not a programming issue. Nor was it a software issue at all. The problem was the O-ring seals in the SRBs (Solid Rocket Boosters). The manufacturer stated that they should not be operated under 53 degrees, and NASA overrode the recomendation and launched anyway. The expected happened.
NASA hasn't ever had a hardware problem. Or a software problem. Ever. Every problem can be directly tied to one specific person being a fscking moron. The closest you could come is that Mars probe that crashed because of mismatched units. And that was just poor communication among the software guys.
Professor Falkin was always saying, "Leave a backdoor in any program you write, just in case your code becomes self-aware."
The only reason it took thigns down was because a timing loop was messed up, and it was spreading something like 1000 times too fast. It was supposed to spread everywhere, yes, but by crawling slowly.. it was not intended to eat up all connections on all machines.
Had that been the case, it would have been much more widespread and caused much less damage.
The RISKS Digest is a mailing list and usenet newsgroup that describes all kinds of situations where technology has gone wrong. Many of the stories involve programming errors.
Google's RISKs Archive
I'll agree that some programming errors *could* be fatal, but the one that comes to mind is the "2 line change" from AT&T that essentially knocked out phone service throughout the east and mid-west in 1990. It was the topic if many quality assurance seminars for the better part of the early 90's. I only remember it because it effected my company -- we lost phone service for 2 days. It was also one of those traditional "last minute changes" that someone clearly f*cked on...
http://www.soft.com/AppNotes/attcrash.html
Outlook!
Built with the idea that code in attachments should be executable, often automatically. Also full of exploitable bugs, to get even more stuff running automatically, regardless of who who sent it. Responsible for a huge amount of damage by all sorts of worms, trojans, etc.
Someone, somewhere got the idea that email would look better with html; and if it got html, it should get scripting too, that's consistent with web pages! And it's cool if attachments (like pictures) can be opened in their appropriate program automatically - let's run any executables then, that's consistent!
This is oversimplified, but I really feel that this is a case of stupid consistency that caused multi-billion dollar damage. Email should never be executed by the mail client.
I believe posters are recognized by their sig. So I made one.
Here's the Link
-- Kircle
Why not provide a link instead of saying "Oh yeah, I saw it way back when."
You people who say "use google to find it" or "this was already asked" are worse than the people who actualy ask the question.
Their only problem (if it could be said to be a problem) is ignorance, your kind however are a much better example of the problem of self-rightous lazyness.
Oh wait... -1 Redundant
Here's a good site though with tons of examples.
My favorite would be the infamous time when NASA did half its calculation in metric and the rest in SI. ;)
F-bacher
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
MIT runs a class called 6.033: Computer Systems Engineering. These lecture notes contain a list of projects that had great sums of money spent on them only to be abandoned. Also the reading list has a bunch of papers that discuss the "big splash" failures like Therac 25.
but couldn't find it.
Anyway, here are a couple of links.
Software horror stories
More horrors
that was told to my class about the altitude of fighter jets.
A company was hired to rewrite the code that was used on one of the models of fighter jets, and they offered to fix an unusual bug.
The details are: apparently they had two altimeters - one was barometric, and the other I don't remember.
Anyway, the programmer was coding along, and was writing code to determine what would happen if the altimeters stopped functioning.
He came to the case where they both weren't working, and couldn't figure out what to do, so called one of the pilots that was acting as an information source for the developers, and asked him what altitude they normally flew at, and he answered, "12,000 feet" or something similar.
So the programmer wrote,
if altimeter1 not working
{
if altimeter2 not working
{
set height = 12000;
}
}
Stupid, but this code could not be changed. The pilots had the following rule deeply ingrained: if the altitude stays at 12,000 for more than a few seconds, pull up, as your altimeters aren't working.
If you've ever seen Edward Tufte's canned speech, he partially attributes the event to an inability of the engineers involved to organize and present their information in a clear way to communicate the nature of the problem.
couldn't find it either, huh ? ;)
Wouldn't setting it to something like 0 be better? I mean, I could miss it sticking at 12,000 for a while, but if I notice that my altitude is suddenly 0, I think my first instinct will be to pull up as fast as possible.
F-bacher
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
I used to work for a 1999/2000 'golden child' dot-bomb which dealt in file trading... a proposed legal form of napster. It was a fucked company from the start, but it still had a lot of traffic in the early days.
:)
:)
We always had problems with downloading files from the site.... the files kept getting corrupted, and occasionaly, a member would complain that they tried to download a powerpoint presentation and ended up getting 4 way anal porn.
This perplexed the developers, and it was not until 9 months after going online with the site, did they realise that the java class that dealt with the downloads was a single process shared by all users!
So, your download would go ok IF nobody else tried to download at the same time. If two people clicked download at about the same time, you would download the file that the second person wished to download.
No wonder they went bankrupt
-- 7 string electric violin + live loop samplers
When they played Heidi over the end of the greatest come-back in football history. Oh wait, you didn't mean that kind of programming, did you?
Do what you can, with what you have, where you are.
Don't be so narrow in your approach. Is it a programming error if a stadium roof collapses because the engineers couldn't understand what the output of their computer model was saying?
What about when the construction crew quietly substituted what they thought was an equivalent design to what the computer program came up with for a skywalk over a hotel lobby?
After almost 20 years in this field, I think that at least 80% of the serious "errors" I see are because the user didn't understand the results of the program, and only 20% of them are due to classic development errors.
The lesson to learn from this: the user interface matters. Give some thought to presenting the information in a meaningful manner (e.g., the infamous pre-Challenger graphs showing O-ring erosion vs. the post-Challenger graph that mapped damage by temperature at the time of launch), and allow users to see the information in the way that makes the most sense to them.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
... should be enough to write a dissertation on the thoughtless computing leading to serious problems.
Anyone got a reliable link for the toilet one?
... well ... acurate news.
I've never really considered the register to be a source of
A company I once worked for (as an intern) was in the business of what's called "train control" software. Briefly, it's the software that dispatchers use to monitor the status of the switches, the position of all the trains being tracked by the system, etc. One of the features of the system is to provide early-warning of potential collisions. Well, the system is quite reliable (having been in service, in one form or another, since the 70's). However, there have been some accidents.
Once such accident, in Mexico, was caused by an unexpected combination of several simultaneous failures. One day, for some reason, one of the servers needed to be reset. At the same time, two freight trains were stopped at a switch, in the process of what's called a "pass," where one train turns off onto a side track to let the other train pass by on the main track. Long story short, the status bits of the switch got lost during the server reset (there is a provision for restoring track states when the backup servers take over, but it didn't work for some reason). After asking if the track was clear, the driver for train1 recieved a green light from the dispatch office. The dispatcher, not knowing that train2 hadn't cleared the switch yet, figured everything was ok. The trains collided at very low speed, and not head-on, but nonetheless the collision cost the rail line several million in equipment and downtime. No one was hurt.
The lesson: When writing bullet-proof software, check every possible condition! More extensive field testing would have caught the failover bug.
A poor communication among the software guys that results in improper units being used in a program isn't a software problem?
If that wasn't a software problem, what was it? All software problems are defects in design or implementation, they all go back to a miscommunication or mistake among some software people somewhere.
I'm an AC for a reason...
Let's just say that two years ago a very large international shipping company suffered two days of worldwide failure in the package routings printed on labels. The bug was caused by an incorrectly placed paren in an index offset calculation, leading to truncation of an intermediate result (to a 16 bit unsigned int, when it should have been 32). The bug sat dormant for five years because the result matrix it was indexing into was smaller than 64kbytes. As soon as it grew over that size - boom! What a way to wake up at 2am when the Asian-Pacific region starts calling...
I didn't make it, but I was definitely involved with the fix. After that we did some very thorough auditing on all of the routing code - and fortunately didn't find any other surprises lurking.
Not a specific example, but a big mistake is to assume that just because when you use a function in a certain way that works means it's suppose to work that way. I've seen so many people fail to read any documentation on the functions they are using. Whenever I program, I make sure every function, operand, everything I use I understand what they do exactly. I don't just assume, I make absolutely certain. Read, Read, Read, and then Read some more.
..There's a-dooin's a-transpirin'
No, really.
Search and you will find.
Learning to search effectively will serve you best.
Yes but the lander was friggen funny, you can u just see the guy sitting there, taking a hit off a bong then stateing. "Dude dude, comehere, got a problem" "whats that?" "*giggle* Well you know the lander *gafaw* the navigation was in meters....but i programmed the lander in feet, so instead of landing *grin* fsck'er burried..... I wish there woulda been another lander there to see that one hit, woulda been the shot of a lifetime. Besides, nasa crashes things into things on perpose:)
Jesus saves, everyone else takes full damage from the fireball.
I think it would be interesting to know when the first infinite loop occured in the early days of programming, and how the programers dealt with it. Obviously, back then they only had single-tasking machines.
Let's say you turned in some bad FORTRAN code to the university computer on a time share. What if nobody noticed for hours that your program was taking up all the processing time? That would make some people pretty pissed. :p
This isn't really a programming error, but a user training error.
In the Airbus if the pilot tries to correct (use the flight controls) while the computer is engaged the computer will correct the pilot's correction. Unlike in a car with cruise control where if you hit the breaks it just cuts the cruise control. Many China Airlines planes have crashed due to poor pilot training in this regard. They weren't trained well enough to shut off the computer control before taking control of the plane.
I'm also sure someone can be a little more detailed than this, but it is, IMO, at least a design error that has caused hundreds of deaths.
As a side note, my Software Engineer professor refused to ever fly on a fly by wire plane, and was opposed to SDI simply because he didn't beleive that either had been or ever would be debugged properly. (if there is one error in every 10,000 lines of code, and it has 3 or 4 million Lines of Code, how many errors is that? His answer: too many to trust)
Come on now, that's the lazy way!
How about citing an actual example of windows code bugs causing big problems? I'll go first. The USS Yorktown had to be towed back to harbor when the NT system that was automating most of the ship crashed.
What? The French make exelent cars..(Peugeot, Citroen)...
The American cars on the other hand are *completely* hopeless!
Try a Peugeot 206 / 307 and feel how it handels the road. Then you don't even want to go back!
Moderation: +4. Modded 70% Funny and 30% Overrated. 100% Saturated.
Yeah it is probably in the archives. I've read it before.
:-)
Problem is, the slashdot search engine sucks. I haven't yet been able to query the archives and actually find what I'm looking for without needing to dig through hundreds of irrelevent discussions. Sometimes I think it might be faster to just scroll back through the "Older Stuff" section.
Or we could just have another discussion about it.
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
I worked for a programmer back in the 80's who made a mistake that caused all credit card purchases to disappear from the electronic journal. This meant that their purchases were not recorded on their credit card statements. Fortunately for the company the bug did not affect the recording of the transactions on the paper journal. This bug wasn't discovered for a few days and it took quite some time to rekey all the credit transactions.
Unfortunately this was not her first or last mistake of this magnitude. Retailers often see IT as an expense rather than an asset and are as cheap as possible. This has a tendency to cause shoddy programming since they hire as few programmers as possible and overwork them and often software is put into production without being thoroughly tested. At least this was the case when I worked in retail some ten years ago--I don't think I'll do that again.
But I am finding that insurance companies have the same philosophy.
US shooting down Airbus 320
You're referring to the destruction of Iran Air flight 655 by the USS Vincennes near the Strait of Hormuz, on July 4, 1988. For one thing, it was an Airbus A300 (bigger and older than an A320). The failure there was mostly in human decision making, not in the AEGIS radar system, which faithfully reported that the airliner was travelling at 450 knots on a steady bearing towards Vincennes, roughly four miles outside the commercial air corridor, and not broadcasting IFF information (which of course they wouldn't, as a foreign civilian airliner). It was the officers of Vincennes who interpreted this information as a threat, misidentified the target as an Iranian F14, and destroyed it.
Toronto-area transit rider? Rate your ride.
http://slashdot.org/articles/02/05/02/1525210.shtm l?tid=128 - Debug your code, or else!
:-)
Using google's serach engine provides better results for slashdot.org that slashdot's own search engine
A poor communication among the software guys that results in improper units being used in a program isn't a software problem?
That's correct. It's a communication problem
If that wasn't a software problem, what was it?
A miscommunication between software guys...
All software problems are defects in design or implementation, they all go back to a miscommunication or mistake among some software people somewhere.
Your definition of a software problem is to vague to be proper...
But anyway, that's only half true. The problem is that not all software bugs go back to that source... hardware plays a big role as well.
SELECT * FROM BugTraq_SecurityFlaws WHERE FlawCause LIKE '%buffer%overflow%' ORDER BY OSType ASC
Never underestimate the relief of true separation of Religion and State.
I had always thought that SI was the English system; I have no idea why.
Thanks,
F-bacher
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
Not ONE hardware problem...ever?
Clearly you are forgetting the Apollo I fire which resulted from a spark in a pure O2 atmosphere. The spark was caused by a frayed wire. That's a hardware problem for sure.
IIRC Germany lost some telephone service in some areas. Otherwise not a whole hell of a lot.
>
the database they were using faulted on a divide by zero. nothing to do with NT.
Despite what may programmers think, they do make many mistakes. Having been in QA for more than 7 years, blimey, the stories I could tell.
For example. Once there was a requirment for a windows program to do nothing. If it started up, it would just shut down . Simple? I would have thought so - even if it wasn't, it was simple for the developer to unit test. It took 7 attempts. Ranging from opening a window and sitting there - through several GPFs - and at least one reboot.
Then there was one time (of many) where despite assurances from development that the product had been properly unit tested, it would core dump on start up.
My point is that any CS student should understand the whole development process. It is more than just programming. Whilst neither of the above were life threatening, it illustrates a point. No matter how many examples of catastrophe and failure you find, there would be alot more without testing and QA.
Of course, you could take the point that all those public failures are a result of lax QA.
I can't recomend the risks site too highly. (redundent I know)
a m.html
Risks To The Public In Computers And Related Systems
http://catless.ncl.ac.uk/Risks
On how to be 0wned by other people: Counterpane: Crypto-Gram . Shares with comp.risks the reframe of "I can't belive people don't learn from this"
Counterpane: Crypto-Gram
http://www.counterpane.com/crypto-gr
Don Norman's _The Design of Everyday Things_ and website also offer insight on how to avoid UI failures relating to failures.
http://www.jnd.org/index.html
Also, get a copy of _Code Complete_ and/or _Code Write_ by Steve McConnell [pub: Microsoft Press Which is rich irony) Lots of mistakes and how to avoid them.
The cautionary note might be that most of these failures are human related at some level. Whether it be at the project level, or the UI level -- there are lots of ways to cause a failure.
Finally, avoid any kind of carreer in Software QA. There is no better way to just get kicked around at the expense of the people putting the bugs in the software in the first place.
Anybody can work under ideal circumstances. -- Jeff K. (January 4, 2001)
I love how complete bullshit gets moderated to +5 Informative on slashdot. Why not do a tiny bit of fact checking and slam people for misinformation rather than praising them for anything negative having to do with Microsoft???
Indeed. The Slashdot search engine seems to OR the search terms together, which is of course very stupid. It is a prime Example of Programming Gone Wrong.
Someone here was claiming that NASA has never had a software bug. That sounded pretty unbelievable to me. And sure enough, it's not true. In the recent Mars missions alone, they had a bunch of software bugs resulting in things varying from non-fatal vehicle failures to outright loss of spacecraft.
Regarding the loss of the Mars Climate Orbiter spacecraft, from nasa.gov: "The 'root cause' of the loss of the spacecraft was the failed translation of English units into metric units in a segment of ground-based, navigation-related mission software"
Also, here are several "software bugs" (their words) relating to the Mars Surveyor Lander Vehicle are described. These bugs were detected and fixed in the field (ie, Mars). At least one of the bugs caused a heater failure in the vehicle on Mars. This failure was recovered from.
Anyways, those are just two quickies, but NASA has their share of bugs. (And generally some pretty ingenious ways to reprogram and update vehicle software post-launch.)
On a related note, here's a paper from NASA entitled "The Infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software".
After all, it is better to learn from the mistakes of others than from your own, right? ;)
:p
It is better. It is also very rare. Most people (especially programmers) that I know have to learn things the hard way, myself included. Sometimes, you can be told "no, don't do it that way" over and over and over, and still want to do it that way until you realize, the hard way, why you maybe should have listened.
Or maybe that's just me, and the weirdo's I hang with...
NGWave - Fast Sound Editor for Windows
I can't believe no one has mentioned it yet -- it's probably because they don't care about the third world
Well, I do care about the third world. But I was not aware the Bhopal disaster was down to dodgy software. I always believed it was reckless cost cutting by a faceless multi-national which took advantage of the fact that India, as a developing country, didn't have very good health & safety legislation.
But I think the main reason disasters like this are ignored is that poor people don't make very good consumers, so the consumerist society pays little attention to their wants and desires. And their deaths are little more than statistics.
10,000 dead? Bung them some cash.
Now, what do you think would happen if a large number of decent hard working consumers were wiped out in a single event?
Do you mind, your karma has just run over my dogma.
Actually I think that no one mentioned this since it has nothing to do with programmer error. (At least not according to what you linked to.)
Karma: Incomprehensible (Mostly affected by posting at +5, reading at -1, and metamoderating everything unfair.)
Now, what do you think would happen if a large number of decent hard working consumers were wiped out in a single event? it did, 09/11/01
"Sic Semper Tyrannosaurus Rex."
To increase altitude in an aircraft, you add power, not pull up. Pulling up slows the aircraft down and decreases altitude.
Much as I dislike NT, especially in critical environments, this problem had nothing to do with NT. It had everything to do with bad coding.
As we all know, information systems are only as smart as people make them. In the case of the USS Yorktown, an admin/operator entered data which caused a divide by zero condition in the application. Because the application did not have any exception handling built into it for a divide by zero condition, it died.
You can't blame the OS for this. The application should have had exception handling built into it in a couple of places. It probably should have checked any new entries before comitting them to ensure the new data would not introduce such a condition, and the app itself should have had appropriate error handling to prevent a panic/dump when a divide by zero condition was encountered.
If the app was coded by the same people on another platform, the end result would have been the same.
Idiot, n. A member of a large and powerful tribe whose influence in human affairs has always been dominant
Please stop all this "STFW" crap. It's easy to search the web, but there may be people out there reading slashdot who haven't put their tale of programming woe on a web page. In the time it took you to post that crap, you could have thought for a moment, then not said anything.
Using a pure O2 environment simplifies things tremendously. The bigest thing is that when the craft is in space, it leaks. Period. You can't stop it. So they need to replace the air as the mission progresses. Running in a pure O2 environment allowed them to operate at a lower pressure, which means that they needed to take up less air with them, which meant a lighter capsule, which is very good.
After the Apollo 1 fire, they switched to a mixed atmosphere envrionment on the ground, but only replace the leaking O2 in space. So after a while in orbit, they are actually back to a pure O2 environment. This saves the craft from having to carry replacement O2 and N2, while not really risking safety. (Fire doesn't spread well in space due to lack of convection.)
http://www.acme.com/jef/netgems/scratch_monkey.htm l
-calyxa
Decay! Decay! Decay! -Helium
Actually, the switching code was in C and the crash was due to a programmer's apparent misunderstanding of the 'break' statement. See full details at: http://www.csc.calpoly.edu/~jdalbey/SWE/Papers/att _collapse.html
An Air France A320 (a new design) was doing a low-altitude fly-by at an airshow when the aircraft descended into terrain.
The pilot, since convicted of manslaughter, claims the aircraft reported AGL (above ground level) altitude to be 100', while video shows the aircraft was closer to 30'. There is significant evidence to support this story, such as the apparent swapping of DFDRs and the issuing of Operational Engineering Bulletins to correct problems as explained by the captain of the aircraft.
The captain claims that the throttle by wire system would not respond to increased command, so he retracted them to idle, then advanced them to Takeoff/Go Around (full). The aircraft had crashed by that point, killing 3 aboard.
See this for more.
-twb
http://wwwzenger.informatik.tu-muenchen.de/perso ns/huckle/bugse.html
It's not as simple as you make it out to be. NASA's Marshall Center applied a significant amount of pressure to Morton Thiokol (the contractors who designed and manufactured the solid rocket boosters) to give them the go-ahead. See, the contractors have absolute veto authority; if they want NASA to not launch, NASA can't do anything about it. However, NASA was under a TON of schedule pressure to launch. (There's even a conspiracy theory that Reagan ordered NASA to launch so he could call McAuliffe in orbit during the State of the Union Address scheduled for that evening, but there's absolutely NO evidence that this is true.) NASA passed off that pressure onto the management Morton Thiokol, who unfortunatly buckled under it.
The poster said they'd never had hardware problems, which I suspected as classifying problems as EITHER a software problem or a hardware problem.
If a miscommunication among software guys that results in a bug isn't a software problem, then what exactly is a software problem?
The most common kind of internet security failure derives, it would seem, from buffer overflows on the internet.
These buffer overflows invariably arise from unsatisfactory bound checking -- one of the simplest kinds of bugs, and are easily exploited these days by script kiddies.
Examples are too numerous to mention.
>>I always believed it was reckless cost cutting by a faceless multi-national
Yes, but more than that, is was a lack of communication between sections. I forget exactly what caused this incident, but it was four or five different problems that all went wrong at once. Had any of them not had problems, thye porbably would have been closer to a Three-Mile Island scare rather than any actual damage occuring. But two of their safety systems were off-line for maintainance, and a third and fourth were poorly designed. Something like that.
Back when C++ was new, there was an insidious problem with the syntax that never showed up during compilation.
//check for \ //found one, handle path
if(c=='\')
slashfound=1;
++index;
Code similar to this delayed shipment of a commercial product because it caused serious instability.
.
I've read in-depth technical analyses of the Apollo fire, and I have an MSc in Physics.
Before that, *no-one* knew that a spark in one place could cause a fire TWO FEET AWAY.
(You get little hot bits of burnt dust floating around in a pure oxygen atmosphere, and they keep themselves hot enough to set something else afire quite a ways away. Of course things are *easier* to set fire to in that atmosphere as well.)
Some of the tips, which may appear obvious to some of us, include:
--- Fox
It was a new financial system, and it was a real mess - something like £9m initial cost and £20m due to its flaws. According to Anthony Finkelstein, who's written a very detailed report on the fiasco:
You can read his full report here (pdf) or here (google html version). There are also news reports on the system here and here.
Basically, it was bad management throughout... a classic case of a big software project gone wrong.
Horror stories (lost rockets, etc) are certainly attention-getters, but a more useful question might be what kinds of errors got made, regardless of how severe the outcome.
For example, I once helped a newbie employee with a program that was working fine in a simple test case, but was blowing up when it tried to crunch through a production file.
After digging a little, I noticed that she was using recursion in her "GetNextInterestingRecord" routine! The logic was:
1) Get a record
2) See if it's the kind we want
3) If not, Call self
4) return record to main
I'm not sure why she chose to use recursion (too many classroom lectures on "cool" stuff and too little experience with getting useful stuff done?), but the program needed "interesting" records every so often to keep from overflowing the stack.
Clearly recursion should be confined to those problems where it's really needed, and not used just because you can find a way to state the problem using recursion. And even then, you need think about how big the stack will get, and what sorts of scenarios could cause it to get too big.
From the site:
"In 1969, as part of its global empire, Union Carbide Corporation set up its pesticide formulation unit in the northern end of the city of Bhopal in central India. Initially it mixed and packaged pesticides imported from the US but was gradually expanded. In December 1979 its Methyl Iso Cyanate (MC) plant with an imtalled capacity of 5000 tonnes went into production.
On the night of December 2, 1984, during routine maintenance operations in the Methyl Iso Cyanate (MC) plant, at about 9.30 p.m., a large quantity of water entered storage tank no. 610 containing over 60 tonnes of AEC.
This triggered off a runaway reaction resulting in a tremendous increase of temperature and pressure in the tank and 40 tonnes of MIC along with Hydrogen Cyanide and other reaction products burst past the ruptured disc and into the night air of Bhopal at around 12.30 a.m. Safety systems were grossly under-designed and inoperative. Senior factory officials knew of the lethal build-up in the tank at least one hour before the leakage, yet the siren to warn neighbourhood communities was sounded more than one hour after the leak started.
By then, the poisons had enveloped an area of 40 sq.kms. killing thousands of people in its immediate wake. Over 500 thousand suffered from acute breathlessness, pain in the eyes and vomiting as they ran in panic to get away from the poison clouds that hung close to the ground for more than four hours."
Nothing to do with programming errors here that I can see. Sounds more like gross negligence and incompetence to me.
-A.
student of animation and the fine arts
Prevent email address forgery. Publish SPF records for y
Well, except for Mars Polar Lander, where the failure review board determined that the lander crashed because a flag indocating contact with the ground was not intialized to zero prior to the start of the retro-thruster loop. So the flag got set by the shock of deploying the landing legs, never got reset, and caused the thrusters to switch off as soon as they were on.
I guess maybe you forgot about Apollo 13 as well (hardware)? Or the Galileo High Gain Antenna that failed to deploy (hardware)? Or the serious telemetry system problems they had with one of the Voyagers (hardware)? Or the faulty landing bag on one of the Mercury flights (hardware)? (was it Glenn's? I don't remember) Or that funky glitch in the landing computer during Apollo 11 (software)? You know, there's a reason that most space mission tend to be heavy on redundant hardware, and invest a lot of time and effort in fault protection software.
Every problem can be directly tied to one specific person being a fscking moron.
Well yeah, but that's the case with a lot of bugs, isn't it? Mistakes tend to be people issues.
The closest you could come is that Mars probe that crashed because of mismatched units. And that was just poor communication among the software guys.
You are at least correct about that - the problem was not a software issue. Lockheed Martin Astronautics was on contract to supply everything to NASA in SI units (which is what NASA uses for everything). LMA - or at least the part the caused this problem - uses English (Imperial) units internally, and neglected to perform the appropriate conversion before they sent the data on to NASA.
- [...] Mars probe that crashed because of mismatched units. And that was just poor communication among the software guys.
So if it's not a bug, it must be a featureHave an article on the guys who write the stuff. They're damn good, but they say themselves their programs contain errors: "the last three versions of the program [...] had just one error each. The last 11 versions of this software had a total of 17 errors." Apparently never caused a problem, but not bug-free.
Then there was the Canadarm2 issue. Or wasn't that a bug either
yes, we have no bananas
Actually, it was more a case of bad presentation skills. Check out Edward Tufte's "Visual Explanations" for a complete rundown, but basically, IIRC, one guy (or group) knew of the danger and spoke up about it. His supervisors said "Okay, write me a report detailing excactly why we should delay the launch." He did, and it was a very confusing report. So they went on with it, and, well, you know the rest.
c-hack.com |
no, i was just saying that we do have an example of what happens when you lose several thousand consumers in one fell swoop, and the aftermathof such an event, not a whole lot happened after bhopal, i dont feel like researching much, but i'm willing to bet the only changes were stricter regulations on plants like that, after the 9/11 attacks our entire country changed(not for the better)
"Sic Semper Tyrannosaurus Rex."
>>looking back I realized I was too critical
It's easy to be critical; hindsight is 20/20. I think NASA goofed badly with the Challenger, both in not requiring a redesign of the joint and by launching in the cold weather. I did a report on this for which I read through the Presidential report on the disaster, and NASA goofed on both these counts and should have seen the incredible danger in both these decisions. In both, people within NASA and Thiokol were continually raising red flags over the decisions, but nothing was done.
On the other hand, the Apollo 13 incident was almost unforceable. In retrospect, it should have been prevented, since it was agin caused by a design change that wasn't throughly implemented. (It was caused by a change in voltage, causing a thermister made for the older, lower voltage to fuse shut. This then didn't turn off the heating elements, which led to the insulation on the wires inside the O2 tank to melt off. It then sparked during a cryostir.) However, the Apollo system was so complex that it's easy to see how the change was overlooked for the tanks, and it's possible to forgive NASA for it. The rest of the chain in the problem was pretty much unpreventable and unpredictable.
Apollo 1 was somewhere in between. While the problems related to the fire (the inward opening hatch, the pure O2 environment) were forgivable, the whole capsule had problems which people had been complaining about. Gus Grissom had once hung a lemon from the top of the craft to show what he felt about it. So in general, NASA should have been more through with their safety concerns.
A period in the wrong place and they steal to much money?? Who can leave that off their list?
Carpe meam simiam!
When something like this happens, it's little more than an embarassing public relations problem. If the news can't be completely supressed through advertising, perhaps it can be kept off the evening news and relegated to the back pages. It requires a well-coordinated PR firm, but hey that's what they're around for.
Sure, a few independent news agencies might pick it up and make a big deal about it - until someone goes whaling or starts cutting down redwoods. Few people pay much attention to the independent media anyway. Joe Sixpack doesn't subscribe to The Progressive.
On the local front, shut down the plant, and evacuate your American/European workers. Split them up and transfer them around. If someone makes noise, force them to sign an NDA for their severance packages. Spread liberal bribes on the local front, write the whole venture off, and wait for the hubbub to die down. If you want to stay in the region and resume operations, do so under the umbrella of a subsidiary. If it's too risky, simply relocate to another third-world region. It's not like there's a limited supply.
Unless you stay in the region, you really don't have to worry much about the local population. They're too poor to pursue legal action or be a security threat.
Besides, it's not as if they're white Christians, is it?
</sarcasm>
The quintessential book about stories like this is called "Set Phasers on Stun" by Steven M. Casey (ISBN 0963617885). If you're interested in tales of this sort, this should be your starting point.
Bottom line: that stuff about the floating point error in the PAC-2 system looks neat on paper but it's not at all clear that the faulty calculation was responsible for the loss of life.
GMD
watch this
Here are some of the best examples of windows crashing on high visibility systems that are relied upon:
in the street
At the airport
at the atm
on CNN
At disneyland
On your phone
In an airplane
At the bus stop
And why do you think that everyone should spoon feed you?
I agree! What's the point of having people spoon feeding us information like little babies when we can just go out and find it ourselves. "News" sites like Slashdot are the worst at it, "spoon feeding" us entire stories and links to relevant information. The laziness! Everyone should just pick a topic of the day when they get out of bed and proceed to Google to find all relevant information. People that research, distill, and provide useful information in an organized manner are just exaserbating the problem. Bravo to you, sir, for saying what needs to be said!
Thats not entirely true. Adding power will inccrease your altitude, but pulling up will too. When you pull up, you trade altitude for speed. In other words, youll go higher but your plane will be goins slower. Eventually you arent going fast enough to maintain level flight characteristics, so you have to add power or stop trying to go higher. In some cases youre right though, if you already are only going fast enough to maintain level flight, pulling back on the stick will slow you down and decrease your altitude, but this isnt always true. As for the person who didnt understand how adding power increased altitude, when you go faster, you increase the lift coming from your wings (since lift is a function of speed and angle of attack) so there is a net upward force on the aircraft, causing it to go upwards.
Well, if you apply more forward thrust, you increase the speed differential of the air flowing over the airfoil... Bernoulli should say that this increases your lift and so you go up.
The Mongrel Dogs Who Teach
How about this:
:-)
if altimeter1 not working
{
if altimeter2 not working
{
while (1)
{
height = 1;
while (height 99999)
{
height++;
}}}} (sorry for the bad code, but the lameness filter got me)
There, a nice spinny altimeter.
my cs teacher told me this one back in college...he said one of the first runs of the f-16 (or maybe another one of the computer controlled fighers in the air force) they were flying and everything worked just fine. however they took it across the equator and the plan flipped upside down. so the pilot corrected it and everything went back to normal. then he flys across the equator again and it flips.
so they took a close look at the software, and there was a bug in their sin function so that when they went across the equator they angle changed from positive to negative and the sin function didn't have the negative incorporated. so basically when the plane went over the equator it thouht it was upside down and corrected itself by flipping itself upside down.
i think it's a funny example of a stupid mistake possibly making a catastrophe. i've never seen this mentioned elsewhere, so i'm not to sure about this. but i do trust the cs prof who told me, before coming to my school he did a bunch of government contract work.
Was working for a small isp. Sitting at work developing a script to blank the accounts off our old mail server (outsourced) for when our new mail server is completly online and ready to go. Its done, i remove my debugging code and the limites I had placed (i had limited it to work with only 2 test accounts) Congradulating myself on a job well done I head to the hall to grab myself a coke, i come back and my boss is at my comp, now the program was written in VC++ so the 'play' button is pretty obvious and hes seen me use it before, the idiot wanted to see what i was working on and ran it, blanking all accounts off of the mail server. Took us 3 days to get the outsourceing company to restore from a backup (one of the reasons we were co-locating our own), and even then all mail recieved after the backup (the night before) was gone ofc. I just about strangled my boss, on the upside, he never touched my workstation again.
Jesus saves, everyone else takes full damage from the fireball.
Slashdot Math!
cause we all know 50 + 1 - 1 = 49!
Ok, that was lame, go ahead and mod me down...
| - | - |
of the Tacoma Narrows bridge falling. The *fault* was with the design, and hence, the designers.
An extended bolt puncturing the gas tank during a rear end collision was the *cause* of Ford Pintos exploding. The *fault* was with the design, and hence, the designers.
Both of these items could have been claimed to be perfectly free of design flaws while being used as "intended."
This argument did not help the designers in not being found liable for their design flaws.
The divide by zero error was the *cause* of the operating system's failure. The *fault* was with the operating system. The *operating system* crashed. An operating system failure is *always* the fault of the operating system, and hence, its designers.
Read any textbook on the design of operating systems and in the first page or two you find some sort of statement along the line of, " A faulty app should never cause the operating system to fail." This is correct design.
Let me repeat. If an app fails, it is the fault of the app. If the operating system fails, no matter what an app has done, it is the fault of the operating system. An operating system must *assume* apps badly written by complete incompetents.
It doesn't matter what operating system. Windows, Linux, Mac or just the beads on your abacus.
* It is the responsibiltiy of the operating system not to fail.*
The fact that such failures can be explained away as the fault of the app by people who should know better makes me grieve for the state of engineering these days. It can only result in products being produced with greater and greater "craposity" factors eventually resulting in a culture of complete "crapitude."
KFG
After all, it is better to learn from the mistakes of others than from your own, right?
Not better, but more comfortable. You will generally remember better what you learn from making your own mistakes.
Not that I would discourage your approach (or curiosity).
You're all sorta right.. here is one of my favorite aviation pages It'll tell you more than you ever wanted to know about airplane physics (from a pilot's point of view). Chapter 1 covers these altitude/speed/power concepts...
You can read about it from James Gosling's home page (also has info on Arianne 5).
Luckily the engineers were able to upload a patch to Mars. That's remote debugging/patching for you :-)
Back issues of "Communications of the ACM" are a gold mine for such blunders of the art. Most issues have a back page column "Inside Risks" that are or were written by Peter Neumann but various others have contributed. Usually each covers a theme since the subject material is so broad and seemingly unending.
"Flight instruments don't lie"
... it has an electronic AOA.
... no matter what the real AOA was.
... Fortunately, it was expensive and not lethal.
First, BEFORE YOU LEAVE THE GROUND, pilots are taught that instruments don't lie. Specifically, when the human inner ear is placed in flight, things go wrong (the inner ear canals are static, not dynamic, devices; the fluid has no dampening or rate sensors). When there is no external reference, the inner ear canals adjust to the eye's visual presentation. It's called the 'leans.' Bad joo-joo. Many a perfectly good aircraft has been flown into the ground because the pilot believed his ears and eyes and not his instruments.
Second, IN FLIGHT, angle-of-attack (AOA) is a spectacular indicator of where your airfoil exists within (or outside) the flight envelope for your aircraft. Inside the flight envelope, you can seek best range (mpg) or best endurance (loiter) or best climb.
In most aircraft, the angle-of-attack indicator is a manual instrument (on the skin is a sensor which looks like a big euro-style handle and it runs to an indicator in the cockpit).
Many pilots are correctly taught to 'fly' the angle-of-attack.
Third, ON THE GROUND, when you land, you use the aircraft shape as an airbrake. You hold the aircraft nose off the ground as long as possible to create drag.
Fourth, ON THE GROUND, when you land, you do not want to hold the aircraft nose too far off the ground or the tail will scrape the runway and your fitness report will reflect and you'll be the butt of bad jokes at Snopes for eternity.
The AOA is used to assist in the performance of aerodynmic braking. The aircraft performance manual publishes the tried and true range of AOAs for aerodynamic braking. [It also indicates when too much AOA will ding the aircraft.]
Aerodynamic braking is part art and part science and requires accurate instruments.
Enter the F-16
F-16 pilots were taught to fly the flight direction indicators to land.
However, many old and new pilots fell back on the old AOA once the wheels touched the ground to do aerodynamic braking.
Suddenly, F-16 tails were scraping along the runway at an alarming (and expensive) rate.
[As an aside, the problem was probably ignored until a senior officer ground off a few inches of aluminum THEN there was a problem.]
The programmers who wrote the AOA routines were rightly told that the AOA is used in flight. So, when the AOA detected that the aircraft had placed weight on the wheels (weight-on-wheels - WOW), it was programmed to quit working. Unfortunately, it kept the last AOA reading
Pilot flies, pilot lands, pilot believes instruments, pilot scrapes multi-million dollar aircraft's tail along runway.
The programming solution was simple: when there was WOW, fade the AOA.
This was another case when contracts pit spec wording against spec intent against functional application and understanding of how it's supposed to work
"Why did they call you 'sparky' and why are you driving school buses in North Topeka?"
Oh yeah...
At a previous job , we where having some after work drinks, and I started fking around with a RAD app we had developed for a military contract. In a fit of semi drunken bordeom we whacked in lots of pink fluffy clouds and a "my little pony" logo on the boot up screen.
Forgot to restore it.
Next morning the mil guys came in to look at how the prototype was going, and on boot up, up pops "my little pony" with all the little clouds and all. Extremely campy.
Khaki guy not impressed.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
A "large quantity of water" entered the storage tank because an employee who had just been fired dropped a hose into it out of spite (he didnt know what would happen, he just wanted to ruin something). Yes the safety precautions were under-par, but when someone with legitimate access wants to destroy something its pretty hard to prevent.
:).
And yes, this has nothing to do with programming error
Ok.. I remember reading that one in the paper as US military guys that where being shown the system by ADI (Australian Defence Industries). I also remember nearly falling off my chair laughing.
You may be right tho. Fsking funny.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Perhaps the Y2K problem passed without incident exactly because of these fixes. There was software that remembered the data as only two digits, and some of it did need to keep track of the entire year, though the "19" was assumed.
We will probably never know.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
My college program involved several co-op workterms, in which students would be placed in paying jobs as part of their education. One of our teachers regaled us with stories of co-op placements gone bad. In one case, a student at the local lottery office (where the prof used to work) apparently sat on a keyboard and apparently managed to butt-type a sequence of keys that knocked out the lottery system for awhile across the province (apparently while trying to flirt with a female co-workers).
From what I remember, he was blacklisted for quite a while with local employers, probably didn't get a date from the female co-worker either...
The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.
-- Nathaniel Borenstein
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
unless your pointing at the ground. an if you've even been in an acrobatic plane (such as a jet fighter) then you'll know it's oftern extremely hard to know intuitively which way is up - especially when you're in the clouds.
Could we have a new Slashdot category entitled Ask Slashdot To Do My Research/Homework For Me? Then I could mark this category unread and avoid some annoyance.
There is so much information readily available on the subject of software failures online and in scientific and popular publications. (See other responses to this question for examples.) IMHO, the questioner should go look for the answer to this kind of question directly before bugging the entire Slashdot audience; the editors should enforce this policy.
The system did not collapse per se but progressively became bogged down by a series of poor design issues and implementation issues.
What happened was there was a memory leak, in that not all the memory used when a call was processed was released. This meant that each call chewed up a small part of core.
As the day wore on, this loss of memory started to make the system run slower, and created more calls as users started to worry about the non-show of the ambulance.
Meanwhile, back at the control centre, the operators started getting blasted by messages about over-due ambulances, and other system warnings. They were spending time simply dismissing Error dialogues.
By the end of the day, they were still dealing with the emergency issues notified at 12.00.
Of course, in the inquiry, there were many different management and design issues to be addressed, including the reliability and scalability of the software. [It was a Visual Basic program.]
I have seen a number of instances personally, most of these tend to be ignored by management keen to see the system up and running. The most often case for dismissal of problems is "teething problems", and "Luditism".
In practice, the real issue here is the UI. Not so much "flash chrome", but that the buttons and so forth will actually do what the user expects them to do. The user must be able to understand how to process and correct errors in relation to the application data itself. That is, if I enter 1200, and I mean 1130, I should be able to correct that.
The other disaster happening out there is that the program must be useful to the operator. So apart from entering data, the operator must be able to extract useful information from it. What the back end does does not really matter.
For example, a clerk who has to enter data on the screen each sale, in addition to operating the till, would be reluctant to use it. On the other hande, if the program is part of the till operation, and it provides information on how much stock is left, the clerk is more accepting of the change.
Implementing a system is not about plonking a pc with a program on a user's desk. It's about a user process. Users are looking for outcomes, not process. So if you want to go to a shop, you want to buy something, and the clerk wants to sell it to you. All the rest is administrivia.
Software design is important. So is user training.
OS/2 - because choice is a terrible thing to waste.
I think I've recommended this book serveral times on Slashdot. Simply put, THE collection of computing related horror stories.
2 01 55805X/qid=1035769692/sr=8-13/ref=sr_8_13/104-4078 673-1863905?v=glance&n=507846
http://www.amazon.com/exec/obidos/tg/detail/-/0
I swear by MacOS X. Although I use to swear *at* MacOS 9...
The NT crash brought down every other NT box on the ship, not good news on a ship powered entirely by NT, is it? (-:
I have a friend (who still works for IBM) who was learning to program on mainframes, ran his app, killed it after 2.5 seconds, and went down to collect his print run. One and a half boxes of paper. He thought that was expensive... but consider running an app on your smartship while it's manouvering in close quarters, and bringing down NT. One and a half boxes of sailors. A bit expensive...
Got time? Spend some of it coding or testing
It must also be expecting programs written by incomplete incompetents, ie, people who are clever enough to get most of the coding right, then put in a weird twist on the last call that guts the OS. Programs writen by complete incompetents are often disqualified (GPF) before they get so far.
Got time? Spend some of it coding or testing
I did run acroess that title, but for some reason I did not read it. It's very possible that no local libraries had a copy (in fact, a run of Penn State's library search engine yields no results, so this was almost certianly the case). As it was not a huge paper in general (just for a high school class, albeit a *major* paper for high school), I didn't feel compelled to go looking for tons of secondary sources when Penn State had the Commission's Report. As this report is the basis for most of the information out there on the Challenger, it was by far and away my biggest source.
/.ers is Richard Feynman's "What Do You Care What Other People Think?" Feynman was one of the members of the commission that investigated the accident, and he gives his story in the second half of the book. Feynman is a fun guy and the book is a very good and easy read.
One book that may be of particular interest to
In general, there are certain sacrifices that you have to make in terms of safety. Having to cart a one-piece booster just wouldn't have worked, period. This is especially true at that time because NASA was running another launch pad in Califiornia at an Air Force base (I forget which, and also forget if it was ever used) in addition to the one at Cape Canaveral. I suspect a barge in that case would have necessitated a trip all the way through the Panama canal to get between the launch sites. My point is that you can't always take the safest option. However, that doesn't mean you ignore blantant safety issues. NASA was negligant in its inaction concerning a joint redesign. (And this is true legally as well as IMHO; the families of the astronauts I believe got a fairly substantial amount of money in a wrongful death suit, though I forget if it was settled out of court.) The decision to launch in cold weather was, in my mind, far secondary to the lack of any progress regarding the design of the joint.
If anyone is curious, my report is online as a PDF and HTML. The PDF version has a couple more pages that I didn't splice into the HTML file, including a VERY interesting and revealing memo starting on page 40. Try to ignore the numerous technical errors (I have a couple dozen typos and horrible tense consistancy). I wish that I had had the time to proofread it, but it was too long for the time I had avaliable. But I don't think ym teacher bothered to read it anyway, because he made no comments on it.
-----rhad
Slashdot needs to interview Natalie Portman.
From the Pacific Northwest, home of "innovative" approaches to software reliability, comes:
3 4563661_ship27m.html
...
http://seattletimes.nwsource.com/html/localnews/1
"Officials could not say for certain what caused the ship to heel, but they think the ballast system was probably at fault. A malfunction became evident about 3:30 a.m., when the 653-foot ship started to tilt. The crew was evacuated and no one was hurt.
The ship, in operation since June, has an automated ballast system that adjusts water levels in 28 compartments to keep it righted on the high seas."
Kind of frightening - wonder if the crew even knows how to do a manual override. (Also weird that evacuating the upper port balast chamber would cause it to list to port...)
If the Y2k bugs hadn't been fixed, things would have broken left and right, and we would have been blamed for not fixing them ahead of time.
Since the Y2k bugs were fixed, very few things broke, and we got blamed for wasting tons of money to no effect.
C'est la vie, I guess.
At a place I used to work, they made burglar alarms. One burglar alarm, the "8112", had a feature where you could lock out sensors so they would not report. This had two possible uses: the alarm company could lock out a defective sensor, or the alarm company could lock out all sensors if the customer wasn't paying the alarm bills.
Anyway, there were 8 possible sensor "zones", and there was a byte that could lock out any or all of them. You set a bit, one zone was locked out.
An upgraded version of the 8112 came out, where you could replace two of the 8 zones with serial data loops, and you could have over 100 individually reporting sensors instead of 8. This optional feature was called "Zonex" (for "Zone expander" or something like that). For no good reason, when Zonex was running, the sense of the lockout bits was reversed: instead of being lockout bits, they became enable bits.
I want to emphasize this. If Zonex was running, you had to set all the bits; otherwise you had to clear all the bits.
So the setup software knew to check the Zonex bit, and set up the lockout byte accordingly.
This worked great until a new version of the 8112 came out where Zonex was always running, whether or not the Zonex bit was set. If the user didn't happen to set the Zonex bit when setting up that version of the 8112, the burglar alarm would silently ignore all the sensors. Eeeek!
Once we figured that out, we added a check for the version of the 8112 and all was well again with the setup software.
The moral of this story is: don't randomly invert the sense of settings!
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
From my Software Engineering textbook (author: Vliet if you're interested), a few references you might like: - http://www.csl.sri.com/users/neumann/neumann-book. html
- http://www.rothstein.com/slbooks/sl296.htm
Also, you might like:
"Design Paradigms: Case Histories of Error and Judgment in Engineering" by H. Petroski (not restricted to Software Eng)
Enjoy,
Rod
"I respect faith but doubt is what gets you an education." --who knows
The RISKS mailing list (aka comp.risks on usenet) deals with this topic quite thoroughly. Go forth and read this fine forum on risks to the public through computers and related systems. Learn about the problems faced by planes, trains, automobiles, banks, websites, electronic voting machines and more.
On a slightly different tack - the
Sleipner A oil platform sank because of a bad design, caused by inaccurate computer based modelling (using an FEA tool inappropriately). In this case it was the data not the software.
Hang on... My win98 box already does that! And to think, I critisise mircrosoft for shody coding!
Come to think of it... I wondered what that big rectangular prismatic monilith was doing next to my box, next thing I know it will become a star child.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
Just remember that if (a = b) is not the same as if (a == b)... Every time I write that wrong it takes me hours to find the damn bug, cause it might not appear immediately.
The SAAB JAS-39 Griffon crash you mention was in fact caused by the pilot not being warned about "pilot induced oscillations" (though there was a crash in testing that was attributed to the control systems). Basically, the plane started to weer left, the pilot quickly compensated as did the control system, leading to overcompensation. So, the pilot compensated back the other way, as did the plane...
Rinse, lather, repeat. End result: plane rears up, suffer complete loss of air speed, falls like a brick into a crowd of about 200 000 spectators (this was an airshow over central Stockholm!), and through divine intervention happens to hit to one empty spot in a sea of people.
Interesting fact 1: footage shows the plane stabilizing back down into a correct flight attitude once the pilot ejected. Not much use without airspeed, though.
Interesting fact 2: SAABs division for Flight Control (presumably the same guys who did the Griffon control systems) also programmed the flight control systems for the Ariadne...
Interesting (or at least humurous) fact 3: This is the monument marking the spot where JAS crashed.
I choose to remain celibate, like my father and his father before him.
Bottom line: that stuff about the floating point error in the PAC-2 system looks neat on paper but it's not at all clear that the faulty calculation was responsible for the loss of life.
Dead on! There's been loads of evidence that NONE of the patriots EVER hit a signle scud. Luckily the scuds had problems of their own with some wing design when going neg-G or something,
I can't remember what it was, but anyway quite often they just simply blew up when decending towards a target.
Even I remember Bush the elder boasting (numbers may be inaccurate, but gap was 1) "37 missiles engaged, 36 intercepted". Naturally that raised a few questions about what was this "intercepted" as none of the Patriots ever hit a scud. And...
I saw this rather hillarious documentary about
all this Patriot fuzz where some US general telling in court what they ment with "intercepted". He said that "intercepted" meant only that at SOME point the patriot's flight path / trajectory crosses that of the scud's.
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
That's fucking cool. Any more information?
--Giving to trolls for the benefit of us all
My university used to offer distance learning for computers. The students would post their programs in, secretaries would type them in, and the listings of compiler errors would be posted back to the students. At 2-3 weeks turnaround, the students were inclined to think before coding a bit more, and hoped the typists were good... Soon after I left, the university made having access to a PC a requirement for the course, taking all the fun out of it :-)
Of course they didn't. The patriot was specifically designed to detonate itself CLOSE TO the offending missile and, hopefully, in the process destroy the latter. This is, in fact, what happened: Tel Aviv and surrounding areas were rained on by falling scud parts. These were pieces of the scuds intercepted by the Patriots.
The problem of intercepting a moving target is difficult, but it becomes much easier when the goal is to simply get "near enough" to disable it with an explosion.
... is whot bwings os tugevza tsuzay.
Almost a decade ago when I worked for a differect credit card company that shall remain nameless, a member of my team (I was the lead) introduced a defect that was responsible for about $40K is mis-applied credits. I am not sure whether we ever got the money back.
The program was written in C, and he had changed a do-while loop to a for loop, in editing he had kept the line that contained the original condition (including the trailing semicolon). As many of you C-ers out there are aware, a semicolon following a for() statement will not execute the subsequent code block in the loop!
A very memorable lesson in the value of lint and thorough regression testing!
This may not qualify as a disaster, but I distinctly remember having to give an account for the defect to the corporate controller with an aufience of grand and exalted poobahs. She was a very intolerant and technically ignorant person that actually intimated that this had been done maliciously.
KK4SFV
CDE
:)
Cheers
Sigh... If someone is going to rip all the pictures, I wish they'd at least give proper attribution. Visit http://www.windowscrash.com for the original collection. I always give attribution.
Indeed, there was a *slew* (pun intended) of timing problems with the initial software to run the shuttles (does anyone else remember the frequency of early launches scrubbed due to software?). From my understanding, the bugs were traced to race conditions amongst the (then large) array of onboard and ground computers.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Hey we sold you this! Top of the range! But it's broken, even before we sold it to you. If you pay us £500000 we'll fix them all, but if you don't your blood will boil and your head will explode, all your kids will die of pestilence, your wife will sleep around, your plane will try to reach the moon and all your elevators are belong to us.
Careful. Quoting from a Microsoft EULA like that without proper attribution could get you tossed into jail for a DMCA violation, sport.
In talking with programmers and fighter pilots at Hill AFB, I learned that the pilots usually have to restart some computer systems several times every flight.
frob.
//TODO: Think of witty sig statement
Check out http://ask.slashdot.org/article.pl?sid=01/10/31/19 27246&mode=thread&tid=156 for this same discussion with an emphasis on embedded computing.
"Prepare for the worst - hope for the best."
Female Prison Rape in NY