プログラマーとエンジニアの昔話（前編）

これは、バグが時々まったく信じられない症状を引き起こすという、インターネット上の記事を集めたものです。 もしかしたらあなたにも何か言いたいことがあるかもしれません。

バニラアイスクリームに対する自動車アレルギー

明白なことが必ずしも答えであるとは限らず、事実がどれほど現実離れしているように見えても、それでも事実であることを理解しているエンジニアのための物語です。 ゼネラルモーターズ社のポンティアック部門は、次のような苦情を受け取りました。

あなたに手紙を書くのはこれで XNUMX 回目ですが、返事をしなかったことであなたを責めるつもりはありません。クレイジーに聞こえるからです。 私たちの家族は毎晩夕食後にアイスクリームを食べる伝統があります。 アイスの種類は毎回変わりますが、夕食後に家族全員でどのアイスを買うか選んでからお店に行きます。 最近新しいポンティアックを購入したのですが、それ以来、アイスクリームを買いに行くのが問題になりました。 ほら、バニラアイスクリームを買って店から帰ってくると、いつも車が始動しません。 他のアイスクリームを持っていれば問題なく車は動きます。 どんなに愚かに聞こえるかもしれないが、私は真剣な質問をしたいのです。「ポンティアックの、バニラアイスクリームを持ってくると始動しないのに、別のフレーバーのアイスクリームを持ってくると簡単に始動するのはなぜですか？」

ご想像のとおり、部門長はその手紙に懐疑的でした。 ただし、念のためエンジニアを派遣して確認させました。 彼は、美しい地域に住む裕福で教育を受けた男性が出会ったことに驚きました。 彼らは、二人でアイスクリームを買いに店に行くことができるように、夕食後すぐに会うことに同意しました。 その夜は普通の天気だったが、車に戻るとエンジンがかからなかった。

技師はさらに三晩やって来た。 初めてのアイスクリームはチョコレートでした。 車が発進した。 XNUMX回目はストロベリーアイスクリームでした。 車が発進した。 XNUMX日目の夜、彼はバニラを飲むように頼みました。 車は始動しませんでした。

エンジニアは合理的に推論して、車がバニラアイスクリームに対するアレルギーがあるとは信じませんでした。 したがって、私は車の所有者に、問題が解決するまで訪問を続けることに同意しました。 そして途中で、彼はメモを取り始めました。時間、ガソリンの種類、店に到着して帰った時間など、すべての情報を書き留めました。

エンジニアはすぐに、車の所有者がバニラアイスクリームを買うのに費やす時間が減ったことに気づきました。 その理由は店内の商品の配置にありました。 バニラアイスクリームが一番人気で、見つけやすいように店の前の別の冷凍庫に保管されていました。 他の品種はすべて店の奥にあり、適切な品種を見つけて支払うまでにさらに時間がかかりました。

さて、エンジニアにとっての疑問は、エンジンを切ってから時間が経っていないのに、なぜ車が始動しなかったのかということです。 問題はバニラアイスクリームではなく時間だったため、エンジニアはすぐに答えを見つけました。それはガスロックでした。 それは毎晩起こりましたが、車の所有者がアイスクリームを探すのにもっと時間を費やしたところ、エンジンはなんとか十分に冷えて、簡単に始動できました。 そして、男性がバニラアイスクリームを買ったとき、エンジンはまだ熱すぎて、ガスロックが解ける時間がありませんでした。

教訓: 完全にクレイジーな問題であっても、時には現実になることがあります。

クラッシュバンディクー

これを経験するのは苦痛です。 プログラマは、自分のコードを第一、第二、第三…と非難することに慣れており、XNUMX万位のどこかでコンパイラのせいにすることになります。 そして、リストのさらに下の方では、すでに機器が原因であることがわかります。

これがハードウェアのバグに関する私の話です。

ゲーム「クラッシュ バンディクー」のために、メモリ カードにロードして保存するコードを書きました。 独りよがりなゲーム開発者にとって、それは公園を散歩するようなものでした。作業には数日かかるだろうと思っていました。 しかし、結局コードを XNUMX 週間デバッグすることになりました。 途中で他の問題も解決しましたが、数日ごとに数時間このコードに戻りました。 苦痛でした。

症状は次のようなものでした。ゲームの現在のプレイスルーを保存してメモリ カードにアクセスすると、ほとんどの場合、すべてがうまくいきます。しかし、明らかな理由もなく読み取りまたは書き込み操作がタイムアウトになる場合があります。 短時間の録音では、メモリカードが損傷することがよくあります。 プレイヤーが保存しようとすると、保存に失敗するだけでなく、マップも破壊されます。 くだらない。

しばらくして、ソニーのプロデューサーであるコニー・バスがパニックになり始めました。 このバグを抱えたままゲームを出荷することはできず、1 週間経っても問題の原因がわかりませんでした。 コニーを通じて、私たちは他の PSXNUMX 開発者に連絡しました。誰か同じようなことに遭遇した人はいますか? いいえ。 メモリカードに問題があった人はいませんでした。

デバッグのアイデアがない場合、残された唯一のアプローチは「分割統治」です。問題の原因となる比較的小さな断片が残るまで、欠陥のあるプログラムからコードをどんどん削除していきます。 つまり、バグを含む部分が残るまでプログラムを少しずつ切り取っていきます。

しかし、問題は、ビデオゲームからチャンクを切り出すのが非常に難しいということです。 重力をエミュレートするコードを削除した場合、どうやって実行すればよいでしょうか? それともキャラクターを描くのでしょうか？

したがって、モジュール全体を、何か役に立つことをしているように見せかけて、実際にはエラーを含むことができない非常に単純なことを行うスタブに置き換える必要があります。 ゲームが少なくとも機能するためには、そのような松葉杖を作成する必要があります。 これは時間がかかり、痛みを伴うプロセスです。

要するに、やりました。 ゲームを実行するためのシステムの構成やレンダリング ハードウェアの初期化などを行う最初のコードが残るまで、コードをどんどん削除していきました。 もちろん、この段階では、すべてのグラフィックス コードのスタブを作成する必要があるため、保存とロードのメニューを作成することはできませんでした。 しかし、(目に見えない) 保存およびロード画面を使用してユーザーになりすまして、保存してからメモリ カードに書き込むように要求することはできます。

このため、上記の問題がまだ残っている小さなコードが残っていますが、それでもランダムに発生していました。 ほとんどの場合、すべてが正常に機能しましたが、場合によっては不具合が発生することがありました。 ほぼすべてのゲームコードを削除しましたが、バグはまだ生きていました。 これは不可解でした。残りのコードは実際には何もしていませんでした。

ある時点、おそらく午前XNUMX時頃、ある考えが私に浮かびました。 読み取りおよび書き込み (入力/出力) 操作には、正確な実行時間が関係します。 ハード ドライブ、メモリ カード、または Bluetooth モジュールを操作する場合、読み取りと書き込みを担当する低レベル コードがクロック パルスに従って読み取りと書き込みを行います。

