> The incident was triggered by a valid manual request for a squawk code. This manual request was made correctly and there was nothing abnormal or invalid about the associated flight plan.
> While this request was being processed, the NAS received a message for a higher priority activity to be undertaken which resulted in the squawk code allocation being paused while the system processed the higher priority message. Switching between different activities in response to prioritised requests is a normal function of the system; however, when the processing of the squawk allocation request resumed, the software defect meant it did not resume correctly and the resulting output was corrupted.
> The reason this scenario has not occurred before is because:
> 1. The defect existed in a specific subsection of code within a software module, with an exposure window estimated as approximately one millisecond.
> 2. For the fault to occur, a higher-priority request had to arrive during that exact millisecond while the original request was part-way through updating a value.
> 3. Had the higher-priority request arrived even one millisecond earlier or later, the update would have completed normally.
> Post-incident investigation has identified that when processing of the squawk allocation request resumed, the data associated with it had been corrupted and affected some subsequent flight data updates.
Very interesting. I spent a large part of my career in aerospace and never considered this failure mode before. It makes me wonder: how long is the pathological code allocation time? A few seconds, at most? We're talking about flight identification codes that are normally assigned upon takeoff and change at most a handful of times during a flight.
I assume the "manual request" is an aircraft squawking 7700 or similar, but why does the system need to interrupt an in-flight allocation in the first place? Any controllers here have insight?
One would think it would be sufficient to do something single threaded like
there will be some other tasks in the system that need time guarantees around when they get scheduled for very important (safety?) reasons. so when these higher priority tasks show up the lower priority tasks get suspended.
if they could guarantee hard bounds on how long low priority tasks take to complete they could implement your scheduling algorithm. but i think in reality the low priority tasks are either not boundable or they if they do have a provable bound the bound is too high.
Testing isn't an effective way to catch most race conditions. Code reviews, static analysis, and rigorous enforcement of concurrent coding standards is usually a better approach.
Or maybe even just reviewing logic that is subject to pre-emption.
Maybe I'm being too harsh.. on the plus side the system has at least failed hard every time there's been a fault. Nobody has died. But it's been 3 times now in the past couple of years, and two of those times resulted in over 2000 flights cancelled and days of backlog, and misery for hundreds of thousands. It's really not acceptable.
Chris used to publish all sorts of fun wacky exploits and then stopped when he joined Intel. Putting the LinkedIn puzzle pieces together, he recently left Intel so it looks like he’s back to publishing fun wacky exploits again.
Hmm I granted access to my photos then selected an album but it says "No photos found" after. It also says "PhotoManager has 0 photos" and "DisplayedPhotos has 0 photos". I chose a shared album, if it matters.
edit: okay yeah it doesn’t work with a shared album
The J Church line on Muni is still a train in part because back when they were converting lines to buses, the hill on Church St was too steep for buses.
Wiki says it was more because of the private right away used, not necessarily its steepness:
> While many streetcar lines were converted to bus lines after World War II, the J Church avoided this due to the private right-of-way it uses to climb the steepest grades on Church Street, between 18th Street and 22nd Street.[9]
> Ironically, this steep grade saved the J-Church line from being replaced by buses. After World War II, San Francisco began replacing the streetcar lines with buses, but the Church Street hill proved too steep.
reply