Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8055 > unrolled thread

Re: Arithmetic overflow checking

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-10 01:47 -0700
    Re: Arithmetic overflow checking China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-10 02:47 -0700
      Re: Arithmetic overflow checking pete <pfiland@mindspring.com> - 2011-07-10 06:04 -0400
        Re: Arithmetic overflow checking China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-10 03:29 -0700
          Re: Arithmetic overflow checking Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-10 20:52 +0300
          Re: Arithmetic overflow checking pete <pfiland@mindspring.com> - 2011-07-10 23:29 -0400
      Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-10 04:44 -0700
        Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 11:33 +0100
          Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 04:17 -0700
            Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 12:33 +0100
              Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 05:24 -0700
                Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-12 21:45 -0400
            Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-12 05:25 -0700
              Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 10:21 -0700
                Re: Arithmetic overflow checking Thomas Boell <tboell@domain.invalid> - 2011-07-12 22:39 +0200
                  Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 14:15 -0700
                    Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-12 14:18 -0700
                      Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 23:54 -0700
              Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 19:14 +0100
                Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-13 00:20 -0700
          Re: Arithmetic overflow checking markspace <-@.> - 2011-07-12 09:26 -0700
            Re: Arithmetic overflow checking Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-12 10:52 -0600
              Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-12 10:48 -0700
                Re: Arithmetic overflow checking Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-12 12:36 -0600
                  Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-12 12:16 -0700
                    Re: Arithmetic overflow checking Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-12 14:09 -0600
                      Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-12 14:16 -0700
                Re: Arithmetic overflow checking, not so hard after all "Greg A. Woods" <woods@robohack.org> - 2011-07-12 21:52 -0700
                  Re: Arithmetic overflow checking, not so hard after all Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-13 12:50 +0100
                    Re: Arithmetic overflow checking, not so hard after all "Greg A. Woods" <woods@robohack.org> - 2011-07-13 11:10 -0700
                      Re: Arithmetic overflow checking, not so hard after all Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-14 01:34 +0100
                        Re: Arithmetic overflow checking, not so hard after all "Greg A. Woods" <woods@robohack.org> - 2011-07-19 17:10 -0700
                          Re: Arithmetic overflow checking, not so hard after all Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-19 20:47 -0600
                            Re: Arithmetic overflow checking, not so hard after all Keith Thompson <kst-u@mib.org> - 2011-07-19 20:23 -0700
                              Re: Arithmetic overflow checking, not so hard after all "Greg A. Woods" <woods@robohack.org> - 2011-09-06 17:47 -0700
                            Re: Arithmetic overflow checking, not so hard after all Todd Carnes <toddcarnes@gmail.com> - 2011-07-20 03:48 +0000
                  Re: Arithmetic overflow checking, not so hard after all Keith Thompson <kst-u@mib.org> - 2011-07-13 09:27 -0700
                Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:55 -0500
            Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-12 16:54 +0000
              Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 11:35 -0700
            Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 10:13 -0700
            Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-12 21:53 -0400
          Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:41 -0500
            Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-15 10:56 -0700
              Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 21:27 -0500
        Re: Arithmetic overflow checking bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-07-20 09:22 +0100
          Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-20 10:51 -0700
            Re: Arithmetic overflow checking gordonb.3urm7@burditt.org (Gordon Burditt) - 2011-07-20 15:39 -0500
            Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-21 12:12 +0100
      Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-10 09:28 -0400
        Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-10 06:52 -0700
          Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-10 14:47 -0700
          Re: Arithmetic overflow checking gordonb.u8vng@burditt.org (Gordon Burditt) - 2011-07-11 18:45 -0500
        Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:07 -0500
      Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-10 12:25 -0400
    Re: Arithmetic overflow checking Robert Wessel <robertwessel2@yahoo.com> - 2011-07-10 10:47 -0500
    Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 07:58 -0700
      Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-11 10:48 -0700
        Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 14:40 -0700
      Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-11 14:54 -0700
        Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 15:55 -0700
        Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-11 21:51 -0400
          Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 21:31 -0700
            Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-11 23:16 -0700
            Re: Arithmetic overflow checking James Kuyper <jameskuyper@verizon.net> - 2011-07-12 06:28 -0400
            Re: Arithmetic overflow checking David Thompson <dave.thompson2@verizon.net> - 2011-07-24 22:13 -0400
              Re: Arithmetic overflow checking Lew Pitcher <lpitcher@teksavvy.com> - 2011-07-25 10:24 -0400
    Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 09:05 +0200
      Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 02:22 -0700
        Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 11:34 +0200
          Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-12 03:04 -0700
            Re: Arithmetic overflow checking "Greg A. Woods" <woods@robohack.org> - 2011-07-12 19:55 -0700
              Re: Arithmetic overflow checking "Greg A. Woods" <woods@robohack.org> - 2011-07-12 21:54 -0700
              Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:28 -0500
                Re: Arithmetic overflow checking "Greg A. Woods" <woods@robohack.org> - 2011-07-19 17:16 -0700
          Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 03:33 -0700
          Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-12 08:29 -0400
        Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 13:18 +0200
        Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 11:39 -0700
          Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-12 12:38 -0700
            Re: Arithmetic overflow checking markspace <-@.> - 2011-07-12 13:20 -0700
              Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 13:23 -0700
                Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-12 21:08 +0000
                  Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-12 14:48 -0700
                    Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 15:24 -0700
                      Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-12 16:09 -0700
                        Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-13 10:38 -0700
                          Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-13 11:00 -0700
                          Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-13 12:16 -0700
                            Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-13 13:10 -0700
                            Re: Arithmetic overflow checking markspace <-@.> - 2011-07-13 13:21 -0700
                              Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-13 13:41 -0700
                                Re: Arithmetic overflow checking Robert Wessel <robertwessel2@yahoo.com> - 2011-07-14 21:10 -0500
                                  Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-15 11:57 +0200
                                    Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-15 04:36 -0700
                        Re: Arithmetic overflow checking Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-08-13 21:54 +0300
        Re: Arithmetic overflow checking "Greg A. Woods" <woods@robohack.org> - 2011-07-12 20:03 -0700
          Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-13 00:52 -0700
            Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-13 07:45 -0700
              Re: Arithmetic overflow checking "Greg A. Woods" <woods@robohack.org> - 2011-07-13 11:28 -0700
            Re: Arithmetic overflow checking "Greg A. Woods" <woods@robohack.org> - 2011-07-13 11:15 -0700

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#8189