クロックの助けを借りて、プロセッサに直接接続されていないデバイスは、プロセッサ上で実行されているコードと同期されます。 クロックはボーレート、つまりデータが送信される速度を決定します。 タイミングに混乱がある場合は、ハードウェアまたはソフトウェアのいずれか、またはその両方も混乱しています。 データが破損する可能性があるため、これは非常に悪いことです。

コード内の何かがタイミングを混乱させたらどうなるでしょうか? テスト プログラム コードでこれに関連するすべてを確認したところ、PS1 のプログラマブル タイマーを 1 kHz (1000 秒あたり 100 ティック) に設定していることに気付きました。 これは非常に多く、デフォルトでは、コンソールの起動時に XNUMX Hz で実行されます。 そして、ほとんどのゲームはこの周波数を使用します。

ゲーム開発者のアンディは、動きがより正確に計算されるようにタイマーを 1 kHz に設定しました。 アンディはやりすぎる傾向があります。重力をエミュレートする場合は、可能な限り正確に実行します。

しかし、タイマーの速度を上げると、プログラム全体のタイミング、つまりメモリ カードのボー レートを制御するクロックに影響が出るとしたらどうなるでしょうか?

タイマーコードをコメントアウトしました。 エラーは再度発生しませんでした。 ただし、障害はランダムに発生したため、修正したことを意味するものではありません。 ただ幸運だったらどうなるでしょうか？

数日後、テスト プログラムを再度試してみました。 バグは再発しませんでした。 完全なゲーム コードベースに戻り、メモリ カードにアクセスする前にプログラマブル タイマーが元の値 (100Hz) にリセットされ、その後 1kHz にリセットされるようにセーブおよびロード コードを修正しました。 もう衝突はありませんでした。

しかし、なぜこれが起こったのですか？

再びテストプログラムに戻りました。 1kHzタイマーでエラーが発生するパターンを調べてみました。 最終的に、誰かが PS1 コントローラーでプレイするとエラーが発生することに気付きました。 私自身はこれを行うことはめったにありませんが、コードの保存と読み込みをテストするときに、なぜコントローラーが必要なのでしょうか? - 私はこの依存にさえ気づきませんでした。 しかしある日、アーティストの XNUMX 人が私のテストが終わるのを待っていて、おそらくその瞬間、私は悪態をついていたでしょうが、緊張しながら手の中でコントローラーを回しました。 エラーが発生しました。 「待って、何ですか？！」 よし、もう一度やってみろ！」

これら XNUMX つのイベントが相互に関連していることに気づいたとき、エラーを簡単に再現できました。メモリ カードへの記録を開始し、コントローラを動かし、メモリ カードを破損しました。 私にはそれはハードウェアのバグのように見えました。

私はコニーのところに来て、自分の発見について話しました。 彼女はその情報を PS1 を設計したエンジニアの XNUMX 人に伝えました。 「それは不可能です」と彼は答えました。「ハードウェアの問題であるはずがありません。」 私はコニーに会話をアレンジしてくれるように頼んだ。

エンジニアが私に電話して、彼の片言の英語と私の（非常に）片言の日本語で議論しました。 最後に私は、「コントローラーを動かすとバグが発生する 30 行のテスト プログラムを送信させてください。」と言いました。 彼は同意した。 それは時間の無駄で、新しいプロジェクトに取り組むのにとても忙しかったが、私たちはソニーにとって非常に重要な開発者なので譲歩すると言いました。 私はテストプログラムをクリーンアップして彼に送りました。

次の晩（私たちはロサンゼルスにいて、彼は東京にいました）彼は私に電話して、恥ずかしそうに謝りました。 それはハードウェアの問題でした。

バグが正確に何だったのかはわかりませんが、ソニー本社で聞いたところによると、タイマーを十分に高い値に設定すると、タイマークリスタルの近くのマザーボード上のコンポーネントに干渉するそうです。 そのうちの XNUMX つはメモリ カードのボー レート コントローラーで、コントローラーのボー レートも設定します。 私はエンジニアではないので、何か間違っているかもしれません。

しかし、結局のところ、マザーボード上のコンポーネント間に干渉があったということです。 また、1 kHz でタイマーを実行してコントローラー ポートとメモリ カード ポートを介してデータを同時に送信すると、ビットが失われ、データが失われ、カードが損傷しました。

悪い牛

1980 年代、私の指導者であるセルゲイは、ソビエトの PDP-1800 のクローンである SM-11 用のソフトウェアを作成しました。 このマイクロコンピュータは、ソ連の重要な交通拠点であるスヴェルドロフスク近くの鉄道駅に設置されたばかりです。 新しいシステムは、ワゴンと貨物の交通を経路指定するように設計されました。 しかし、ランダムなクラッシュやクラッシュを引き起こす迷惑なバグが含まれていました。 転倒はいつも誰かが夕方帰宅するときに起こりました。 しかし、翌日の徹底的な調査にもかかわらず、コンピュータはすべての手動テストと自動テストで正しく動作しました。 これは通常、特定の条件下で発生する競合状態またはその他の競合バグを示します。 深夜の電話にうんざりしていたセルゲイさんは、原因を究明し、まず操車場のどのような状況がコンピューターの故障につながったのかを理解することにした。

まず、すべての原因不明の転倒の統計を収集し、日付と時刻ごとにグラフを作成しました。 パターンは明らかでした。 さらに数日間観察した後、セルゲイは将来のシステム障害の時期を簡単に予測できることに気づきました。

彼はすぐに、混乱が発生したのは、駅がウクライナ北部とロシア西部から近くの屠殺場に向かう大量の牛を仕分けしているときだけだったということを知った。 屠殺場はカザフスタンに近いカザフスタンの農場から供給されていたため、これ自体が奇妙だった。

チェルノブイリ原子力発電所は 1986 年に爆発し、放射性降下物により周辺地域は住めなくなった。 ウクライナ北部、ベラルーシ、ロシア西部の広大な地域が汚染された。 到着する車両に高レベルの放射線が含まれているのではないかと考えたセルゲイは、この理論を検証する方法を開発しました。 国民が線量計を持つことは禁止されていたため、セルゲイは駅で数人の軍人に登録した。 ウォッカを何杯か飲んだ後、彼は兵士を説得して、不審な車両のXNUMX台の放射線量を測定することに成功した。 正常値の数倍に達していることが判明した。

牛は大量の放射線を放出しただけでなく、そのレベルが非常に高かったため、駅の隣の建物にあったSM-1800のメモリのランダムなビット損失が発生しました。

