3 ms·

> In most languages I've used you get a division by zero error or NaN Or it raises an exception, which once disabled a navy warship for hours: > Now decommiss

by FabHK 5y ago

> In most languages I've used you get a division by zero error or NaN Or it raises an exception, which once disabled a navy warship for hours: > Now decommissioned, the USS Yorktown was among the first warhips extensively computerized to reduce crew (by 10% to 374) and costs (by $2.8 million per year). > On 21 Sept. 1997, the Yorktown was maneuvering off the coast of Cape Charles, VA, when a crewman accidentally ENTERed a blank field into a data base. The blank was treated as a zero and caused a Divide-by-Zero Exception which the data-base program could not handle. It aborted to the operating system, Microsoft Windows NT 4.0, which crashed, bringing down all the ship’s LAN consoles and miniature remote terminals. > The Yorktown was paralyzed for 2 3/4 hours, unable to control steering, engines or weapons, until the operating system had been re-booted. Fortunately the Yorktown was not in combat nor in crowded shipping lanes. > If IEEE 754’s default had been in force, the division by zero would have insinuated into the data-base an ∞ and/or NaN, which would have been detected afterwards without a crash. http://people.eecs.berkeley.edu/~wkahan/Boulder.pdf http://people.eecs.berkeley.edu/~wkahan/Boulder.pdf https://www.wired.com/1998/07/sunk-by-windows-nt/ https://www.wired.com/1998/07/sunk-by-windows-nt/ EDIT: It was 2 3/4 hours, not 23 hours. I copied/pasted carelessly from the PDF.

da_chicken 5y ago
Eh, there's like six separate issues that led to this. 1. Interface accepted blank value for a form when a numeric value is required. 2. Application and database permitted a null or coerced a zero when the value is required and cannot be zero. You've got to sanitize your input. 3. Application did not check for or gracefully handle something as common as a division by zero exception. Instead it proceeded to a buffer overrun and crashed. 4. Application crashing apparently caused an OS crash? Yes, okay, it's NT 4.0 and a buffer overrun, but that still should not happen. Protected mode is a thing. 5. There is no redundancy in a system that manages the steering, weapons, and engines of a warship. 6. A warship was unable to restore the single CNC system to working order for 23 hours. Furthermore... there's no evidence that the software would have behaved more sensibly or more controllably if it had a value of infinity instead of an error. It shouldn't have had a zero in the first place.

by FabHK 5y ago

da_chicken 5y ago

Eh, there's like six separate issues that led to this. 1. Interface accepted blank value for a form when a numeric value is required. 2. Application and database permitted a null or coerced a zero when the value is required and cannot be zero. You've got to sanitize your input. 3. Application did not check for or gracefully handle something as common as a division by zero exception. Instead it proceeded to a buffer overrun and crashed. 4. Application crashing apparently caused an OS crash? Yes, okay, it's NT 4.0 and a buffer overrun, but that still should not happen. Protected mode is a thing. 5. There is no redundancy in a system that manages the steering, weapons, and engines of a warship. 6. A warship was unable to restore the single CNC system to working order for 23 hours. Furthermore... there's no evidence that the software would have behaved more sensibly or more controllably if it had a value of infinity instead of an error. It shouldn't have had a zero in the first place.