On 7/12/2011 12:38 PM, Patricia Shanahan wrote:

> It would not necessarily directly take time. It could be done in
> parallel with the stage that writes results back to register files, or
> bypasses them to other instructions.


A JO almost certainly would be executed in parallel with the ADD 
instruction.  Executing two instructions in parallel has been available 
on consumer CPU (x86) since about 1992.  It's two decade old technology. 
  Folks complaining about performance degradation due to overflow 
detection are frankly greatly out of date in their understanding of CPU 
architecture.

[toc] | [prev] | [next] | [standalone]

#8190

On Tue, 12 Jul 2011 13:20:15 -0700, markspace <-@.> wrote:

>On 7/12/2011 12:38 PM, Patricia Shanahan wrote:
>
>> It would not necessarily directly take time. It could be done in
>> parallel with the stage that writes results back to register files, or
>> bypasses them to other instructions.
>
>
>A JO almost certainly would be executed in parallel with the ADD 
>instruction.  Executing two instructions in parallel has been available 
>on consumer CPU (x86) since about 1992.  It's two decade old technology. 
>  Folks complaining about performance degradation due to overflow 
>detection are frankly greatly out of date in their understanding of CPU 
>architecture.

     I also suggest that they build a time machine and go for a ride
on a certain Ariane 5 launch.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8193

On Tue, 12 Jul 2011 13:23:40 -0700, Gene Wirchenko wrote:

> 
>      I also suggest that they build a time machine and go for a ride
> on a certain Ariane 5 launch.
>
An out-of-range signal might have been the initial clause[1] but the real 
problem was that this exception caused an diagnostic bit pattern to be 
written to the SRI's (Inertial Reference System's) normal output channel, 
where the OBC (On Board Computer) interpreted it as flight data by 
failing to recognise it as an exception message. Unfortunately, by 
treating it as flight data, the OBC interpreted it as requiring full 
engine deflection, causing the Ariane 5 to yaw violently. Unsurprisingly, 
being side-on at high airspeed caused it to break up. 

There real cause of the crash was using a poorly documented A4 SRI 
without fully understanding its designed-in operating parameters or 
ensuring that they were reset to interpret standard A5 operating 
conditions as normal and within limits and then compounding the problem 
by not designing the OBC to recognise SRI exception messages. 

IOW, this crash was more a case of poor documentation and design rather 
than arithmetic overflow.

The full report is here: http://www.di.unito.it/~damiani/ariane5rep.html

