I have now posted the slides from my keynote talk at the S4D 2011 conference to the presentations list on my regular home page. The topic of that talk was “System-Level Debug”, something which has started to interest me in recent years.
Essentially, as the (embedded) software systems we are developing get more and more complex, we need to update our debuggers to keep up with the times. This means moving beyond looking at single processors, threads, programs, or even nodes – and making debuggers that support working with multiple contexts at once. For example, debugging a couple of different boards in a rack from a single debug session. This would mean supporting multiple processor architectures, execution modes, and operating systems inside a single debugger session. Debuggers need to orient themselves towards handling software that is already running in a target, rather than starting the target software. The debugger becomes more of a passive observer of the target system than an active component.
Take a look!
Once a defect/bug is discovered you will have to fix/change the code, recompile and rerun.
You repeat these steps until no more misbehavior is perceived.
The more code you wrote the more less errors are in your first release.
One more thing : the correct behavior is mainly know to the software design team ; what can be perceived as a bug could have been an as-it-is feature.
Also sometimes is hardware which malfunctions due to environment factors ( temperature , moisture, oldage ).
I recently shopped around for an SSD drive. The MTBF published by the manufacturer is 2 million hours. That in years is 250.
250 continuous usage years! You need to keep it inside the functional envelope though otherwise it will eventually break suddenly and/or sooner.
In conclusion : once software is groomed and bug free it will run almost forever.