Some Boeing 737s can't land on some runways with true heading 270 [pdf] | Hacker News Reader

Some Boeing 737s can't land on some runways with true heading 270 [pdf]

rgl.faa.gov

75 pointsColinWright38 comments

Isn't this a duplicate of a post within the past few weeks? I remember this.

https://news.ycombinator.com/item?id=21991087

Thank you!

This makes me wonder how long it would take for a competent technical leader to course-correct the culture and product issues that have crept in at Boeing. It seems to me it would be on the order of years to get their house in order to get quality to where it should have been.

> competent technical leader to course-correct the culture and product issues that have crept in at Boeing.

This issue looks to be a pretty run-of-the-mill bug in their software. It's likewise scoped down pretty far--there only exist a few runways (in US, Colombia, and Guayana) that make this relevant. ADs like this come out all the time.

I get the gist of what you are saying about it being par for the course, but can you explain why a heading of 270 (West if 0 is North)would affect air worthiness? Is it something to due with true North vs. magnetic north deviations? Grasping here. I am truly curious about this one. Thanks!

Air worthiness is determined by the FAA. In this case, the aircraft are only considered not airworthy when the flight plan calls for landing on one of those runways. Operating them in any other configuration is A-OK.

As to why the bug exists, who knows :)

Edit: Clarified slightly.

It affects airworthiness because the displays went blank when certain ILS approaches with heading 270 were selected. This is unexpected and would require the flight crew to fall back on other instruments.

The FAA routinely issues airworthiness directives for all sorts of safety issues. Here are a few others published in the past week or so:

https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf...

Based on the AD, I suspect they're doing some sort of math on the longitude coordinates of the runway borders/endpoints. ("[O]nly seven runways worldwide, as identified in this AD, have latitude and longitude values that cause the blanking behavior.")

Why does correctness matter, its not like anyone is ACTUALLY named "DROP TABLE users;"

Background for the post above: https://xkcd.com/327/

Not blaming this commenter specifically, but this pervasive callous attitude of over-focusing on narrow metrics of importance seems to be why our general experience with software is so... shitty.

The problem with such “partial” functionality is that it breaks composition. When you start building systems with a dozen modules, each with a couple of edge cases like this, the probability of something failing becomes high, and makes the final result/experience very crappy. Imagine if you had a sweater you couldn’t wear on Tuesdays!

For those who don’t get it, it’s not just about how often this “bug” affects the system (let alone the fact that it is quite severe). It indicates an utter lack of competence towards developing safety critical systems... like, how can one be writing navigation code and NOT know this?

That this could be considered a run-of-the-mill software bug means that we have set our standards too low.

Isn't gonna happen. The amount of outsourcing, regulatory side-stepping and bean-counting is beyond the tipping point.

At this point it would be easier to start a new company and import the positive things from Boeing. They've lost their "engineering first" mentality and that's not something that is easy to get back, and they may not be able to handle the financial losses involved in doing so after running as "money first" for so long.

>how long it would take for a competent technical leader to course-correct the culture

Undefined. The problem was never a lack of technical proficiency, the problem is the culture.

From what I've heard, the recent CEO who was forced to step down was the competent technical leader that was working on fixing the problems at Boeing. He just didn't have time to do it.

F-22 had similar weird bug. Instead of degrees it was dates.

In 2007 squadron (12) of F-22's were flying from Hawaii to Japan. When they crossed when they crossed international date line every plane had systems crash. They lost communication-, fuel-, and navigation subsystems and restart did not solve the problem. Apparently only basic aviation systems worked. They could still fly.

They would have been completely lost, but luckily tanker escorting them was still nearby. They were able to follow it back to the base.

It's a software bug that affects 7 runways worldwide due to a combination of heading and lat/long.

That does bring up an interesting point. There's only so many airports in the world (especially ones that can support a 737). You'd think that'd be easy to exhaustively test if you wanted to.

Interesting. Do you have more on that? I'd be curious to know more details.

Would a viable workaround be to tell it the heading is 269 or 271? You’d land at a slight angle which would have you moving about 17 m toward an edge of the runway for every km down the runway you go. That seems mild enough for the pilots to correct once they are on the ground.

FTA: "All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected."

Holy f-cking f-ck.

Do any languages (like Rust, maybe) force you to guard against the possibility of a variable being zero if it sees you're dividing by that variable?

And if not the compiler, are there popular static analyzers for any languages that do so?

Rust doesn't by default, though you could certainly make a wrapper type that does. You could do the same in any language that has algebraic data types (rust enum's), or another sensible way of forcing you to check certain kinds of errors.

I'll have to experiment with implementing that as well as how Rust divides by zero. Thanks for sharing.

My probably wrong understanding is that the philosophy behind Rust is that code without IO/unsafe shall not panic. It might provide useless results but it won't panic. But dividing an integer by zero causes a panic (if I recall).

Edit: derp. Of course they can panic. You really can't guard against overflow or OOM and such. gpm helped correct my thinking: it's not about avoiding panics, it's about avoiding undefined behaviour, forcing you to define all possible branching paths.

Safe rust code is allowed to panic, the standard library does in many places, and the language does if you overflow normal arithmetic while debug assertions are on (if debug assertions are off, overflows result in wrapping instead).