ソ連では食糧不足があり、当局はチェルノブイリの肉を国内の他の地域の肉と混合することを決定した。 これにより、貴重な資源を失うことなく、全体的な放射能レベルを下げることが可能になりました。 これを知ったセルゲイはすぐに移民のための書類を記入した。 そして、時間の経過とともに放射線レベルが低下すると、コンピューターのクラッシュは自然に止まりました。

パイプを通して

かつて、Movietech Solutions は、会計、チケット販売、および一般的な管理のために設計された映画館用のソフトウェアを作成していました。 主力アプリの DOS バージョンは、北米の中小規模の映画館チェーンの間で非常に人気がありました。 したがって、最新のタッチ スクリーンやセルフサービス キオスクと統合され、あらゆる種類のレポート ツールが装備された Windows 95 バージョンが発表されたとき、それがすぐに人気になったのも不思議ではありません。 ほとんどの場合、アップデートは問題なく完了しました。 現地の IT スタッフが新しい機器を設置し、データを移行し、ビジネスを継続しました。 それが続かなかった場合を除いて。 これが起こると、会社は「掃除屋」というあだ名を持つジェームズを派遣することになった。

ニックネームは極悪非道なタイプを示唆していますが、この清掃員はインストラクター、設置業者、何でも屋を組み合わせたものにすぎません。 James はクライアントのサイトで数日かけてすべてのコンポーネントを組み立て、その後さらに数日かけてスタッフに新しいシステムの使い方を教え、発生したハードウェアの問題を解決し、基本的にソフトウェアの初期段階での支援を行いました。

したがって、この多忙な時期に、ジェームズが朝オフィスに到着し、自分の机に着く前に、いつも以上にカフェインがたっぷり入ったマネージャーが出迎えたのも不思議ではありません。

「残念ですが、できるだけ早くノバスコシア州アナポリスに行ってください。」 システム全体がダウンし、エンジニアと一晩作業した後、何が起こったのかわかりません。 サーバー上のネットワークに障害が発生したようです。 ただし、それはシステムが数分間稼働した後でした。

――昔の体制には戻らなかったんですか？ - ジェームズは完全に真剣に答えましたが、心の中では驚いて目を丸くしました。

— まさにそのとおりです。IT スペシャリストは「優先順位を変更」し、古いサーバーをそのまま使用することに決めました。 ジェームス、彼らは 1950 つのサイトにシステムをインストールし、プレミアム サポートの料金を支払うだけで、現在では XNUMX 年代と同じようにビジネスを運営しています。

ジェームズはわずかに背筋を伸ばした。

- それは別の問題です。 さて、始めましょう。

アナポリスに到着したとき、彼が最初にしたことは、問題が発生した顧客の最初の劇場を見つけることでした。 空港で撮った地図では問題ないように見えましたが、目的の住所の周囲が怪しいように見えました。 ゲットーではないが、フィルム・ノワールを彷彿とさせる。 ジェームズがダウンタウンの縁石に車を停めていると、売春婦が彼に近づいてきた。 アナポリスの規模を考えると、おそらくそれは街全体で唯一の場所でした。 彼女の外見を見てすぐに、大画面でお金のためにセックスを提供した有名なキャラクターが思い出されました。 いや、ジュリア・ロバーツのことではなく、ジョン・ヴォイトのことだ [映画「ミッドナイト・カウボーイ」への言及 - 約レーン].

売春婦を送り届けた後、ジェームズは映画館に行きました。 周囲はだいぶ良くなってきましたが、まだまだ荒廃した印象が残りました。 ジェームズが心配しすぎたわけではない。 彼は以前にも悲惨な場所に行ったことがある。 そしてここはカナダで、強盗ですら財布を奪った後は「ありがとう」と礼儀正しく言うのです。

映画館の通用口はじめじめした路地にあった。 ジェームズはドアに歩いて行き、ノックしました。 すぐに軋んでわずかに開きました。

-掃除屋さんですか？ - かすれた声が中から聞こえた。

- はい、私です...すべてを直すために来ました。

ジェームズは映画館のロビーに入った。 仕方がなかったらしく、スタッフは来場者に紙のチケットを配り始めた。 これにより、より興味深い詳細は言うまでもなく、財務報告が困難になりました。 しかし、スタッフはジェームズさんを安堵の表情で迎え、すぐにサーバールームに連れて行きました。

一見したところ、すべてが順調でした。 ジェームスはサーバーにログインし、いつものように怪しい場所をチェックしました。 問題ない。 しかし、James は細心の注意を払ってサーバーをシャットダウンし、ネットワーク カードを交換し、システムをロールバックしました。 彼女はすぐに本格的に働き始めました。 スタッフはチケットの販売を再開しました。

ジェームズはマークに電話して状況を伝えた。 ジェームズがそこに留まり、何か予期せぬことが起こらないか確認したいと思うかもしれないことは想像に難くありません。 彼は階段を降りて従業員たちに何が起こったのかを尋ね始めた。 明らかにシステムは動作を停止しました。 彼らはそれをオフにしたりオンにしたりして、すべてがうまくいきました。 しかし、10分後にシステムがダウンしてしまいました。

ちょうどこの瞬間、同じようなことが起こりました。 突然、チケット発行システムがエラーをスローし始めました。 スタッフはため息をつき紙のチケットを掴み、ジェームズさんは急いでサーバールームへ向かった。 サーバーではすべてが良好に見えました。

すると従業員の一人が入ってきた。

— システムは再び動作しています。

ジェームズは何もしていないので当惑した。 より正確に言えば、システムを機能させるものは何もありません。 彼はログアウトし、電話を手に取り、会社のサポート ラインに電話しました。 すぐに同じ従業員がサーバー ルームに入ってきました。

- システムがダウンしています。

ジェームズはサーバーをちらっと見た。 色とりどりの形が織り成す興味深く見慣れたパターンが画面上で踊り、パイプが混沌と蠢き、絡み合っていた。 誰もが一度はこのスクリーンセーバーを見たことがあるでしょう。 それは美しく表現されており、文字通り催眠術にかかりました。

ジェームスがボタンを押すと、パターンが消えました。 彼は急いで切符売り場に行き、途中で戻ってくる従業員に出会った。

— システムは再び動作しています。

メンタルフェイスパームができるなら、それはまさにジェームズがやったことだ。 スクリーンセーバー。 OpenGLを使用しています。 したがって、動作中はサーバー プロセッサのすべてのリソースが消費されます。 その結果、サーバーへの各呼び出しはタイムアウトで終了します。

James はサーバー ルームに戻ってログインし、スクリーン セーバーを空白の画面を持つ美しいパイプに置き換えました。 つまり、プロセッサ リソースを 100% 消費するスクリーンセーバーの代わりに、リソースを消費しない別のスクリーンセーバーをインストールしました。 それから、自分の推測を確認するために 10 分間待ちました。

次の映画館に到着したとき、ジェームズは、スクリーン セーバーをオフにするために 800 km 飛んだところであることをマネージャーにどう説明すればよいか考えていました。