[1] The instrument causing the problem was an unmodified Ariane 4 SRI 
which raised an out-of-limits exception when the normal Ariane 5 
trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#8197

Martin Gregorie wrote:
> Gene Wirchenko wrote:
>>      I also suggest that they build a time machine and go for a ride
>> on a certain Ariane 5 launch.
>
> An out-of-range signal might have been the initial clause[1] but the real
> problem was that this exception caused an diagnostic bit pattern to be
> written to the SRI's (Inertial Reference System's) normal output channel,
> where the OBC (On Board Computer) interpreted it as flight data by
> failing to recognise it as an exception message. Unfortunately, by
> treating it as flight data, the OBC interpreted it as requiring full
> engine deflection, causing the Ariane 5 to yaw violently. Unsurprisingly,
> being side-on at high airspeed caused it to break up.
>
> There real cause of the crash was using a poorly documented A4 SRI
> without fully understanding its designed-in operating parameters or
> ensuring that they were reset to interpret standard A5 operating
> conditions as normal and within limits and then compounding the problem
> by not designing the OBC to recognise SRI exception messages.
>
> IOW, this crash was more a case of poor documentation and design rather
> than arithmetic overflow.
>
> The full report is here:http://www.di.unito.it/~damiani/ariane5rep.html
>
> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
> which raised an out-of-limits exception when the normal Ariane 5
> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  
>

In other words, this was a case where there *was* an out-of-range
exception, thus it makes the exact opposite point to the one Gene
presumably wanted to support.

--
Lew

[toc] | [prev] | [next] | [standalone]

#8201

n Tue, 12 Jul 2011 14:48:47 -0700 (PDT), lewbloch <lewbloch@gmail.com>
wrote:

>Martin Gregorie wrote:

[snip]

>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>> which raised an out-of-limits exception when the normal Ariane 5
>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  

     ...the Ariane 5 having more powerful engines.

>In other words, this was a case where there *was* an out-of-range
>exception, thus it makes the exact opposite point to the one Gene
>presumably wanted to support.

     The data I read was that the exception was not handled.  IIRC,
debugging got interpreted as navigational data.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8203

Gene Wirchenko wrote:
> lewbloch wrote:
>> Martin Gregorie wrote:
>
> [snip]
>
>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>>> which raised an out-of-limits exception when the normal Ariane 5
>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  
>
>      ...the Ariane 5 having more powerful engines.
>
>> In other words, this was a case where there *was* an out-of-range
>> exception, thus it makes the exact opposite point to the one Gene
>> presumably wanted to support.
>
>      The data I read was that the exception was not handled.  IIRC,
> debugging got interpreted as navigational data.
>

Precisely.  There was an exception, and it was not handled.  Having
the exception was not enough.

--
Lew

[toc] | [prev] | [next] | [standalone]

#8239

On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch
<lewbloch@gmail.com> wrote:

>Gene Wirchenko wrote:
>> lewbloch wrote:
>>> Martin Gregorie wrote:
>>
>> [snip]
>>
>>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>>>> which raised an out-of-limits exception when the normal Ariane 5
>>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  
>>
>>      ...the Ariane 5 having more powerful engines.
>>
>>> In other words, this was a case where there *was* an out-of-range
>>> exception, thus it makes the exact opposite point to the one Gene
>>> presumably wanted to support.
>>
>>      The data I read was that the exception was not handled.  IIRC,
>> debugging got interpreted as navigational data.

>Precisely.  There was an exception, and it was not handled.  Having
>the exception was not enough.

     No surprise there.  Most of us understand that exceptions have to
be handled as well as thrown.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8240

On 7/13/2011 10:38 AM, Gene Wirchenko wrote:
> On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch
> <lewbloch@gmail.com>  wrote:
>
>> Gene Wirchenko wrote:
>>> lewbloch wrote:
>>>> Martin Gregorie wrote:
>>>
>>> [snip]
>>>
>>>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>>>>> which raised an out-of-limits exception when the normal Ariane 5
>>>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.
>>>
>>>       ...the Ariane 5 having more powerful engines.
>>>
>>>> In other words, this was a case where there *was* an out-of-range
>>>> exception, thus it makes the exact opposite point to the one Gene
>>>> presumably wanted to support.
>>>
>>>       The data I read was that the exception was not handled.  IIRC,
>>> debugging got interpreted as navigational data.
>
>> Precisely.  There was an exception, and it was not handled.  Having
>> the exception was not enough.
>
>       No surprise there.  Most of us understand that exceptions have to
> be handled as well as thrown.

