Spirit rover OS problems

Why do press articles alwasy say scientists as in the above paragraph ? It bugs the hell out of me when in all these projects no engineers are ever acknowledged as having done anything. Hopefully it was not really the scientists that was doing the engineering anf programming of the Pathfinder.

Anton Erasmus

Excrement of a male bovine. It's called lint. All C++ does is give you more rope with which to shoot yourself in the foot.

I don't know why more C programmers don't lint their code. I suspect it's because they resent being told (by anybody or anything) that their code sucks.

I think it was John Levine who said something to effect of "It's clearly possible to write good programs in C++. It's just that no one does."

You might get that to work in C++ if you tried hard enough, but every C compiler I've ever used would puke on that. You need a better example. How about "b += 10;"? That at least would compile, though it surely wouldn't "work."

Regards,

-=Dave

Hi Dilton,

By the way, to all: I am NOT referring to the above URL. I am referring to the first reference quoted in it, to which the link is . This latter reference appears to be considerably less sanitized than the embedded.com article.

This is what *I* read (verbatim):

"Once we understood the problem the fix appeared obvious : change the creation flags for the semaphore so as to enable the priority inheritance. The Wind River folks, for many of their services, supply global configuration variables for parameters such as the "options" parameter for the semMCreate used by the select service (although this is not documented and those who do not have vxWorks source code or have not studied the source code might be unaware of this feature). However, the fix is not so obvious for several reasons :"

The article I reference above specifically says that it was undocumented and its existence could only be learned by studying the sourcecode.

Can you point out where I ever said "Linux"? I said open source. I didn't say Open Source(sm) :) I would point you to eCos, uCos-II, and now even (kinda) Windows CE as examples of open source applications that are not Open Source - and specifically not Linux.

I am specifically excluding OSes that are closed-source to the masses but open-source to the rich illuminati/trough-fillers (potayto, potahto).

I'm very happy your application ran for so long under Windows NT. This phenomenon is commonly known as "luck" and is modeled pseudo-mathematically in many role-playing games with more or less the same accuracy as any reliability estimate you can give your client.

The problem is that you have no way of guaranteeing that it will survive a given system loading condition, because without OS source you have no hope of knowing what the machine is doing at any given time, nor the tools to find out.

Any professional gambler-cum-mathematician will tell you that a hundred good hands in a row from an unbiased pack of cards do not predict the outcome of the next deal. Having the source is like having X-ray vision at a card game. It doesn't protect you against an opponent with a world-beating hand, but it lets you plan for it and limit your losses.

Although I have built entire RTOSes in the past, I have also programmed extensive systems using nestable interrupts. Such systems are possible if the hardware has done its job and provided an interrupt for each possible hardware event.

The result is a very simple system with NO RTOS, but handles situations very well. It simply reacts to events as they happen, and multiple events get stacked up and unwound if they happen at the same time. It is even possible to sculpt the "priority" of the tasks by having a high priority event handler delay the point at which it reenables interrupts for nesting until after its critical work is done, however, I have found that is rarely necessary. The result is a system with excellent latency and low overhead.

The point is, there is no real reason for an RTOS to grow to a complex mass. With critical applications, the verifiability of code must be considered along with its function.

Someone said earlier in this thread that priority inversion was the cause of the recent Spirit rover problems, and yet, I can't find anything that backs that up. I can't even find any news that mentions "priority inversion" in conjunction with Spirit.

All the news I read says that the problem had something to do with the flash filesystem.

I sent this to Scott Adams, but I have a feeling he already published it in one of the DNRC newsletters :)

ISTR someone saying something along the lines of:

C gives you enough rope to hang yourself. C++ gives you enough rope to rig a brigantine and still have enough left over to hang yourself.

Sorry, it's not original. I'm not that clever. I got it from the title of a book Allen Holub wrote: "Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming"

I have a copy, it makes for fun reading, but it's not a silver bullet (Fred Brooks was always right), and I don't agree with all of it. Amazon Marketplace has several copies if you're interested.

Regards,

-=Dave

Initial reports: "priority inversion"; later reports: "flash files". My guess (and that's all) is that both are true - consider that the problem totally disabled the craft. I believe it was watchdogging into a semi-shutdown mode, but may be wrong. I'd like to know.

Steve

Hi Lewin,

Ok, you and rickman make your points well. You were both referring to the article referred to by the article you referred to originally. I read the article not the reference of the article because you referred to the article not to a reference contained within the article.

Technicality only. :)

Not if you have a coding standard enforced with lint they won't. Ada provides facilities for unchecked conversions but it is not reasonable to argue that all Ada programs are intrinsically unsafe because of it.

That doesn't work. If you change the last line to b+=10 it will compile, but a good lint tool will not let it pass.

I tried it and got:

Likely creation of out-of-bounds pointer (10 beyond end of data) by operator 'ptr+=int'

Andy

This is a quote of what I said in my original posting in this thread:

really

My company used VxWorks on 68Ks back in 1994 and found priority inversion problems in their file system code which resulted in cross linked files and, occasionally, system lockup. We ended up fixing it ourselves because Wind River was too slow in responding, but we submitted our patch code to them and the next version of the 68K RTOS worked properly.

I haven't been following the story that closely, but if these spacecraft really used VxWorks and indeed were crippled by priority inversion in the file system, it means that WindRiver has never paid much attention to detail because they have been aware of the (potential for) problem in VxWorks for at least a decade.

George

============================================== Send real email to GNEUNER2 at COMCAST dot NET

the

article

Ah. :) I thought you meant the first reference of the article's author possibly attributing the failure to X; I didn't realize that you literally meant the first article referenced within the article.

Right, this special kind of customer should also get a line-by-line training of the OS (divided by the overall costs it would be nearly $0)

Good points. Actually I don't need to be convinced, so far I had only good experience giveing the source of any software we produce. But todays problem is, that many people think of open source == Open Source == freeware. Or they buy a product then start changing the code and later want support for what they might have crippled !

Wow.

This is the kind of posting I'd love to read in comp.os.vxwoks...

-- Ignacio G.T.

Certainly. But some languages make it hard to write bulletproof code, while other languages make it hard to screw up.

C is like a table saw missing the finger guard. An expert can use it most of the time without losing fingers, but you wouldn't turn a beginning shop class loose with it.

An interesting comparison, as I consider the blade guard on a table saw to be very dangerous, and always remove it.