特定の月相でのクラッシュ

実話。 ある日、月の満ち欠けに依存するソフトウェアのバグが発生しました。 月の真の位相の近似値を計算するために、さまざまな MIT プログラムで一般的に使用される小さなルーチンがありました。 GLS は、このルーチンを LISP プログラムに組み込み、ファイルの書き込み時に 80 文字近くの長さのタイムスタンプを持つ行を出力します。 メッセージの最初の行が長すぎて次の行につながることは非常にまれでした。 そして、後でプログラムがこのファイルを読み取ると、呪いがかかりました。 最初の行の長さは、正確な日付と時刻、およびタイムスタンプが印刷された時点のフェーズ仕様の長さに依存します。 つまり、このバグは文字通り月の満ち欠けに依存していたということです。

初の紙版 専門用語ファイル (Steele-1983) には、前述のバグを引き起こすそのような行の例が含まれていましたが、植字機がそれを「修正」しました。 それ以来、これは「月相のバグ」として説明されています。

ただし、仮定には注意してください。 数年前、CERN (欧州原子核研究センター) の技術者は、大型電子陽電子衝突型加速器で行われた実験でエラーに遭遇しました。 コンピューターは、科学者に結果を示す前に、この装置によって生成された膨大な量のデータを積極的に処理するため、このソフトウェアが何らかの形で月の満ち欠けに敏感であるのではないかと多くの人が推測しました。 数人の絶望的なエンジニアが真実の真相に到達しました。 この誤差は、月の通過中の地球の変形による長さ 27 km の環の形状のわずかな変化によって生じました。 この物語は、「素粒子物理学に対するニュートンの復讐」として物理学の民間伝承に組み込まれており、最も単純かつ最古の物理法則と最先端の科学概念との関係の一例となっています。

トイレを流すと電車が止まる

私がこれまで聞いた中で最高のハードウェアのバグは、フランスの高速鉄道で起きたものです。 このバグにより列車に緊急ブレーキがかかるようになりましたが、これは乗客が乗車している場合に限ります。 そのたびに列車は運行を停止され検査されたが、何も見つからなかった。 その後、彼はラインに戻されたが、すぐにクラッシュして停止した。

ある検査中に、電車に乗っていたエンジニアがトイレに行った。 彼はすぐに洗い流されてしまいました、ドーン！ 緊急停止。

エンジニアは運転手に連絡して次のように尋ねました。

—ブレーキをかける直前に何をしていましたか？

- そうですね、下りで速度を落としました...

通常の運行では、列車は下り坂で何十回も減速するため、これは奇妙でした。 列車は進み、次の下り坂で運転士がこう警告した。

- ゆっくりしていきます。

何も起こらなかった。

—最後のブレーキングのときは何をしましたか？ - 運転手に尋ねた。

- そうですね...トイレにいたのですが...

- じゃあ、トイレに行って、また下に行ったときにしたことをしてください！

機関士はトイレに行き、運転手が「速度を落としています」と警告すると水を流した。 もちろん電車はすぐに止まりました。

問題を再現できるようになったので、原因を突き止める必要がありました。

XNUMX分後、彼らは、エンジンブレーキのリモコンケーブル（列車の両端にエンジンがXNUMXつずつ付いていた）が電気キャビネットの壁から外れ、トイレのプラグソレノイドを制御するリレーの上に落ちていることに気づきました...がオンになった場合、ブレーキ ケーブルに干渉が発生し、障害に対するシステムの保護には緊急ブレーキが含まれるだけでした。

FORTRANを嫌ったゲートウェイ

数か月前、私たちは本土（これはハワイでした）のネットワーク接続が非常に遅くなっていることに気づきました。 これは 10 ～ 15 分間続き、その後突然再び発生する可能性があります。 しばらくして、同僚が本土のネットワーク接続がうまくいかないと私に不満を言いました。 一般的に 動作しません。 彼は、本土のマシンにコピーする必要のある FORTRAN コードをいくつか持っていましたが、「FTP アップロードが完了するまでネットワークが十分に長く続かなかった」ため、コピーできませんでした。

はい、同僚が FORTRAN のソース コードを含むファイルを本土のマシンに FTP 送信しようとしたときに、ネットワーク障害が発生したことが判明しました。 ファイルをアーカイブしようとしました。その後、ファイルはスムーズにコピーされました (ただし、ターゲット マシンには解凍機能がなかったため、問題は解決されませんでした)。 最後に、FORTRAN コードを非常に小さな部分に「分割」し、一度に XNUMX つずつ送信しました。 ほとんどのフラグメントは問題なくコピーされましたが、いくつかのフラグメントは通過しなかったか、コピー後に通過しました。 多数の 試み。

問題のあるパッセージを調べたところ、それらには共通点があることがわかりました。つまり、それらのパッセージにはすべて、大文字の C で構成される行で始まり、終わるコメント ブロックが含まれていました (同僚が FORTRAN でコメントすることを好んでいたため)。 私たちは本土のネットワーク専門家にメールを送り、助けを求めました。 もちろん、彼らは FTP 経由で転送できない私たちのファイルのサンプルを見たいと思っていました...しかし、私たちの手紙は彼らに届きませんでした。 最後に、私たちは簡単な方法を思いつきました 説明転送不可能なファイルがどのようなものであるか。 それはうまくいきました :) [問題のある FORTRAN コメントの XNUMX つの例をここに加えてみませんか? おそらくその価値はありません！]

結局、私たちはそれを理解することができました。 最近、キャンパスの私たちの部分と本土のネットワークの間に新しいゲートウェイが設置されました。 大文字の C のビットが繰り返し含まれるパケットを送信するのは非常に困難でした。 これらのパケットのうちのほんの数個がゲートウェイのリソースをすべて占有し、他のほとんどのパケットの通過を妨げる可能性があります。 私たちはゲートウェイのメーカーに苦情を言いました...そして彼らは次のように答えました。 私たちはすでに彼のことを知っています。」 最終的には、別のメーカーから新しいゲートウェイを購入することで問題を解決しました (前者の弁護をすれば、FORTRAN プログラムを転送できないことが利点になる人もいるかもしれません!)。

難しい時

数年前、第 40 相臨床試験のコストを削減するために Perl で ETL システムの作成に取り組んでいたとき、約 000 の日付を処理する必要がありました。 そのうち 1 人はテストに合格しませんでした。 これらの日付はクライアントから提供されたデータから取得されたものであり、しばしば驚くべきものであったため、これは私にとってはあまり気になりませんでした。 しかし、元のデータを確認してみると、2011年1月2007日と30年XNUMX月XNUMX日だったことが分かりました。さっき書いたプログラムにバグがあるのか​​と思ったのですが、すでにXNUMX年も経っていたことが分かりました。古い。 ソフトウェア エコシステムに詳しくない人にとって、これは不思議に聞こえるかもしれません。 別の会社が金儲けをするという長年の決断をしたため、私のクライアントは、一方の会社が偶然導入し、もう一方の会社が意図的に導入したバグを修正するために私にお金を払ってくれました。 私の言いたいことを理解してもらうためには、最終的にバグとなった機能を追加した会社と、私が修正した謎のバグの一因となったその他の興味深い出来事について話す必要があります。