I think the lesson we need to learn from the Ariane failure is that
adding a check removes one type of risk, but the cost of two forms of
additional risk:

1. The check gives a false positive result.

2. There is a bug in the handling of the error report.

Patricia

[toc] | [prev] | [next] | [standalone]

#8249

On Jul 13, 10:38 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch
>
>
>
>
>
>
>
>
>
> <lewbl...@gmail.com> wrote:
> >Gene Wirchenko wrote:
> >> lewbloch wrote:
> >>> Martin Gregorie wrote:
>
> >> [snip]
>
> >>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
> >>>> which raised an out-of-limits exception when the normal Ariane 5
> >>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  
>
> >>      ...the Ariane 5 having more powerful engines.
>
> >>> In other words, this was a case where there *was* an out-of-range
> >>> exception, thus it makes the exact opposite point to the one Gene
> >>> presumably wanted to support.
>
> >>      The data I read was that the exception was not handled.  IIRC,
> >> debugging got interpreted as navigational data.
> >Precisely.  There was an exception, and it was not handled.  Having
> >the exception was not enough.
>
>      No surprise there.  Most of us understand that exceptions have to
> be handled as well as thrown.
>

Apparently it was a surprise to the Ariane 5 folks.

But you brought up the case history in the first place.  What was the
point if not that exceptions need to be handled?  Isn't the problem
with the rocket exactly that exceptions weren't handled, despite your
attempt to palm that off as obvious?  Or are you just shifting ground
now that your apparent original point turns out not to be supported by
the Ariane failure?

It certainly was not that overflow exceptions are good all by
themselves, since that didn't help the rocket in question.

The lesson I derive is that nothing is too simple, trivial or obvious
to overlook.  Whether it's metric vs. English system of length that
makes one miss Mars, or failure to handle an exception that makes a
rocket blow up, despite that *obviously* one must use consistent
units, and *obviously* one must handle exceptions when thrown, we
still need to be diligent about such "obvious" matters.

So put aside your pseudo-condescension and let's learn the lessons
these case histories teach us.

--
Lew

[toc] | [prev] | [next] | [standalone]

#8256

On Wed, 13 Jul 2011 12:16:22 -0700 (PDT), lewbloch
<lewbloch@gmail.com> wrote:

>On Jul 13, 10:38 am, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch

>> <lewbl...@gmail.com> wrote:
>> >Gene Wirchenko wrote:

[snip]

>>      No surprise there.  Most of us understand that exceptions have to
>> be handled as well as thrown.
>>
>
>Apparently it was a surprise to the Ariane 5 folks.

     No.  From what I read, in the area of the error, there were some
places where handling was judged needed and some not.  What they did
about it was not adequate.

>But you brought up the case history in the first place.  What was the
>point if not that exceptions need to be handled?  Isn't the problem

     First, you need a mechanism for them.  Then, you handle them.

>with the rocket exactly that exceptions weren't handled, despite your
>attempt to palm that off as obvious?  Or are you just shifting ground

     But it is obvious to a professional.  It is fairly basic.

>now that your apparent original point turns out not to be supported by
>the Ariane failure?

     Exceptions were not dealt with properly.  Not having them when
one should is another case of this.

>It certainly was not that overflow exceptions are good all by
>themselves, since that didn't help the rocket in question.

     A professional would understand that they have to be used
properly, too.

>The lesson I derive is that nothing is too simple, trivial or obvious
>to overlook.  Whether it's metric vs. English system of length that
>makes one miss Mars, or failure to handle an exception that makes a
>rocket blow up, despite that *obviously* one must use consistent
>units, and *obviously* one must handle exceptions when thrown, we
>still need to be diligent about such "obvious" matters.

     Of course.

>So put aside your pseudo-condescension and let's learn the lessons
>these case histories teach us.

     My condescension?  Look in a mirror.

     I assume that professionals will understand some pretty basic
things.  For example, if we have an exception mechanism, that we do
something about the exceptions.  Were I to explain every such detail,
it would be being condescending.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8257

On 7/13/2011 12:16 PM, lewbloch wrote:

> The lesson I derive is that nothing is too simple, trivial or obvious
> to overlook.


