Slashdot Mirror
Software Bug in F-35 Radar Causes Mid-Flight System Reboot
Reader Lisandro writes: The F-35 Fighter jet can't seem to catch a break. An advanced AN/APG-81 AESA F35 radar system has been found riddled with a software bug that causes it to degrade and stop working. The solution? Rebooting the system while in the air.
Major General Jeffrey Harrigian, director of the Air Force's F-35 integration office at the Pentagon, was quoted as saying "radar stability - the radar's ability to stay up and running. [...] What would happen is they'd get a signal that says either a radar degrade or a radar fail - "something that would force us to restart the radar." The issue was spotted in late 2015, and thankfully, it was caught during the testing period. The software version "3i" is affected. An update aimed to resolve the bug is expected to be delivered to the US Air Force by the end of March.
Major General Jeffrey Harrigian, director of the Air Force's F-35 integration office at the Pentagon, was quoted as saying "radar stability - the radar's ability to stay up and running. [...] What would happen is they'd get a signal that says either a radar degrade or a radar fail - "something that would force us to restart the radar." The issue was spotted in late 2015, and thankfully, it was caught during the testing period. The software version "3i" is affected. An update aimed to resolve the bug is expected to be delivered to the US Air Force by the end of March.
A serious question here.
Has anyone experienced memory leaks caused by race conditions and how (un-)common is it? Those would be much harder to catch and might also only appear in real world scenarios.
Have you actually every tried writing a formal proof of correctness for any algorithm at all, let alone a non-trial one dependent on external subsystems and with huge amounts of state?
Yes, I have tried, and raised funding, and managed in fact to run one layer of our formal modelling language in real time (slowly). But we decided that the proof languages (Z and ML, with a sprinkling of CCS) weren't up to the task, and nor were we.
Rgds
Damon
http://m.earth.org.uk/
This happens literally all the time with software updates on jets, anyone who's worked on any other generation fighter/attack aircraft in the "digital age" knows this. The interesting part, is that someone is publicly complaining about it, and making a software version with a bug, known to the public. Every radar system we've produced for 30 years has issues, again, this is completely normal. This article is about sounding some sort of political alarm, it shows that there's some dissent among the ranks, and I can assure you, that any experienced test pilot wouldn't even be remotely surprised to see this type of behavior, but the usual course of action is to document it and train the pilots in the short term, while releasing a new version of software in the long term. Pilots fly with "radar degrade" every single day. This is making a standard issue between contractors and military flight crews, into a public pentagon issue, to either ask congress for more money, rather than holding said contractors accountable for their failure to meet some sort of design goal, or to try to join the "anti F-35" team to advance his own career in some way. Our jets are flying way beyond their designed limitations right now, and the longer it takes to replace them, the worse off all of our military personnel are going to be.
The other detail missing here is that 3i isn't fielded yet. That is something like Block 2F which is only installed in the Marine Corp unit right now. Oh by the way - There is only one unit of Marine F-35s that are "on-duty" right now - the entire rest of the fleet is under test/development.
Have you compiled your kernel today??
777 or 747, can't remember which. Many years ago I took a flight from Chicago to Shanghai. Once we've boarded the plane, we sat there for a longer than usual amount of time. Eventually the pilot announced a delay due to "technical difficulties" and a technician was dispatched soon thereafter. After another 15 minutes or so, the pilot announced they had to reboot the system and we would be well on our way. Sure enough, all power was cut - the lights, seat displays, etc. I can't remember if they had the engines idling or not; either they were still running unaffected or they shut them down prior to the reboot. But the real fear I had was what happens if another reboot is needed 30k, feet in the air. I just hope the technician needed a hardware swap and not clearing an unknown unreproducible software glitch.
Life is not for the lazy.
If you're using the standard model of whoever allocates the memory is responsible for freeing it, then it should never happen. Now I understand that sometimes you need to break that paradigm, but a programmer who does this should be very aware of this and careful when they do it. And in any case, again, pointers should always be initialized to NULL, and if reusing a pointer you should check if it's null before assigning to it, and after freeing, it should always be nulled. Even better, use an autopointer or some variant there of.
For the tl;dr, with all the tools and established practices programmers should use when dealing with unmanaged languages, memory leaks should never happen, let alone due to a race condition.
Extremely common, actually. It's one of the major pitfalls and difficulties of doing multi-threaded programming and one of the hardest things for programmers new to multi-threaded design to learn how to solve. It can also be extremely difficult to debug, even for experienced programmers.
Improper garbage collection is another extremely common bug that becomes harder to find and debug with multi-threaded programming, and that can also lead to memory leaks.
There are time tested techniques to mitigate these issues and strategies to find and squash the bugs, but as you said, they can be extremely hard to reproduce while testing.
It's possible to write complex systems using modular design: do one thing and do it well.
And you'll soon discover your simple modules start interacting in ways that you did not anticipate or understand. There are also unlikely to be any tools available to analyze how your set of modules work as a whole.
Every nontrivial system has emergent behavior. You can't eliminate complexity with hand waving.
The F-104 was a fantastic jet. But a terrible military jet.
That thing was made to be a fast, last minute, bomber interceptor. It was built to get there at Mach 2+, fill the bomber's ass with lead and get home. Originally, it hadn't provision even for missiles!
But them, Pentagon changed the rules demanding a multi hole aircraft, and Lockheed started to hack the airframe. As a technical achievement, it was a formidable one. But again, as a military weapon, a questionable one.
The best "worst" hack was the F-104G, made for Germany. They almost doubled the combat radius - but made the thing yet more harsh to handle. A lot of German women were made widows by this plane.
Curiously, Italy was also an operator for this aircraft, but without a single recorded casualty (perhaps nobody managed to take it off! =P ).
The bottom line I had read is: the F-104 is a formidable plane in the hands of formidable pilots. And a catastrophe waiting to happen in everybody else's.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org