Software Defect Tracking

But it went through rigorous DO-178 Class A process. Doesn't that mean it's bug-free?

[/facetious]

I find it even more scary that redundant control systems are sharing code. That was supposed to be forbidden, back to the Apollo program.
 
It could have been written in Chinese and I'd still have about the same comprehension.
 
I always thought that was forbidden also. If these are the General Flight Computers, they all didn't even run the same OS, did they? Something seems weird here. Like this particular portion of the code broke some very deep basic rules of the Shuttle's computer use model. They also weren't supposed to be coded by the same team, even. I'm having a hard time figuring out which "four" computers he's talking about. (There were five main computers on board, I thought.)

I'm fuzzy today... I'll have to look into this later.
 
Sac Arrow said:
It could have been written in Chinese and I'd still have about the same comprehension.
Click to expand...

Initialization of counters works something like this:
Start with Step1
Step 1 Open the fuel valve.
Step 2 Watch fuel drop from the sky.
Step 3 Close the fuel valve.
​
Now, having gone through the steps once, you now want to go through them again. But you forget to reset to Step 1. So now, your computer program is looking for Step 4. There is no step 4, so it is hunting around in all of its storage drawers for Step 4. Meantime, nothing else is happening because it cannot find Step 4 and is going around like a demented monkey trying to find Step 4.
 
Ah, operating systems written in Fortran-66 spaghetti....

Some of the code written before structured programming looks both unfamiliar and thoroughly frightening to the modern eye.

Want even more scary thoughts? IBM wrote the code for the SAGE project using techniques like that. A bug in the space shuttle kills seven people. A bug in detection of incoming Soviet nuclear bombers is a bit more serious.
 
MAKG1 said:
But it went through rigorous DO-178 Class A process. Doesn't that mean it's bug-free?

[/facetious]

I find it even more scary that redundant control systems are sharing code. That was supposed to be forbidden, back to the Apollo program.
Click to expand...

No such thing as a DO-178 Class A process.
 
Did anyone notice the date: "
Communications of the ACM 27(9), September 1984"
 
Want to find a bug? Look in IF statements. Bugs hide in IF statements. Better yet, look inside the ELSE clause. If there is no ELSE clause, a bug is sure to be there.
 
Bob Noel said:
Did anyone notice the date: "
Communications of the ACM 27(9), September 1984"
Click to expand...

What's the significance? That was two years before the Challenger explosion. And that wasn't a software fault. And it was three years after STS-1.
 
AuntPeggy said:
Want to find a bug? Look in IF statements. Bugs hide in IF statements. Better yet, look inside the ELSE clause. If there is no ELSE clause, a bug is sure to be there.
Click to expand...

My favorite C bug looks like

if (cond);
func();

How many of us have done that at one point or another?
 
MAKG1 said:
My favorite C bug looks like

if (cond);
func();

How many of us have done that at one point or another?
Click to expand...
Once I had a new manager ask me what was my most common mistake. When I said "semi-colons" he told me I was mistaken. "Everyone's most common mistake is with pointers," he stated. No, that only took six months to master.
 
Capt. Geoffrey Thorpe said:
Computed GoTo? :hairraise:

With no clipping? :hairraise:

People were flying on this ****? :hairraise:
Click to expand...

My thought too.

And what I don't want to think about is whether or not anything in my airplane is running similar code.

I write code for a living. I know what happens...
 
I work in hardware, but even I know better than to code a goto into anything more important than a video game. Jeeeeeeezzzzzzz....
 
SCCutler said:
Since I am not C-aware (and have not programmed in a Very Long Time), please explain the error. I assume it is basic syntax.

Thanks!
Click to expand...

The semi-colon after the if statement ends the statement inline with no content. If the intention is to have func(); run only if the condition is satisfied, it should look like

Code: 
if(cond)
{
     func();
}

As it is, func(); will always run, regardless of the condition.

