パスワードを忘れた? アカウント作成
12403918 story
バグ

米国で起きた航空管制システムの機能不全、メモリ不足が原因と判明 41

ストーリー by hylom
分かりやすいメモリリーク 部門より
あるAnonymous Coward 曰く、

先週の土曜日、米バージニア州の航空管制センターでシステムに不具合が発生し、ワシントン空域の数百ものフライトが遅延もしくはキャンセルされるなどの被害が出た。一部ではサイバー攻撃の可能性も疑われていたが、米連邦航空局(FAA)が解析した結果、原因は今年初めに行われたレーダー施設で行われた管制システムのソフトウェアアップデートであることが判明したという(FAAThe Washington PostGCNSlashdot)。

問題があったのは、頻繁に参照されるデータをカスタマイズされたウィンドウに表示する機能。ここで本来なら不要になったデータは削除されるはずだったが、メモリ内にデータが残りそれが肥大化。その結果、システム全体の動作に必要な処理能力を奪ったとのこと。FAAおよび開発を行ったロッキードマーティンは、問題が解決するまでシステムの運用停止を決めたという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年08月22日 17時12分 (#2868833)

    そんな重要なシステムを止めてしまって大丈夫なのか?と思って
    リンク先を見にいったのですが、「システムの運用停止」という記述は見つけられませんでした。

    FAAのプレスリリースには以下のように書かれていて、問題の表示機能の使用を一時的に停止しただけのようです。

    By temporarily suspending the use of this function, we have eliminated the possibility of this particular issue from occurring again.

    • by Anonymous Coward on 2015年08月22日 22時08分 (#2868950)

      原因のソフトウェアアップデートが「今年初めに行われた」というのも対応する記述がみつかりません。プレスリリースで関係しそうなのは

      The availability rate of the En Route Automation Modernization (ERAM) system has been higher than 99.99 percent since it was completed nationwide earlier this year.

      というところですが、直訳すれば「今年のこれまでにアメリカ全体でERAMシステムが完成して以来、その稼働率は99.99%を超えている」という意味で、ソフトウェアアップデートとは関係ないし、「今年初め」という表現もありません。

      親コメント
    • by Anonymous Coward

      追加窓が別スレッドなら、解放処理忘れでは無く、解放されない時がある感じかも。。。
      UIマルチスレッドは応答性とかメモリ使用量とか文句なしですが、トラブル再現とデバッグは非常にきつい。。。

  • by Anonymous Coward on 2015年08月22日 7時59分 (#2868636)

    原因 → メモリリーク
    結果 → メモリ不足

    こうではないですか?
    部門の方はリークって書いているのに...。

    • by Anonymous Coward on 2015年08月22日 10時07分 (#2868670)

      メモリリークがあっても十分にメモリがあれば大丈夫と思ってるんじゃないですかね。

      slashdotでは「FAA System Runs Out of Memory」とあります。これを和訳したのでしょう。
      これは正しいですが、和訳するときに間違えたのでしょう。
      意訳するときに、上記のようにメモリリークがあっても十分にメモリがあれば大丈夫という
      思い込みがあれば、このように間違った意訳をしてしまうかもしれません。

      親コメント
      • 「機能不全の原因」としてはどっちもあり

        たとえば、整備不良→ブレーキ故障→事故なら
        「事故の原因は整備不良」「事故の原因はブレーキ故障」どっちでもおかしくはないでしょう。

        --
        うじゃうじゃ
        親コメント
        • by Anonymous Coward

          メモリ不足ならメモリを増やせばいいが
          メモリリークならメモリの使用を見直すしかない
          普通は対処しなければならない手法がわかるよう記載する

          > 「事故の原因は整備不良」「事故の原因はブレーキ故障」どっちでもおかしくはないでしょう。

          なのでおかしい
          整備不良とブレーキ故障の因果関係があるからといって整備不良が原因とはならない
          風が吹けば桶屋が儲かると似たようなもの

          例 タンクに穴が開く→ガスケツ→エンスト

          A「ガスケツで車が動きません」
          B「じゃあガソリン入れとけ」
          A「ガソリンつぎ足しましたがガスケツで車が動きません」
          B「そんなばかな」
          A「やっぱタンクに穴が開いてたらいくら入れたってムリっすよね」

          #状況がわかってない人がよくやる必要な情報を伝えることができない例

          • 別に読んだ人が解決しなきゃいけないわけでもないし、あくまで見出しであって詳細は別に書かれてるんだからそこまでこだわらんでも(;´∀`)

            --
            うじゃうじゃ
            親コメント
            • by Anonymous Coward

              僕もあなたと同じ感覚を持っていて、どちらも自然に読めるのだけれど、
              最近の揚げ足取りの風潮から、初動の印象はとても大事です。

              最初の一発で誰を悪者にするかで、その後の展開がずいぶん違う。
              要は分析力、洞察力不足なのに批判力だけは強い人が多いのだけれど。

          • by Anonymous Coward
            まぁ、エンストはエンジンストールの略で
            ガス欠でエンジンが止まったのはエンストって言わないんですけどね。
            • by Anonymous Coward

              (エンジンストップじゃなかったのか…)

        • by Anonymous Coward

          「不足」という言葉には、どこかに「十分」レベルがあり、それよりも少なかったというニュアンスがあります。

          しかし、メモリリークが原因なら、「十分」レベルはどこにもありません。
          どんなに大量のメモリを用意しても、いずれは使い切ってしまいますから。

          なので、「不足」という言葉は不適切だと思います。

          • by Anonymous Coward

            何言ってんの。
            毎日再起動すれば問題ないじゃん。

    • by Anonymous Coward

      ??「メモリ不足ならツクモで買って足すしかないよね、しかたないね」

      • by Anonymous Coward
        ツクモだと不良品をつかまされて「相性保障がないからもう一度購入して」と言われますよ。
        • by Anonymous Coward

          交換保証を付けたいから、メモリモジュールと液晶はツクモなんじゃないかと

  • by Anonymous Coward on 2015年08月22日 11時21分 (#2868702)

    これでだいたい解決するんじゃね?

    • Re:1日1回再起動 (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2015年08月22日 11時46分 (#2868710)

      「フライト中ではありますが、本機はただいまより再起動するのですべての機能が停止します。墜落する前に復旧完了する予定ですので問題ありません」

      親コメント
      • by copper (2040) on 2015年08月22日 23時10分 (#2868976) 日記

        マジレスしておくと、機体の制御系もエンジンも2重系で2台以上積んでるから、1つずつの再起動は可能。

        親コメント
        • by Anonymous Coward

          おおぉ、空飛ぶ航空管制センター!!

          というかクラウドベース(スペクトラム基地)?

      • by Anonymous Coward

        民間機は空中給油機能がないから、余程頻繁に再起動が必要でない限り、給油着陸時に再起動すれば間に合うだろう。
        問題は軍用機で、整備上・政治的理由等で地球を1/4周程を往還する爆撃機で爆弾満載の往路や、地球最後の日に飛行する予定の国家空中作戦センター機(例:E-4Bナイトウォッチ)が再起動が必要では困るだろうな。
        特に後者は退役も検討された様だが、中共がDF-41(東風41 MIRV車両移動型ICBM 弾頭10基 射程12000km)やJL-2(巨浪2号 SLBM 3個以上のMIRV 射程8000km以上)の実用化配備が迫っている以上、相当任務機は装備され続けるのでは?

        • by Anonymous Coward

          Windows Updateがバックグラウンドでパッチ適用しちゃって操縦中にいきなり再起動ウィンドウが……

          # 念のため言っておくとネタなのでAC

      • by Anonymous Coward

        ついにUnixもWindows相当になったということですね。

    • B787型機 [reuters.com]

      親コメント
    • by Anonymous Coward on 2015年08月22日 13時11分 (#2868739)

      再起動したら、そのまま動かなくなる可能性も。

      #動いているものには触れるな

      親コメント
      • by Anonymous Coward

        電気設備の法定点検で帰ってこなくなったサーバーが何台あったかお題にするのも良いかもしれない。

        # ヤバイのでAC

  • by Anonymous Coward on 2015年08月22日 8時28分 (#2868639)

    Free() after assignment, please.

    • by Anonymous Coward

      JavaなどのGCのある言語で、参照を消し忘れたに一票。

      • by Anonymous Coward

        static Map<LoginInfo,Dialog>で、new LoginInfo("user1").equals(new LoginInfo("user1"))=falseな実装なんて、いくらでもあるよなー。

      • by Anonymous Coward

        C言語では配列にゴミが残っていても(長さを管理していれば)別に問題ないが、Javaでは配列の使わなくなった要素にはnullを代入しないと参照が残ってGCされないというのは盲点だった。

  • by Anonymous Coward on 2015年08月22日 9時20分 (#2868659)

    ちょっとした図表入りでもたかだか10MBとか20MBそこらのワープロ文書を作成するのにメモリ10GB搭載マシンを使う今日この頃
    数値シミュレーションするのにメモリ不足など気にせず、ジャブジャブとリソース使いまくりのお気楽プログラミングが出来るのはハッピーだ

    だが長時間連続運転する計測制御システムみたいな製品を作る時にメモリーリークとかがあったら怖い
    短時間のテストではメモリ不足に気がつくはつずがない

    ああ、そうか、メモリは有り余っているから仮想マシンを2つ動かして片方はホットスタンバイ状態にしておく
    もう一方がメモリ不足になったらマシンを切り替えて処理継続、その間にメモリ不足の方はリセットして次の切り替えに備えてスタンバイしておけば良いのか.......

    • by Anonymous Coward

      普通(日本の航空管制システムの場合ですが)、人命に関わる事でもあり、開発したシステムは利用者(航空管制官(業務)、航空管制技術官(システム))の習熟も兼ねて何か月も評価してから、システム切替えします。航空大国である米国ではいきなり切替えしても大丈夫、という事なのでしょうか。

      もしかして、今回のケースではシステム評価期間中に頻繁にシステムアップデートしていて長期運用試験はやってないけど、やった事にしてたとか。(異国の開発者の皆様お疲れ様です。・・・本当の地獄はこれからだ?)

      • by Anonymous Coward

        数ヶ月程度では顕在化しないような問題だったのかも。

        • by Anonymous Coward

          実際、稼働後5年経って発生なんて障害、多々あるしね。
          でも、ロングランテストならリソース状況くらい毎日確認する…つーか、それがなければロングランの意味がないと思うんだけどなあ。

          • by Anonymous Coward

            知ってる限りだと、ログの行数(通し番号)が21億ちょっとを越えたところで死んだシステムってのがあってな
            毎日平均で40万件弱ぐらいの処理をやってて、稼働15周年を目前にフリーズしてみんなで慌てたことがあったなぁ

            # 符号つき32bitの最大値越えてオーバーフロー

            • by Anonymous Coward

              ある値が増え続ける場合、最大いくつか、行ったらどうするかってのは、基本設計だよなあ。
              と言いつつ、特定のウインドウを上げて落としてるだけである連番が桁溢れ(3桁)して、障害通知された例が最近あった。
              普通に使ってれば10も行かないので、誰も気にしてなかったのかどうなのか。
              保守で入った人間には分からん。

              • by Anonymous Coward

                おっと、UNIX time の悪口はそこまでだ。

    • by Anonymous Coward

      真に富豪的なら、動的に取得解放を繰り返さず、静的に一括して取っておけばよいのではないだろうか?

      • by Anonymous Coward

        1日1台ずつ使い捨てでいいんじゃない?

    • by Anonymous Coward
      一方ロシアはアセンブラでシステムを組んで4重化した
    • by Anonymous Coward
      VMwareFTの様なホットスタンバイだったら、いざと言うときにスタンバイ側もメモリ不足を起こしていたりして…。 :-)
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...