古き良き時代には、Apple コンピュータの日付が自動的に 1 年 1904 月 1 日にリセットされることがありました。 理由は単純で、日付と時刻を把握するために電池で動く「システムクロック」を使用していたからです。 バッテリーが切れたらどうなりましたか? コンピューターは、エポックの開始からの秒数によって日付を追跡し始めました。 エポックとは、基準となる元の日付を意味し、Macintosh の場合は 1904 年 XNUMX 月 XNUMX 日でした。バッテリーが切れると、現在の日付は指定された日付にリセットされました。 しかし、なぜこんなことが起こったのでしょうか？

以前、Apple は元の日付からの秒数を保存するために 32 ビットを使用していました。 1 ビットは 0 つの値 - 00 または 01 のいずれかを保存できます。 10 ビットは 11 つの値の 000 つを保存できます: 001、010、011、100。 101 ビット - 110 つの値のうち 111 つを保存できます: 32、232、4、294、967 、296、136、2040など。 また、0 には XNUMX の値のうちの XNUMX つ、つまり XNUMX 秒を保存できます。 Apple の日付の場合、これは約 XNUMX 年に相当するため、古い Mac では XNUMX 年以降の日付を処理できません。 また、システム バッテリーが切れると、日付はエポックの開始から XNUMX 秒にリセットされ、コンピューターの電源を入れるたびに (または新しいバッテリーを購入するまで) 日付を手動で設定する必要があります。

ただし、日付をエポックからの秒数として保存するという Apple の決定は、エポックより前の日付を処理できないことを意味し、後で説明するように広範囲にわたる影響を及ぼしました。 Apple が導入した機能はバグではありません。 とりわけ、これは、Macintosh オペレーティング システムが「ミレニアム バグ」の影響を受けないことを意味しました (これは、制限を回避するために独自の日付システムを備えている多くの Mac アプリケーションについては言えません)。

どうぞ。 Apple コンピュータにはパーソナル コンピュータを成功に導いた VisiCalc が搭載されていましたが、私たちは PC 革命の立ち上げに貢献した IBM の「キラー アプリケーション」である Lotus 1-2-3 を使用しました。 公平に言えば、1-2-3 が登場していなかったら、PC はほとんど普及せず、パーソナル コンピュータの歴史は大きく異なった発展をしていたかもしれません。 Lotus 1-2-3 は、1900 年をうるう年として誤って扱いました。 Microsoft が最初のスプレッドシート Multiplan をリリースしたとき、市場の小さなシェアを獲得しました。 そして、Excel プロジェクトを立ち上げたとき、行と列の命名スキームを Lotus 1-2-3 からコピーするだけでなく、1900 年を意図的​​にうるう年として扱うことでバグ互換性を確保することも決定しました。 この問題は現在でも存在しています。 つまり、1-2-3 ではこれはバグでしたが、Excel では、たとえデータが間違っていたとしても、すべての 1-2-3 ユーザーがデータを変更せずにテーブルを Excel にインポートできるようにするための意識的な決定でした。

しかし、別の問題がありました。 まず、Microsoft が Macintosh 用に Excel をリリースしましたが、この Excel では 1 年 1904 月 1 日より前の日付は認識されませんでした。また、Excel では、1900 年 XNUMX 月 XNUMX 日が時代の始まりとみなされていました。 したがって、開発者は、プログラムが時代の種類を認識し、目的の時代に応じてデータをプログラム内に保存するように変更を加えました。 Microsoft もこれに関する説明記事を書きました。 そして、この決定が私のバグを引き起こしました。

私の ETL システムは、Windows で作成された Excel スプレッドシートを顧客から受け取りましたが、Mac で作成することもできます。 したがって、表内の元号の始まりは、1 年 1900 月 1 日または 1904 年 XNUMX 月 XNUMX 日のいずれかになる可能性があります。 どうやって調べますか？ Excel ファイル形式には必要な情報が表示されますが、私が使用したパーサーではそれが表示されず (現在は表示されています)、特定のテーブルのエポックがわかっていると想定していました。 Excel のバイナリ形式を理解し、パーサーの作成者にパッチを送信するのにもっと時間を費やすこともできたかもしれませんが、クライアントのためにやるべきことがたくさんあったため、エポックを決定するためのヒューリスティックを急いで作成しました。 彼女は単純だった。

Excel では、5 年 1998 月 07 日の日付は、「05-98-5」(役に立たないアメリカのシステム)、「98 年 5 月 1998 日」、「5 年 98 月 8601 日」、「35981 年 1900 月 34519 日」、または別の形式、別の役に立たない形式 (皮肉なことに、私のバージョンの Excel が提供していない形式の 1904 つは ISO 4 でした)。 ただし、テーブル内では、フォーマットされていない日付が、エポック 1904 の場合は「XNUMX」、エポック XNUMX の場合は「XNUMX」として保存されています (数字はエポックからの日数を表します)。 シンプルなパーサーを使用して書式設定された日付から年を抽出し、次に Excel パーサーを使用して書式設定されていない日付から年を抽出しました。 両方の値が XNUMX 年異なる場合、epoch-XNUMX のシステムを使用していることがわかりました。

なぜフォーマットされた日付を使用しなかったのですか? 5 年 1998 月 98 日は、日付を除いて「XNUMX 年 XNUMX 月」として書式設定できるためです。 非常に多くの企業からさまざまな方法で作成されたテーブルを受け取ったため、日付を把握するのは私たち (この場合は私) の役目でした。 それに、Excel が正しく理解しているのであれば、私たちもそうすべきです。

同時に 39082 に遭遇しました。Lotus 1-2-3 では 1900 年をうるう年とみなしており、これが Excel でも忠実に繰り返されたことを思い出してください。 そして、これにより 1900 年に 39082 日追加されるため、多くの日付計算関数がまさにその日に関して間違っている可能性があります。 つまり、1 は、2011 年 31 月 2006 日 (Mac の場合) または 2011 年 1900 月 2006 日 (Windows の場合) である可能性があります。 私の「年パーサー」がフォーマットされた値から 5 年を抽出した場合は、すべて問題ありません。 ただし、Excel パーサーは使用されているエポックを認識しないため、デフォルトでエポック XNUMX が設定され、XNUMX 年が返されます。 私のアプリケーションは、その差が XNUMX 年であることを認識し、それをエラーとみなしてログに記録し、フォーマットされていない値を返しました。