This is not actually a mistake I make often. I tend towards simple typos. That or the "Oh ****" moment when you realize your entire algorithm has one subtle but critical flaw and needs to be entirely re-worked.
 
SCCutler said:
Since I am not C-aware (and have not programmed in a Very Long Time), please explain the error. I assume it is basic syntax.

Thanks!
Click to expand...
The semi-colon after if(cond) ends the IF statement. So, the next statement, func() will be executed whether the IF is True or False. One assumes that the programmer intended for it to only execute when cond is True. If so, he should have left off the semi-colon.

if (cond)
func();

​
 
And there is also the time-honored:

If ( a=b )
func();
​
In this case, the programmer is setting the value of a to the value of b instead of comparing them. And func() will always be executed. If he wants to compare the two and only execute func() when they are already equal, this is what it should be.
If ( a==b )
func();
​
 
bluesky74656 said:
The semi-colon after the if statement ends the statement inline with no content. If the intention is to have func(); run only if the condition is satisfied, it should look like

Code: 
if(cond)
{
     func();
}
As it is, func(); will always run, regardless of the condition.

This is not actually a mistake I make often. I tend towards simple typos. That or the "Oh ****" moment when you realize your entire algorithm has one subtle but critical flaw and needs to be entirely re-worked.
Click to expand...

BTDT. The off-by-one error in my trajectory generator that made it unstable was a real SOB to find.

There have been precedents for Fortran typos generating wrong answers. By default, Fortran makes a new variable for you with value 0. And older Fortran had only six significant characters in variable names, so they tended to look like "IGAF01"
 
bluesky74656 said:
The semi-colon after the if statement ends the statement inline with no content. If the intention is to have func(); run only if the condition is satisfied, it should look like

Code: 
if(cond)
{
     func();
}

As it is, func(); will always run, regardless of the condition.

This is not actually a mistake I make often. I tend towards simple typos. That or the "Oh ****" moment when you realize your entire algorithm has one subtle but critical flaw and needs to be entirely re-worked.
Click to expand...

AuntPeggy said:
The semi-colon after if(cond) ends the IF statement. So, the next statement, func() will be executed whether the IF is True or False. One assumes that the programmer intended for it to only execute when cond is True. If so, he should have left off the semi-colon.

if (cond)
func();

​
Click to expand...

It works in PHP. If you do an if statement without curly brackets it will apply to the next line of code. I've never liked it..and programmers that use it drive me insane but it does work:
Code: 
<?php
if(1==1)
echo 'hello'.PHP_EOL;
echo 'bye'.PHP_EOL;


if(1==2)
echo 'air'.PHP_EOL;
echo 'plane'.PHP_EOL;
?>
Will output:
hello
bye
plane
Click to expand...
 
Ah yes, writing code... Takes me back to my plant engineering days and writing machine language code for PDP-8S 12 bit machines - and later on 11's Then we really upscaled in the early 70's with CAI 16 bit machines, paper tape readers for inputting code, and (gasp) the very first display screens just as I bailed out and went to med school.. I had a programmer working for me at that time, when he would get his pay check (just before lunch) he would eat his sandwich while double checking the arithmetic on his check stub using a grease pencil on the Formica table top - in binary... Of course, we used hexadecimal for calculating memory addresses... After ten or eleven hours of writing strings of machine code with imbedded binary and hex numbers by the time you went home you would be lucky to be able to walk and chew gum simultaneously... Were there logic errors as you balanced Boolean logic with binary and hex number branching instructions? Does the bear cop in the buckwheat?
 
docmirror said:
I work in hardware, but even I know better than to code a goto into anything more important than a video game. Jeeeeeeezzzzzzz....
Click to expand...

Before structured programming in the mid-70s, that's the way EVERYTHING was done.

