John Smith <JS****@mail.net> wrote:
Are you aware of a case where a software error or undefined
behavior caused actual physical damage to hardware?
Yes. The most common example is early PCs that used a combination of
hardware and software to generate their video output signals. Incorrect
code and/or data could result in wildly out-of-spec video signals that
would damage (possibly spectacularly) the monitors of the time, which
were not protected against such abuse.
Another example I am personally familiar with was a graphics computer
where the assembly language was more like microcode -- there were no op
codes, per se, rather the bits in the instruction specified the source
and destination of the data, the logical operation to perform on the
source and target data (assign, negate, AND, OR, XOR), an optional
rotation to be performed, etc. The standard calling conventions for the
system had argument lists inline with the code, so a call to a
subroutine consisted of the call instruction, followed by the first
argument, the second argument, etc., then the next instruction to be
executed on return from the subroutine. There was no argument count, so
variable length argument lists were, by convention, terminated by a word
with all bits set.
There was a bug in one of the standard libraries that resulted in
variable argument subroutines returning to the all ones terminator
rather than the following instruction as it should. An instruction with
all bits set was not a well-defined operation, it truely resulted in
undefined behavior, although the bit mapped nature of the instructions
made it fairly obvious what should happen. The result was mostly
innocuous, although it did have the potentially "interesting" side
effect of incrementing the very last word in memory. However, because
that particular combination of operations was not useful (hence the lack
of a defined instruction), it had never been tested, and it resulted in
a short-circuit in the processor. Since the short circuit only existed
for the duration of the instruction execution, it was not immediately
fatal, but if it happend frequently enough, it would eventually cause a
transistor to overheat and fail. It took years to figure out why one
particular transistor on one particular card in the processor had an
abnormally high failure rate.
-Larry Jones
My dreams are getting way too literal. -- Calvin