これを回避するために、私はこれを書きました (疑似コード):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

そして、40 件の日付がすべて正しく解析されました。

大量の印刷ジョブの途中

1980 年代初頭、私の父は、テープ ドライブと高速テープ送り用の空気圧システムを開発した、今はなき部門であるストレージ テクノロジーで働いていました。

彼らは、中央の XNUMX つの「A」ドライブを XNUMX つの「B」ドライブに接続できるようにドライブを再設計し、「A」ドライブを制御する RAM 内の小さな OS が読み取りおよび書き込み操作をすべての「B」ドライブに委任できるようにしました。

ドライブ「A」を起動するたびに、オペレーティング システムをメモリにロードするために、「A」に接続されている周辺ドライブにフロッピー ディスクを挿入する必要がありました。 それは非常に原始的なもので、計算能力は 8 ビット マイクロコントローラーによって提供されていました。

このような機器の対象者は、大量の住所ラベルや銀行取引明細書を印刷する必要がある、銀行や小売チェーンなど、非常に大規模なデータ ウェアハウスを持つ企業でした。

あるクライアントが問題を抱えていました。 印刷ジョブの途中で、特定のドライブ「A」が動作を停止し、ジョブ全体が停止する可能性があります。 ドライブの動作を復元するには、スタッフはすべてを再起動する必要がありました。 そして、これが XNUMX 時間のタスクの途中で発生した場合、膨大な量の高価なコンピュータ時間が失われ、作業全体のスケジュールが混乱します。

技術者はストレージテクノロジーズから派遣された。 しかし、最善の努力にもかかわらず、テスト条件下ではバグを再現できませんでした。このバグは大規模な印刷ジョブの途中で発生したようです。 問題はハードウェアではなく、RAM、マイクロコントローラー、フロッピードライブ、テープドライブの考えられるすべての部品など、できる限りすべてを交換しましたが、問題は解決しませんでした。

その後、技術者は本社に電話し、専門家に電話しました。

専門家は椅子とコーヒーを手に取り、コンピューター室（当時はコンピューター専用の部屋がありました）に座り、スタッフが大量の印刷ジョブを順番に並べるのを眺めました。 専門家は障害が発生するのを待っていましたが、実際に障害が発生しました。 誰もが専門家に注目しましたが、彼にはなぜこれが起こったのか分かりませんでした。 そこで彼は、その仕事を再びキューに入れるよう命令し、すべてのスタッフと技術者が仕事に戻りました。

専門家は再び椅子に座り、失敗を待ち始めました。 約XNUMX時間が経過したところで障害が発生しました。 専門家は、すべてが人で満たされた部屋で起こったこと以外には何も考えていませんでした。 彼はミッションを再開するよう命令し、座って待った。

XNUMX 回目の失敗までに、エキスパートは何かに気づきました。 この障害は、担当者が外部ドライブ内のテープを交換したときに発生しました。 さらに、従業員の XNUMX 人が床の特定のタイルを通過した直後に障害が発生しました。

高床はアルミニウムタイルでできており、高さは 6 ～ 8 インチであった。 重要なケーブルを誤って踏んでしまうのを防ぐため、コンピューターからの多数のワイヤーが上げ床の下を通っていました。 高床の下に破片が入らないように、タイルは非常にしっかりと敷かれていました。

専門家はタイルのXNUMX枚が変形していることに気づきました。 従業員がその角を踏んだ際、タイルの端が隣のタイルと擦れた。 タイルを接続するプラスチック部品もタイルと擦れて、静電気の微小放電が発生し、無線周波数の干渉が発生しました。

現在、RAM は無線周波数干渉からよりよく保護されています。 しかし、当時はそうではありませんでした。 専門家は、この干渉によりメモリが中断され、それに伴ってオペレーティング システムの動作も中断されることに気づきました。 彼はサポート サービスに電話し、新しいタイルを注文し、自分で設置したところ、問題は解消されました。

満潮だ！

この物語は、ポーツマスのオフィス (だと思う) の XNUMX 階か XNUMX 階の埠頭エリアにあるサーバー ルームで起こりました。

ある日、メインデータベースを備えた Unix サーバーがクラッシュしました。 彼らは彼を再起動させましたが、彼は喜んで何度も何度も倒れ続けました。 私たちはサポートサービスの担当者に電話することにしました。

サポートの人…彼の名前はマークだったと思いますが、それは問題ではありません…私は彼のことを知らないと思います。 本当に、それは問題ではありません。 マークの話は続けましょう、いいですか？ 素晴らしい。

それで、数時間後、マークが到着し（リーズからポーツマスまではそれほど遠くありません）、サーバーの電源を入れたところ、すべてが問題なく動作しました。 典型的なひどいサポートでは、クライアントはこれに非常に腹を立てます。 マークはログ ファイルを調べましたが、不都合な点は何も見つかりませんでした。 それでマークは電車に戻り（あるいは彼が到着した交通手段が何であれ、私が知っている限りではそれは足の不自由な牛だった可能性があります...とにかく、それは問題ではありません、いいですか？）、浪費した後、リーズに戻りますその日。

その同じ夜、サーバーは再びクラッシュしました。 話は同じです…サーバーが上がらないのです。 マークはリモートで支援しようとしますが、クライアントはサーバーを起動できません。

また電車、バス、レモンメレンゲ、その他のくだらないことを繰り返すと、マークはポーツマスに戻ってきます。 サーバーは問題なく起動しています。 奇跡。 マークは数時間かけてオペレーティング システムやソフトウェアがすべて正常に動作していることを確認し、リーズに向けて出発します。

正午頃にサーバーがクラッシュします（落ち着いてください！）。 今回は、サーバーを交換するためにハードウェア サポート担当者を呼び込むのが合理的だと思われます。 しかし、いいえ、約 10 時間後には低下します。

この状況が数日間繰り返されました。 サーバーは動作しますが、約 10 時間後にクラッシュし、その後 2 時間起動しません。 冷却やメモリリークなどすべてをチェックしましたが、何も見つかりませんでした。 その後、クラッシュは止まりました。

一週間は気楽に過ぎていきました…みんな幸せでした。 すべてが再び始まるまで幸せです。 絵も同じです。 作業時間は10時間、休憩時間は2～3時間。

そして、ある人（この人はITとは何の関係もないと言われたと思います）はこう言いました。

「潮だ！」

感嘆の声には虚ろな視線が向けられ、セキュリティコールボタンを押すのをおそらく誰かの手がためらったのだろう。

「潮の流れとともに機能しなくなります。」

これは、コーヒーを飲みながら座って Tide Yearbook を読む可能性の低い IT サポート ワーカーにとってはまったく異質な概念であるように思われます。 彼らは、サーバーは一週間故障することなく動作していたため、これは潮汐とはまったく関係ないと説明しました。

「先週は潮が引いていたが、今週は潮が高い。」

