Can we guarantee a program will never go wrong?

Question

We have a system here. Recently there is a wrong calculation in one of the number in the report generated by the system. Through out our experience, we've never encounter any problem/error in this system for some years.

Because the writer of this system had already gone, we can hardly trace the programs. But we've verify the input data, the setting and they are right.

Now my question is, will a computer program suddenly go wrong without any logical reason? If I slam on the server machine, will one of the number which the computer is calculating, become another number and make the calculation wrong?

I agree my idea there is quite mad, but I just want to know, how can we know the problem is not caused by the program and the input, but some other factors?

P.S. This mad system has no log.

Answer 1

I would say no!

In theory the answer is no, we can only test for:-

• some limited number of environments.
• some limited number of timescales.
• some limited number of test cases.

This is considerably less than the total possible number of environments, times and cases the program may encounter in its lifetime. Also we have little knowledge of the future should you program cope with 10,000% inflation, should your program cope with a super duper new 31 bit architecture?

The theory is supported by experience I personally have encountered:-

• Programs breaking when moved to a different locale. Checking for "MAY" when the month was "MAI".
• Programs failing tests on a new version of the compiler, A bug in the previous version in conjunction with a bug in the program produced the correct result.
• Programs breaking on a new release of the OS. When Solaris increased the default number of directory entries the SMALLINT returned by ftok() always returned zero for the first file in the directory.
• programs breaking because it was the first time they encountered a particular combination of inputs, which were both valid and unexpected and would never have been tested for -- negative interest rates on deposits, zero weight items to be shipped, items of such low value that VAT couldn't be calculated etc. etc.

Answer 2

In theory, if you start with identical state, the result will be identical. In reality, assuring identical initial state in "server sized" equipment is pretty much impossible.

Take uninitialized variables. Look at this code:

  short i;

  if(i==-1)
  {
        //do something special
  }
  else
  {
        i=0;
        //do something else
  }

This will produce unexpected results once in 65536 runs. And unless you assure memory will be in the same state before each run, i will be entirely random.

There are hundreds similar ways for errors to pop up following unpredictable elements of the initial state someone forgot to override, or border cases that happen rarely - race conditions in multi-threaded environment, out of bounds array access, disk IO on corrupted filesystem, and so on.

If you can prove the program is bug-free, there's only the cosmic rays that can break it. But mathematical proof of correctness of anything more complex than two nested loops is pretty much beyond scope of the biggest systems (and costs a small fortune), and for all the rest you can only hope.

Answer 3

Now my question is, will a computer program suddenly go wrong without any logical reason?

If you have the same computing environment exactly, then given an input X to a program will always produce the same result R. In practice, it is seldom to have a single program executing in isolation. The simplest application today runs in an operating system and shares memory with other programs that may be 'loaded' in memory at the same time. These programs may alter the memory in a way that makes a given program malfunctions. This is a famous problem with variables of type 'pointer' for example. Usually such errors cause abnormal system behaviors and not wrong calculation results.

In your case, I assume that the problem may be (and usually is) not what I have described above. The problem may be that:

• the program used the wrong datatype(s) to calculate the result, that error only manifests itself when special values are used.
• the program encountered an error in calculation (due to a logical condition) but did not handle the error and still produced the result. (e.g. mixing float and integer arithmetic)
• a business rule or a logical condition was not coded correctly, the data that was entered represents this condition but the wrong calculation was used. (e.g. subtract amount from account amount before checking the amount in the account first).
• using formulas that apply only to certain range of numbers but the data contains different range. (e.g. calculating an interest rate based on a range of values)

Because of the above and many other reasons software people spend so much resources in an attempt to create correct software, however, software errors still occur, but the errors are 'logical' and have a reason, it is just that the reason is not obvious to some without good research. So, in general tested software is predictable and does not produce random results. Due to the complexity of some programs, and other factors, even tested programs can go wrong but when that happens, errors are for a logical reason.

If I slam on the server machine, will one of the number which the computer is calculating, become another number and make the calculation wrong?

The answer is no in general, software is not fragile in that sense.

What you can do is isolate the cases where the error is occurring, find the similarity between these sets of data causing the error and find the difference between theses sets and the other sets that produce the correct result. You may be able to identify the specific set of values causing the problem. For example you may find that every time a variable has a negative value, the result is wrong.

Updated information about memory corruption errors: Please see Memory Corruption

Answer 4

Can you guarantee a program has no bugs and will never go wrong? No, unfortunately not.

Can you demonstrate that a program has a sufficiently small number of bugs that the cost of finding and fixing them far exceeds the benefit from that action? It sounds to me like you already have.

To paraphrase an old statistics maxim, all programs are wrong, but some programs are useful.

Answer 5

I'm inclined to say no, you cannot prove that a program will never go wrong or provide an incorrect result, even if you can assume perfect input.