What I got from reading that is that the root problem was that the range 
of values that the sensor was capable of producing was not understood. 
Either or both physically producing, or would produce under normal (or 
abnormal) system operation.

It was a failure to understand the the design, and its parameters.  That 
failure of understanding was then propagated down to the code level. 
"We don't need to protect this because an out of range can't happen."

Somewhere, somehow, somebody has to ultimately understand what the 
system does, and when.  If you don't have that, then no amount of 
general wolf-fencing (i.e., catching exceptions) will help, because you 
won't know that the exception even means, let alone what to do about it.

[toc] | [prev] | [next] | [standalone]

#8259

markspace <-@.> writes:
> On 7/13/2011 12:16 PM, lewbloch wrote:
>> The lesson I derive is that nothing is too simple, trivial or obvious
>> to overlook.
>
>
> What I got from reading that is that the root problem was that the range 
> of values that the sensor was capable of producing was not understood. 
> Either or both physically producing, or would produce under normal (or 
> abnormal) system operation.

As I recall, the range of values the sensor was capable of producing was
understood correctly *when the code was written*.

The problem is that the code was written for the Ariane 4.  Management
decided to re-use the same code, with no modifications, on the Ariane 5
-- on which the valid range of values from the sensor was quite
different.

> It was a failure to understand the the design, and its parameters.  That 
> failure of understanding was then propagated down to the code level. 
> "We don't need to protect this because an out of range can't happen."

Decisions had to be made when the code was written about which
exceptions to handle, and which to assume couldn't happen.
Handling them all wasn't an option because it would have slowed
down the system enough so it wouldn't work at all.  The particular
decisions were correct for Ariane 4.

> Somewhere, somehow, somebody has to ultimately understand what the 
> system does, and when.  If you don't have that, then no amount of 
> general wolf-fencing (i.e., catching exceptions) will help, because you 
> won't know that the exception even means, let alone what to do about it.

Given the decision to re-use the same code with no changes for a
new rocket (when the code wasn't designed for cross-rocket portability
in the first place), an improperly handled exception was just one of many
ways that it could have gone wrong.