What safe code isn't allowed to result in is undefined behavior. Panics are defined, they just happen to be defined to print an error message and abort the program (by default, slightly simplified version of how they work).

By the way: If you want to handle overflows you can use methods like `checked_add`, or you could do something like the suggestion for division by zero and create a wrapper type that always does `CheckedI32 + CheckedI32 -> Option<CheckedI32>` (or something). I might implement `Option<CheckedI32> + Option<CheckedI32> -> Option<CheckedI32>` as well so you can delay checking for overflow/division by zero until you want to use the result of the arithmetic.

> ...does if you overflow normal arithmetic while debug assertions are on (if debug assertions are off, overflows result in wrapping instead).

What I am reading from this is that in Rust, debug assertions cause a different semantics. That does not sound right at all.

That's... exactly right, it's the entire point.

Assertions, check if a condition is true, and if it is false print an error message and exit the program. Assertions in rust are written `assert!(expr, optional_formatting_stuff)`.

Debug assertions do the same, but they are only executed when the `debug_assertions` flag is passed to the compiler, typically for performance reasons. In C terms, a debug assert is basically `#ifdef DEBUG_ASSERRTIONS assert(foo) #endif`. Debug assertiosn in rust are written `debug_assert!(expression, optional_formatting_stuff)`.

"Formally", arithmetic overflow in rust is defined to either wrap (as per 2s complement arithmetic) or panic.

In todays compilers that means they perform 2s complement artihmetic when debug assertions are turned off, and they panic when it is turned on. If performance of checking for overflows improves in the future, it will be considered an acceptable (backwards compatible) change to always panic instead, but that would have too large a performance impact today.

The debug assertions can panic on code which has defined behavior in production, but behavior that's probably wrong, and probably would be asserted in production if it weren't too expensive.

For example, if you do "u32::INTEGER_MAX + 3" in debug, it will panic, but in production code it will not (and will use the underlying CPU's result of "2")

In most scenarios, this is not actually what you want. If your program has the possibility of doing arithmetic near or past the bounds, you should define the semantics you need.

I.e., you can use one of saturating_add, wrapping_add, checked_add, or overflowing_add, depending on the semantics that are correct for your application. All of these behave the same between dev and prod.

https://repl.it/repls/SilverCarelessWearable

  error: attempt to divide by zero
   --> main.rs:2:16
    |
  2 |   let result = 1 / 0;
    |                ^^^^^
    |
    = note: #[deny(const_err)] on by default

  error: this expression will panic at runtime
   --> main.rs:2:16
    |
  2 |   let result = 1 / 0;
    |                ^^^^^ attempt to divide by zero

  error: aborting due to 2 previous errors

very simple example though, no idea what happens when that value comes via socket or file, guess that would panic! then.

That's actually just a lint that you can turn off with #[allow(const_err)], though obviously you shouldn't turn it off on a real project since it catches stupid mistakes like this.

And yep, the result is a panic, even with debug_assertions off (i.e. you make overflows wrap instead of panic).

https://play.rust-lang.org/?version=stable&mode=release&edit...

Normally that would depend on the architecture.

For x86, you would get an exception. Of course the compiler could insert a check for 0 and a branch, avoiding the exception.

For PowerPC and I believe most RISC, there is no exception. Most processors would give a specific value, such as 0x80000000 for 32-bit. Of course the compiler could insert a check for 0 and a branch, intentionally jumping to code that raises an exception.

On MIPS the convention was exactly that. The compiler would add that extra code so that you'd get an exception even though the hardware wouldn't give one.

This often causes RISC processor emulators compiled for x86 to crash.

It's one of the many architecture-specific things that can poke through the abstraction layers to burn people. Another common group of them, for which I'm curious what rust does, is shift values that are out of range or that shift negative values right. For example: -6 shifted right by 1, 42 shifted left by 4096, 12 shifted right by -2, 88 shifted left by -3, -13 shifted right by 256, etc. (and for the non-negative values, does it matter if they are an unsigned type or not?)

All of those would panic in rust. Rust inserts checks for anything that might cause an exception in order to turn it into a safe panic.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

It does. There are types in the standard library for non-zero numbers[1]. While it would involve writing a wrapper, Rust does provide for customizing the behavior of operators[2]. The example implementation for Div (the "/" operator) even shows how to make a type that panics when trying to divide by zero. One could also return a Result so that trying to divide by zero can fail gracefully.

1. https://doc.rust-lang.org/std/num/struct.NonZeroI32.html

2. https://doc.rust-lang.org/std/ops/trait.Div.html

The bigger problem is anyone using trigonometry (instead of vector methods) in practical geometry code, where not absolutely necessary.

If you go poking around geometric code (cartography, computational geometry, physics modeling, graphics, ...) and hunt for places where trigonometry is used, you’ll find lots of errors where the programmer didn’t consider the behavior in every edge case. The vector alternatives are simpler, more efficient, more numerically stable, and a lot easier to reason about.

This is easy to do in Ada:

  subtype Heading is Integer range 1 .. 360;

Can't represent 0° in a natural way. Better would be a modular type:

  type Heading is mod 360;

It works for eastward headings so it's not a simple divide by zero crash but another error with trigonometry, probably with arctan or signum.

Reply on news.ycombinator.com