ヨット免許を持っていない人のために少し専門用語を説明します。 潮汐は月の周期によって異なります。 そして地球が自転すると、12,5 時間ごとに太陽と月の引力によって津波が発生します。 12,5 時間周期の最初に満潮があり、周期の途中で引き潮があり、最後に再び満潮になります。 しかし、月の軌道が変化すると、干潮と満潮の差も変化します。 月が太陽と地球の間にあるとき、または地球の反対側にあるとき（満月または月がないとき）、Syzygyn潮汐、つまり最も高い満潮と最も低い干潮が発生します。 半月になると、直角潮汐、つまり最も低い潮汐が得られます。 28 つの極端な値の差は大幅に減少します。 月の周期は XNUMX 日間続きます: 朔望 - 求積 - 朔望 - 求積。

技術者らが潮汐力の本質について説明されると、すぐに警察に通報する必要があると考えた。 そして非常に論理的です。 しかし、その男は正しかったことが判明しました。 XNUMX週間前、駆逐艦が事務所からそれほど遠くないところに停泊していた。 潮が一定の高さまで上昇するたびに、船のレーダーポストはサーバールームの床の高さまで到達してしまいました。 そしてレーダー (または電子戦機器、またはその他の軍事玩具) がコンピューターに混乱を引き起こしました。

ロケットの飛行ミッション

私は、大規模 (約 400 万行) のロケット発射制御および監視システムを、新しいバージョンのオペレーティング システム、コンパイラー、および言語に移植する任務を負っていました。 より正確には、Solaris 2.5.1 から Solaris 7 まで、そして Ada 83 で書かれた Verdix Ada Development System (VADS) から Ada 95 で書かれた Rational Apex Ada システムまでです。VADS は Rational によって購入され、その製品はただし、Rational は、Apex コンパイラへの移行を容易にするために、VADS 固有のパッケージの互換性のあるバージョンを実装しようとしました。

XNUMX 人の人が、コードをきれいにコンパイルするのに協力してくれました。 XNUMX週間かかりました。 そして私は自分でシステムを動作させるために取り組みました。 つまり、これは私が遭遇したソフトウェア システムのアーキテクチャと実装としては最悪だったので、移植が完了するまでにさらに XNUMX か月かかりました。 その後、システムはテストに提出されましたが、テストにはさらに数か月かかりました。 テスト中に見つかったバグはすぐに修正しましたが、その数はすぐに減りました（ソース コードは実稼働システムであったため、その機能は非常に確実に動作しました。新しいコンパイラへの適応中に発生したバグを削除するだけで済みました）。 最終的に、すべてが順調に進んだとき、私は別のプロジェクトに異動することになりました。

そして感謝祭の前の金曜日、電話が鳴った。

ロケットの打ち上げは約３週間でテストされる予定だったが、カウントダウンの実験室テスト中に一連のコマンドがブロックされた。 現実では、これによりテストは中止され、エンジン始動後数秒以内に詰まりが発生した場合、補助システムでいくつかの不可逆的な動作が発生し、ロケットの準備に長い時間がかかり、費用がかかることになります。 それは始まらなかっただろうが、多くの人は時間と多額のお金が失われたことに非常に腹を立てていただろう。 国防総省が無謀に金を使っているなどとは誰にも言わせないでください。私は、予算を第一か二目にし、次にスケジュールを優先しない契約管理者に会ったことがありません。

これまでの数か月間、このカウントダウン チャレンジはさまざまなバリエーションで何百回も実行されましたが、わずかな問題はいくつかありました。 したがって、これが起こる可能性は非常に低いですが、その結果は非常に重大でした。 これら両方の要素を掛け合わせると、このニュースが私と何十人ものエンジニアやマネージャーにとって、破滅的な休暇週間を予測していたことを理解していただけるでしょう。

そしてそのシステムを移植した人物として私に注目が集まりました。

ほとんどのセキュリティ クリティカルなシステムと同様に、多くのパラメータがログに記録されるため、システムがクラッシュする前に実行された数行のコードを特定するのは非常に簡単でした。 そしてもちろん、それらにはまったく異常な点はなく、同じ実行中に同じ式が文字通り何千回も正常に実行されていました。

私たちが Apex の人々を Rational に呼んだのは、彼らがコンパイラの開発者であり、彼らが開発したルーチンの一部が疑わしいコードで呼び出されていたためです。 彼ら（そして他の全員）は、文字通り国家的に重要な問題の根本に迫る必要があることに感銘を受けました。

ジャーナルには興味深いものが何もなかったため、私たちは地元の研究室で問題を再現してみることにしました。 このイベントは実行 1000 回に約 XNUMX 回発生するため、これは簡単な作業ではありませんでした。 考えられる理由の XNUMX つは、ベンダーが開発したミューテックス関数 (VADS 移行パッケージの一部) の呼び出しでした。 Unlock ロック解除には至りませんでした。 関数を呼び出した処理スレッドは、名目上毎秒到着するハートビート メッセージを処理しました。 周波数を10Hz、つまり10秒間に45回まで上げて走り始めました。 約 90 時間後、システムは自動的にロックされました。 ログでは、記録されたメッセージの順序が失敗したテスト時と同じであることがわかりました。 さらに数回実行しましたが、システムは開始後 XNUMX ～ XNUMX 分で一貫してブロックされ、毎回ログに同じルートが含まれていました。 技術的には異なるコードを実行していても、つまりメッセージの頻度が異なり、システムの動作は同じだったので、この負荷シナリオが同じ問題を引き起こしていると確信しました。

ここで、一連の式のどこでブロックが発生したかを正確に把握する必要がありました。

このシステムの実装では Ada タスク システムが使用されていましたが、その使用方法は信じられないほど悪かったです。 タスクは、Ada で同時に実行可能な高レベルの構造であり、実行スレッドのようなもので、言語自体にのみ組み込まれています。 XNUMX つのタスクが通信する必要がある場合、「ランデブーを設定」し、必要なデータを交換した後、ランデブーを停止して独立した実行に戻ります。 ただし、システムの実装方法は異なりました。 ターゲット タスクがランデブーされた後、そのターゲット タスクは別のタスクとランデブーし、さらにそのタスクは XNUMX 番目のタスクとランデブーするというように、何らかの処理が完了するまで繰り返されます。 この後、これらのランデブーはすべて完了し、各タスクは実行に戻らなければなりませんでした。 つまり、私たちは世界で最も高価な関数呼び出しシステムを扱っており、入力データの一部を処理している間に「マルチタスク」プロセス全体が停止してしまいました。 以前は、スループットが非常に低かったという理由だけで問題が発生しませんでした。