Having worked with some code from the period, I find it astonishing that anything worked. FORTRAN-66 and earlier didn't even have an ELSE statement and ENDIF took up a whole extra punch card, so almost all conditionals were of the form "IF (N1.EQ.N2) GOTO 100" followed by the "else" logic, then the "100."

I do not miss that kind of code.:vomit:
 
MAKG1 said:
Umm, yes there is. Design assurance levels are categorized from A (failures are catastrophic) to E (trivial).
Click to expand...

I should have put a smiley in there and/or a nitpicking alert.

DO-178B has levels A through E... and DO-178B didn't come out until well after the article was written (1992 vs 1984).

DO-178 had levels 1, 2, 3 (iirc), but definitely didn't have A - E.
 
MAKG1 said:
Before structured programming in the mid-70s, that's the way EVERYTHING was done.

Having worked with some code from the period, I find it astonishing that anything worked. FORTRAN-66 and earlier didn't even have an ELSE statement and ENDIF took up a whole extra punch card, so almost all conditionals were of the form "IF (N1.EQ.N2) GOTO 100" followed by the "else" logic, then the "100."

I do not miss that kind of code.:vomit:
Click to expand...

Well, like I said, I'm a hardware guy, but I can remember from my few classes in Fortran that it supported the CALL, RETURN, and SUBROUTINE. I think it was Fortran IV, but don't quote me on that. It's been a few years. All I can recall from the classes back then was the instructor telling us that any use of the 'GOTO' instruction was going to be broken code, and he would find a way to break it(without editing). Sure, we had guys in class that would turn in code with GOTOs in it, but I just couldn't bring myself to make spaghetti.
 
Bob Noel said:
I should have put a smiley in there and/or a nitpicking alert.

DO-178B has levels A through E... and DO-178B didn't come out until well after the article was written (1992 vs 1984).

DO-178 had levels 1, 2, 3 (iirc), but definitely didn't have A - E.
Click to expand...

OK, fair enough.
 
AuntPeggy said:
And there is also the time-honored:

If ( a=b )
func();
​
In this case, the programmer is setting the value of a to the value of b instead of comparing them. And func() will always be executed. If he wants to compare the two and only execute func() when they are already equal, this is what it should be.
If ( a==b )
func();
​
Click to expand...

All true unless b == 0. In which case fund() will not get executed.

John
 
Last edited:
One of the most disturbing examples of poor software quality I've ever come across was the coding in the Therac-25 medical treatment radiation source equipment. AFaIK the investigation into this ugly mess resulted in the initiation of quality requirements for medical treatment equipment controlled by software. For a chilling but comprehensive report on the problems you can read http://sunnyday.mit.edu/papers/therac.pdf
There are also some simplified reports on Wikepedia.
http://sunnyday.mit.edu/papers/therac.pdf
 
gismo said:
One of the most disturbing examples of poor software quality I've ever come across was the coding in the Therac-25 medical treatment radiation source equipment. AFaIK the investigation into this ugly mess resulted in the initiation of quality requirements for medical treatment equipment controlled by software. For a chilling but comprehensive report on the problems you can read http://sunnyday.mit.edu/papers/therac.pdf
There are also some simplified reports on Wikepedia.
http://sunnyday.mit.edu/papers/therac.pdf
Click to expand...

Definitely. It's one of those classic cases you read about when you first start looking into software mistakes. Bad stuff there.
 
No, not an infinite loop. Therac-25 is a case where two software bugs were not caught and each one could cause harm.

1) An unexpected sequence of user keystrokes would bypass some hardware interlocks and send about 100 times as much radiation as expected. The result was fatal in most cases.

It turns out that the reason that these keystrokes were initiated by the operator was a basic desire to find a "shortcut" way of setting up the machine. The software designer assumed that the user would use the machine "as designed." This is insidious.

2) Numeric overflow would bypass some interlocks, resulting in too much radiation. This problem is often overlooked in initial design and must be guarded against.
 
You must log in or register to reply here.
Back
Top