(All this is based on my rather vague recollection of my partial reading
of the report.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8290

On Wed, 13 Jul 2011 13:41:51 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>markspace <-@.> writes:
>> On 7/13/2011 12:16 PM, lewbloch wrote:
>>> The lesson I derive is that nothing is too simple, trivial or obvious
>>> to overlook.
>>
>>
>> What I got from reading that is that the root problem was that the range 
>> of values that the sensor was capable of producing was not understood. 
>> Either or both physically producing, or would produce under normal (or 
>> abnormal) system operation.
>
>As I recall, the range of values the sensor was capable of producing was
>understood correctly *when the code was written*.
>
>The problem is that the code was written for the Ariane 4.  Management
>decided to re-use the same code, with no modifications, on the Ariane 5
>-- on which the valid range of values from the sensor was quite
>different.
>
>> It was a failure to understand the the design, and its parameters.  That 
>> failure of understanding was then propagated down to the code level. 
>> "We don't need to protect this because an out of range can't happen."
>
>Decisions had to be made when the code was written about which
>exceptions to handle, and which to assume couldn't happen.
>Handling them all wasn't an option because it would have slowed
>down the system enough so it wouldn't work at all.  The particular
>decisions were correct for Ariane 4.


In a sense it's not that the exception was unhandled, but rather that
the exception was handled as a hardware failure, leading to the
shutdown of the inertial guidance computer.  Of course the backup
guidance system keeled over at the same time (IIRC, the backup system
may have actually tripped off first by a few ms).

So the problem was not so much the unhandled exception, but the
generation of the exception for the normal condition in the first
place.

The real head-banger is that the code in question no longer did
anything useful on the Ariane 5.

[toc] | [prev] | [next] | [standalone]

#8304

"Robert Wessel" <robertwessel2@yahoo.com> ha scritto nel messaggio
news:gn7v17d4ljhjsndhksgk4f1584a135u6cf@4ax.com...
> On Wed, 13 Jul 2011 13:41:51 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>markspace <-@.> writes:
>>> On 7/13/2011 12:16 PM, lewbloch wrote:
>>>> The lesson I derive is that nothing is too simple, trivial or obvious
>>>> to overlook.
>>>
>>>
>>> What I got from reading that is that the root problem was that the range
>>> of values that the sensor was capable of producing was not understood.
>>> Either or both physically producing, or would produce under normal (or
>>> abnormal) system operation.
>>
>>As I recall, the range of values the sensor was capable of producing was
>>understood correctly *when the code was written*.
>>
>>The problem is that the code was written for the Ariane 4.  Management
>>decided to re-use the same code, with no modifications, on the Ariane 5
>>-- on which the valid range of values from the sensor was quite
>>different.
>>
>>> It was a failure to understand the the design, and its parameters.  That
>>> failure of understanding was then propagated down to the code level.
>>> "We don't need to protect this because an out of range can't happen."
>>
>>Decisions had to be made when the code was written about which
>>exceptions to handle, and which to assume couldn't happen.
>>Handling them all wasn't an option because it would have slowed
>>down the system enough so it wouldn't work at all.  The particular
>>decisions were correct for Ariane 4.
>
>
> In a sense it's not that the exception was unhandled, but rather that
> the exception was handled as a hardware failure, leading to the
> shutdown of the inertial guidance computer.  Of course the backup
> guidance system keeled over at the same time (IIRC, the backup system
> may have actually tripped off first by a few ms).
>
> So the problem was not so much the unhandled exception, but the
> generation of the exception for the normal condition in the first
> place.
>
> The real head-banger is that the code in question no longer did
> anything useful on the Ariane 5.

if i say something
if you have a prog that 'can' fail
the exception that make end the program is right
because this point out one error to correct;

if you have a prog can not fail
it is better not raise the exception

[toc] | [prev] | [next] | [standalone]

#8309

On Jul 15, 12:57 pm, "io_x" <a...@b.c.invalid> wrote:
>
> if i say something
> if you have a prog that 'can' fail
> the exception that make end the program is right
> because this point out one error to correct;
>
> if you have a prog can not fail
> it is better not raise the exception
>
Yes, sometimes you just have to plough on regardless, and hope that
the system will recover.

[toc] | [prev] | [next] | [standalone]

#9355

lewbloch wrote:
> Gene Wirchenko wrote:
>> lewbloch wrote:
>>> Martin Gregorie wrote:
>> [snip]
>>
>>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>>>> which raised an out-of-limits exception when the normal Ariane 5
>>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.  
>>      ...the Ariane 5 having more powerful engines.
>>
>>> In other words, this was a case where there *was* an out-of-range
>>> exception, thus it makes the exact opposite point to the one Gene
>>> presumably wanted to support.
>>      The data I read was that the exception was not handled.  IIRC,
>> debugging got interpreted as navigational data.
>>
> 
> Precisely.  There was an exception, and it was not handled.  Having
> the exception was not enough.

There was an exception (overflow in a conversion instruction), and it 
was handled. However, the handler was designed for the Ariane 4, where 
the designers (after careful analysis of the data ranges for the Ariane 
4) decided to assume that an overflow exception indicated a CPU HW 
failure, and consequently the handler shut down the CPU. The same 
overflow then occurred in the redundant CPU, which also shut down, so 
the rocket was left with no guidance.

If the SW had been tested properly, the overflow exception would have 
occurred during testing, which would have revealed the flawed 
assumptions made in the reuse of the Ariane 4 SW on the Ariane 5. Surely 
that would have been better than ignoring the overflow.

The Ariane 501 disaster is a poor guide for this discussion, because of 
the difficulty of proper exception handling in that system: you cannot 
abort the launch and return to the launch pad. In most applications, it 
is much easier to design reasonable and safe exception handlers.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#8223

tm <thomas.mertes@gmx.at> writes:
> 
> Yes, but it must be checked after every operation.
> A hardware that triggers an interrupt, would save this
> extra checks.

I think you're assuming either the code is running nearly bare on the
hardware (in which case your program has its own ISR), or that your OS
has a very inexpensive way to deliver the ISR to a process.

As I mentioned in another post just now, a decent compiler can use
library routines for all arithmetic operations and thus allow all
operations to be checked for overflow algorithmically.  See GCC's
"-ftrapv" option, for example.

You may also be assuming that overflows aren't so common in C.  :-)

Try re-compiling your system's entire userland with "gcc -ftrapv" and
see how much of it still works without aborting.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

[toc] | [prev] | [next] | [standalone]

#8229

On 13 Jul., 05:03, "Greg A. Woods" <wo...@robohack.org> wrote:
> tm <thomas.mer...@gmx.at> writes:
>
> > Yes, but it must be checked after every operation.
> > A hardware that triggers an interrupt, would save this
> > extra checks.
>
> I think you're assuming either the code is running nearly bare on the
> hardware (in which case your program has its own ISR), or that your OS
> has a very inexpensive way to deliver the ISR to a process.

I was not talking about the overhead that occurs when an overflow
happens. Exceptions should be rare and people know that they are
not as cheap as normal computations.

I thought about overhead, when NO overflow occurs.

In an ideal world code with and without overflow checking would run
at the same speed (as long as no overflow occurs).

> As I mentioned in another post just now, a decent compiler can use
> library routines for all arithmetic operations and thus allow all
> operations to be checked for overflow algorithmically.

Yes, but this would have probable more overhead than checking
an overflow flag, not to mention hardware that can do this
without extra cost (trigger interrupt).

> See GCC's "-ftrapv" option, for example.

AFAIK -ftrapv adds code to check an overflow flag after arithmetic
operations.

IMHO -ftrapv is the right way, because it allows gcc to use hardware
support (when a CPU is able to trigger an interrupt on overflow).

BTW, does gcj support this option also?
Has javac a similar option?

> You may also be assuming that overflows aren't so common in C.  :-)
>
> Try re-compiling your system's entire userland with "gcc -ftrapv" and
> see how much of it still works without aborting.

It does work.
I just had to change a program which checks left shift by comparing
the result with a multiplication by a power of two. AFAIK left shift
is not checked by -ftrapv, but multiplication is. Nor the chkint.sd7
program only checks left shift in situations where no overflow
occurs.

Using the signal to raise an exception is something else.
E.g.: gcc and clang disagree in the signal used (gcc: SIGABRT,
clang: SIGILL). So useful support of this feature in Seed7 may
take some time.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#8234

On 7/13/2011 12:52 AM, tm wrote:
> On 13 Jul., 05:03, "Greg A. Woods"<wo...@robohack.org>  wrote:
...
>> As I mentioned in another post just now, a decent compiler can use
>> library routines for all arithmetic operations and thus allow all
>> operations to be checked for overflow algorithmically.
>
> Yes, but this would have probable more overhead than checking
> an overflow flag, not to mention hardware that can do this
> without extra cost (trigger interrupt).

I'm not convinced that there would be extra cost. The main performance
costs on modern processors tend to be data movement, and mis-predicted
conditional branches. The overflow check needs no additional data, and
the associated conditional branches will be about as easy to predict as
is possible.

Patricia

[toc] | [prev] | [next] | [standalone]

#8243

Patricia Shanahan <pats@acm.org> writes:
> 
> On 7/13/2011 12:52 AM, tm wrote:
> > 
> > On 13 Jul., 05:03, "Greg A. Woods"<wo...@robohack.org>  wrote:
> ...
> > > As I mentioned in another post just now, a decent compiler can use
> > > library routines for all arithmetic operations and thus allow all
> > > operations to be checked for overflow algorithmically.
> >
> > Yes, but this would have probable more overhead than checking
> > an overflow flag, not to mention hardware that can do this
> > without extra cost (trigger interrupt).
>
> I'm not convinced that there would be extra cost. The main performance
> costs on modern processors tend to be data movement, and mis-predicted
> conditional branches. The overflow check needs no additional data, and
> the associated conditional branches will be about as easy to predict as
> is possible.

I'm not sure what target host environment you're thinking of, but in any
general purpose operating system environment I can think of the extra
cost of the hardware interrupts triggered by arithmetic overflows could
be significant.  Signal delivery and context switching is never free.

Worst would be if the hardware interrupt couldn't easily and efficiently
be disabled temporarily by the OS when running a process which didn't
care to be notified.  Then the OS would have to handle the interrupt and
figure out whether to discard it or not.  CRC algorithms, and especially
those in the kernel, may have to be carefully re-implemented to avoid
triggering overflows unnecessarily, and would thus then incur added
runtime costs themselves.  I.e. avoiding triggering unnecessary
interrupts could also be a significant runtime cost.

When you get down to brass tacks you only want overflow and wraparound
checking when you need it.  Unfortunately C makes it hard for
programmers to easily know when they need it.  I think the AIR proposal
may help, and it seems as if the RICH work identified many of these
issues and dealt with some of them too.  I guess I'll be content to wait
until something like these shows up in a GCC or Clang release I'm using,
as I've been living with overflows and wraparound (and no bounds checks)
well enough so far.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web