このタスクのメカニズムについて説明したのは、ランデブが要求されたとき、または完了が期待されたときに、「タスクの切り替え」が発生する可能性があるためです。 つまり、プロセッサは、実行の準備ができている別のタスクの処理を開始する可能性があります。 あるタスクが別のタスクとランデブーする準備ができると、まったく別のタスクが実行を開始し、最終的に制御が最初のランデブーに戻ることが判明しました。 また、タスクの切り替えを引き起こす他のイベントが発生する場合もあります。 そのようなイベントの XNUMX つは、ミューテックスの印刷や実行などのシステム関数の呼び出しです。

問題の原因となっているコード行を理解するには、タスクの切り替えをトリガーせずに、一連のステートメントの進行状況を記録する方法を見つける必要がありました。これにより、クラッシュの発生を防ぐことができます。 だから活用できなかった Put_Line()I/O 操作の実行を回避するため。 カウンタ変数などを設定することはできますが、画面に表示できない場合はどうすればその値を確認できますか?

また、ログを調査したところ、ハートビート メッセージの処理がフリーズし、プロセスのすべての I/O 操作がブロックされ、他の処理が実行できなくなったにもかかわらず、他の独立したタスクが実行され続けていたことが判明しました。 つまり、作業が完全にブロックされたのではなく、(重要な) 一連のタスクのみがブロックされました。

これは、ブロッキング式を評価するために必要な手がかりでした。

タスク、列挙型、およびその型のグローバル変数を含む Ada パッケージを作成しました。 数え切れないほどのリテラルが、問題のあるシーケンスの特定の式にバインドされていました (例: Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked) を作成し、それに対応する列挙型をグローバル変数に割り当てる代入式を挿入しました。 これらすべてのオブジェクト コードは定数をメモリに格納するだけであるため、その実行の結果としてタスクが切り替わる可能性は非常に低いです。 (いくつかの理由により) タスクを元に戻すときにブロックが返されるのではなく、実行時にブロックが発生したため、私たちはタスクを切り替える可能性のある式を主に疑っていました。

追跡タスクは単にループ内で実行され、グローバル変数の値が変更されたかどうかを定期的にチェックするだけでした。 変更するたびに、値がファイルに保存されました。 その後、少し待ってから新しい小切手を受け取ります。 問題領域でタスクを切り替えるときに、システムが実行対象としてタスクを選択した場合にのみタスクが実行されるため、変数をファイルに書き込みました。 このタスクで何が起こっても、他の無関係なブロックされたタスクには影響しません。

システムが問題のあるコードを実行する段階に達すると、次の式に進むたびにグローバル変数がリセットされることが予想されていました。 その後、タスクが切り替わる何かが起こり、その実行周波数 (10 Hz) が監視タスクの実行周波数よりも低いため、監視タスクがグローバル変数の値をキャプチャして書き込む可能性があります。 通常の状況では、列挙のサブセットの繰り返しシーケンス、つまりタスク切り替え時の変数の最後の値を取得できます。 ハングすると、グローバル変数は変更されなくなり、最後に書き込まれた値によって、どの式が完了しなかったかが示されます。

トラッキングを使用してコードを実行しました。 彼は凍りついた。 そして監視は時計仕掛けのように機能しました。

ログには予期されたシーケンスが含まれていましたが、ミューテックスが呼び出されたことを示す値によって中断されました。 Unlock、そしてタスクは完了しません - 以前の何千もの呼び出しの場合と同様です。

この時、Apex エンジニアは熱心にコードを分析し、ミューテックス内に理論的にはロックが発生する可能性がある場所を発見しました。 しかし、ブロッキングにつながる可能性があるのは、特定の時間に発生する特定の一連のイベントのみであるため、その可能性は非常に低かったです。 マーフィーの法則、皆さん、それはマーフィーの法則です。

必要なコード部分を保護するために、(OS ミューテックス機能の上に構築された) ミューテックス関数呼び出しを、その部分へのミューテックス アクセスを制御する小さなネイティブ Ada ミューテックス パッケージに置き換えました。

それをコードに挿入してテストを実行しました。 XNUMX 時間後でもコードはまだ機能していました。

私のコードは Rational に提出され、そこでコンパイル、逆アセンブルされ、問題のあるミューテックス関数で使用されていたものと同じアプローチが使用されていないことがチェックされました。

これは、私のキャリアの中で最も混雑したコード レビューでした 🙂 私と同じ部屋には約 20 人のエンジニアとマネージャーがいて、さらに XNUMX 人が電話会議中で、全員が約 XNUMX 行のコードを検査しました。

コードがレビューされ、新しい実行可能ファイルがアセンブルされ、正式な回帰テストのために提出されました。 数週間後、カウントダウンテストは成功し、ロケットは飛び立ちました。

それはそれでいいのですが、この話の要点は何でしょうか?

それはまったく嫌な問題でした。 数十万行のコード、並列実行、十数の対話プロセス、貧弱なアーキテクチャと貧弱な実装、組み込みシステム用のインターフェース、そして費やした数百万ドル。 プレッシャーはありませんね。

この問題に取り組んでいたのは私だけではありませんでしたが、移植作業を行っている私は注目を浴びていました。 しかし、たとえそれができたとしても、それは私が何十万行ものコードをすべて理解したわけではなく、さらにはざっと読んだわけでもありません。 コードとログは全国のエンジニアによって分析されましたが、障害の原因についての仮説を教えてもらったとき、私はそれを反論するのにわずか XNUMX 分かかりました。 そして、理論を分析するように頼まれたときは、他の人にそれを渡しました。なぜなら、これらのエンジニアが間違った方向に進んでいることは明らかだったからです。 おこがましいと思われますか？ はい、これは本当ですが、私は別の理由で仮説と要求を拒否しました。

問題の本質を理解しました。 どこで、なぜ起こっているのか正確にはわかりませんでしたが、何が起こっているのかはわかっていました。

長年にわたり、私は多くの知識と経験を蓄積してきました。 私は Ada を使用した先駆者の XNUMX 人であり、その利点と欠点を理解していました。 Ada ランタイム ライブラリがどのようにタスクを処理し、並列実行を処理するかを理解しています。 また、メモリ、レジスタ、アセンブラのレベルでの低レベルのプログラミングも理解しています。 言い換えれば、私は自分の分野について深い知識を持っています。 そして、それらを使用して問題の原因を見つけました。 私はただバグを回避するだけでなく、非常に機密性の高いランタイム環境でバグを見つける方法を理解しました。

このようなコードとの格闘の話は、そのような格闘の特徴や状況に詳しくない人にとってはあまり興味深いものではありません。 しかし、これらの物語は、本当に難しい問題を解決するために何が必要かを理解するのに役立ちます。

本当に難しい問題を解決するには、単なるプログラマー以上の能力が必要です。 コードの「運命」、コードがその環境とどのように相互作用するか、そして環境自体がどのように機能するかを理解する必要があります。

そして、あなたは自分自身の台無しになった休暇週を過ごすことになります。

継続するために。

出所： habr.com