Raku mentioned formal proof of correctness. That's one thing to consider, but unless I'm completely mistaken, that will still have to assume a perfect execution environment. So, with some amount of time and effort, you can perhaps prove that the program is correct, but that does not necessarily prove that it will always produce the correct results, even given perfect input. The execution environment matters. And I would be wary of assuming that the input is always perfect, either.

This is why, in certain high-availability situations, multiple, completely independent implementations and execution environments are used, and the results are compared to make sure that they are within an acceptable margin of error from each other. In some situations, that margin may very well be zero. Even back in the 1960s, this was deemed important enough to include separate sets of computing hardware in spacecraft. Even if an errant static discharge, cosmic ray or whatever were to affect both computers simultaneously, the odds that both would be affected in the same way (particularly if they are both still working and producing valid-looking results) are miniscule. The odds of the same bug creeping into two completely separate implementations are also extremely small. And so on.

Answer 6

Most (standard) computing is deterministic, I would think.

If possible, set it up to do a batch of 1000 or 10000, etc., iterations with the same input data, and verify that the results come out the same.

Make sure the current values going into the calculation would cause an over- or underflow anywhere (if it is an older system it may not have been intended to be used this long).

Y2K11 anyone?

Answer 7

Testing shows the presence, not the absence of bugs (Edsger W. Dijkstra)

If you're trying to prove that your program works correctly by testing, it won't work.

However, there some approaches in theoretical computer science where you develop a formal proof of the software you have written. Depending on the complexity of your system, this can be a tedious process though. If your system, however, works on a restricted set of commands, you could be successful with this approach.

Answer 8

Unless you can control every single bit in the machine, and every bit of electrical impulse flowing through the circuitry, then you cannot guarantee with absolute certainty that something will not go wrong with your program. Memory modules fail, CPUs can overheat and introduce errors, hard drives can scramble data, and power supplies can introduce noise into the system. The more expensive the hardware, and the more redundant the hardware, the less likely these things will occur, but at some point hardware can fail.

Then you have the operating system, with bugs that can be tickled by the most arcane means imaginable. Compilers may also have obscure bugs just waiting to deftly turn your pristine code into hard-to-trace bugs. It's a jungle out there, and your poor software is vulnerable to all of this. LOOK OUT!

And in my experience, more often than not, whenever there's a bug in a calculation, we never have to dig nearly that far to find the culprit. Generally speaking almost all bugs I've seen in the corporate world are easily found with the right debugging tools, and some elbow-grease.

In other words, while the hardware and OS might not be perfect, you'll likely never have to worry about that level of detail. Just find someone who knows the language, and is handy with a debugger, and dig in.

"simpler explanations are, other things being equal, generally better than more complex ones." -- Summarization of Occam's Razor.

Answer 9

Yes, hitting a system could bend and/or move parts enough to cause a temporary open-circuit (or possibly short-circuit, though it's probably less likely).

Answer 10

The first computer I owned was an Altair 8080 with 256 Bytes of memory. Input was from console switches and output was from a few blinking lights. If you disallow cosmic rays and hardware failures, I believe I could prove that some programs I ran on it would always produce the same results.

Since then, no.

Answer 11

Hardware and software environments are in a constant state of flux. Moving parts, electricity, , temperature, dust, and OS code changes are examples.

Therefore I do not think it is even probable or expected that a computer software program will always behave the same since the environment is always changing.

Software can run for a long time as expected , but eventually either a small change to the host OS software will change which would effect the program in question or the hardware will value.

I am talking about current day computers.

Answer 12

Now my question is, will a computer program suddenly go wrong without any logical reason? If I slam on the server machine, will one of the number which the computer is calculating, become another number and make the calculation wrong?

The answer to that question is unknowable. It is impossible to prove that anything is always true of the universe we happen to live in. Instead we make assumptions and prove that if the assumptions hold, then some complicated property will also hold. This is what formally verified programs guarantee. Most programs are not formally verified though, they instead try to build confidence by providing tests. These tests give you assurance that provided the tests do what they were designed to do and that the assumptions that you've made hold, the program you are using will work at least some of the time.

Answer 13

Absolutely not. You can never be 100% sure that a system will never fail.

If you want your system to be as correct as possible, give a try to Formal Verfication

But let's say that your program is formally verified to the last extent possible. You can still suffer from hardware failure. Let's say you prepare multiple redundant hardware to run you program and make the software completely fault tolerant. You can still suffer from radiation. Let's say you prepare multiple reduntant, radiation proof, hardware. You could still have accidents. Let's say you put your hardware in an impossibly secure facility (not the italics, because I'm talking about an impossible level of security). Well, things will go wrong eventually, because there is one thing in the universe that rules EVERTYTHING: entropy.

Even if you hardware uses an internal, infinite power source, and even if it survives to the day that sun gets large and eats the earth, after some time, the very atoms of your machines will just fade away and your system will inevitably fail.

You lose. FOREVER.

Answer 14

It is just barely possible that the problem is caused by failing RAM, but this is relatively (very) unlikely. Run a memory test, but be ready to look through code.