プログラマーとエンジニアの民俗学（パート3）

バグが時々完全に信じられないほどの症状を示す方法についてのインターネットからの物語のコレクションの最後の部分。パート1、パート2。

（時々）できなかった小さなSSH

これは、私が参加できた幸運なことに、最もエキサイティングなバグハントの1つについての話です。



私が働いていたAdGearTechnologies Inc.では、すべてがSSHで管理されていました。ライブストリーミングでも、管理、監視、展開、ログ収集に使用しています。このプロトコルは堅牢で信頼性が高く、ネイティブUnixツールの予測可能性を備えており、正常に機能します。



しかし、特定の時間やホストの参照がない手紙が、プロトコルが機能していないことを私たちに告げたことがあります。

タイムアウト

ロンドンのデータセンターのマシンは、ログファイルをモントリオールのデータセンターに送信するときにクラッシュすることがありました。このタスクはCronから定期的に実行され、失敗は次のように現れました。

• Cronの電子メールはSSHの問題を報告しました。
  
  
  • 時々それはフリーズします。
  • タイムアウトエラーなしで終了する場合があります。
• 内部ヘルスチェックで、Nagiosはモントリオールのデータが欠落していることを警告します。

ロンドンの車にログインし、手動でコマンドpushを起動すると、正常に機能しました。私たちはそれを一時的なネットワークの問題にまで絞り込みました。

タイムアウト

しかし、クラッシュはランダムに繰り返され続けました。 1日1回、1日2回、金曜日の朝、1時間に数回。それが悪化していることは明らかでした。問題が何であるかがわかるまで、手動でファイルをプッシュし続けました。



ロンドンとモントリオールの間には17のホップがありました。パケットの遅延と損失のプロファイルを作成しました。パケットの1〜3％が2、3ホップで失われたことが判明しました。ロンドンデータセンターの運用部門と協力して、ルート変更を申請しました。



ロンドン市民がパケット損失情報をチェックしている間、私たちはロンドンから2番目に向かう途中でランダムなタイムアウトを探し始めましたモントリオールのデータセンター。このルートのホップは、パケットを失ったものではなく、異なっていました。損失は​​主な問題ではないと判断し、ロンドン市民は、パケットの損失やタイムアウトを再現できず、すべてが順調に見えたと報告しました。

黙示録

悪いCronメールを手動で転送しているときに、興味深いパターンに気づきました。ファイルは高速で正常に転送されたか、まったく転送されずにタイムアウト時にハングしました。ファイルが低速で正常にダウンロードされるケースはありません。



方程式からほとんどのデータを削除することで、単純なバニラSSHを使用してスクリプトを再作成することができました。ロンドンのデータセンターでは、「SSH mtl-machine」サーバーがタスクをすぐに完了するか、ハングして接続を確立できませんでした。驚きが大きくなり始めました。

パッケージはどこに行きましたか？

モントリオールのSSHサーバーの構成とシステムを3回チェックしました。

• DNSサーバーは迅速に応答しました。
• DNS逆引き参照ゾーンが無効になっています。
• クライアント接続の最大数は十分に大きかった。
• 私たちは攻撃されませんでした。
• チャネルは詰まっていませんでした。

さらに、何かが機能していなくても、モントリオールの2つの異なるデータセンターで作業しているとフリーズが発生します。さらに、ロンドン以外のデータセンターはモントリオールとの通信に成功しました。つまり、問題はロンドンに関連していたのです。



tcpdumpを実行し、パッケージを監視しました。Pcapsを使用して取得され、Wiresharkにロードされた一般的なダイナミクスとデータに関心がありました。パケットの損失と再送信の兆候が見られましたが、すべてが最小限であり、心配する必要はありませんでした。



次に、SSH通信が正常に確立された状況での接続全体を分析し、次に、SSH通信がハングした状況での接続を分析しました。



ロンドンからモントリオールへの接続が途絶えたとき、私たちは次の結論に達しました。

• TCP接続の確立はうまくいきました。
• サービスSSH情報がやり取りされました。必要に応じて、通常のTCPackパケットがありました。
• 特定のパッケージがロンドンから送信され、モントリオールで受信されました。
• 同じパッケージがロンドンから数回再送信され、モントリオールで受け取られました。
• モントリオールは単にこれに答えません！

モントリオールが応答しなかった理由は明らかではありませんでした（このロンドンが再びデータを送信しているため）。レイヤー4プロトコルがハングしていたため、接続がハングしました。さらにエキサイティングなのは、ロンドンで繰り返されるSSH送信を中断し、すぐに再起動すると、正常に機能するという事実です。この場合、tcpdumpは、モントリオールがパッケージを受け取り、それに応答したことを示し、作業は続行されました。



ロンドンのSSHクライアントで、詳細なデバッグ（-vvv）を有効にし、これらのログエントリの後、接続がハングしました。

debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

「SSHhangSSH2_MSG_KEX_DH_GEX_GROUP」をグーグルで検索したところ、Wi-Fiの問題からWindowsのTCPバグ、バグのあるルーターがTCPフラグメントを失うまで、多くの結果が得られました。 LANの解決策の1つは、パスのMSSを計算し、この値をルートの両端のMTUとして設定することでした。



ロンドンサーバーのMTUを1500から減らし続けました。魔法の値である576に到達するまで、それは役に立ちませんでした。その後、SSHは再びハングしませんでした。 SSHループを使用してスクリプトを実行していましたが、必要に応じて、MTUを1500に戻すことでタイムアウトを発生させるか、576を設定してタイムアウトを取り除くことができました。残念ながら、これらはパブリック広告サーバーであり、MTUを1500にグローバルに割り当てても問題は解決しません。ただし、パケットの断片化または再構築のプロセスはおそらくどこかで壊れていることはすでに前述しました。



tcpdumpを使用して受信したパケットのチェックに戻りましょう。断片化の兆候はありませんでした。受信したパケットのサイズは、送信したパケットのサイズと同じでした。何かがバイト576+でパケットを断片化した場合、何かが正常に再組み立てしていました。

きらめききらめき、カーブスター

分析を深く掘り下げていくと、tcpdump -s 0 -Xヘッダーだけでなく、完全なパケットダンプ（）を調べました。成功した送信からのマジックパケットと失敗した送信からのパケットを比較すると、TCP / IPヘッダーを除いて、ほとんど違いは見つかりませんでした。しかし、これが576バイトのマークを通過するのに十分なデータを含むTCP接続の最初のパケットであることは明らかでした。以前のパッケージはすべてはるかに小さかった。



失敗したディスパッチからの同じパケットを、ロンドンを出てモントリオールに到着した形で比較すると、私の目は何かに気づきました。微妙なことのために、そして私は疲労のためにそれを払いのけました（それは金曜日の夜遅くでした）。しかし、いくつかの更新と比較の後、私はもはや想像していませんでした。







何か気づきましたか？そうでなければ、それは大丈夫です。テキストエディタで2つのウィンドウにコピーし、それらをすばやく切り替えて、シンボルの変更を確認できます。



まあまあ。これはパケットの損失ではなく、パケットの破損です。非常にわずかな、非常に予測可能な損傷。興味深い観察：

• パケットの最初の部分（<576バイト）はそのままです。
• 16個中15バイトごとに破損しています。
• 損傷は予測可能です。すべてhがになりx、すべてcがになりましたs。

すでにASCIIテーブルを調べて、1ビットが値に固定されていると結論付けた可能性があります1。11バイトの4番目のビットに変換すると、左側の前の文字が右側の値に台無しになります。



障害にはパターン（複数のロンドンマシン→複数のモントリオールデータセンターおよびマシン）があるため、私たちの視野（NICがサーバーを受け入れる）の明らかな原因は疑う余地がありません。理由はルート上にあり、ロンドンに近いに違いありません。



状況は理にかなっているようになりました。また、冗長なtcpdumpモードのヒントにも気づきました（tcp cksum bad）、これまで気づかなかった。Montrealサーバーは、カーネルレベルのパケットが破損していることに気づき、ユーザースペースのSSHデーモンにパケットを転送しなかったため、そのパケットをドロップしました。それからロンドンはパケットを再び送りました、それは再び損害を受けました、そしてモントリオールはそれを黙って捨てました。SSHとSSHdの観点からは、接続がスタックしています。tcpdumpの観点からは、損失はなく、Montrealサーバーは単にデータを無視します。



調査結果をロンドンデータセンター運用部門に報告したところ、数分以内にアウトバウンドルートが大幅に変更されました。最初のホップとその後のホップのほとんどは異なっていました。フリーズの問題はなくなりました。



週末はリラックスして問題やサポートについて考える必要がないので、金曜日の深夜の修正は素晴らしいです:)

ウォーリーはどこですか？

この問題が発生しなくなり、システムが追いついてきたことをうれしく思い、このパケットの破損の原因となっているデバイスを見つけることにしました。



ロンドンのルートを更新してトラフィックを古いルートから遠ざけることは、問題を簡単に再現できなかったことを意味しました。ロンドンから古いルートで入手できる適切なFreeBSDマシンを持っている友人をモントリオールで見つけました。



SSHを使用しなくても、損傷が予測可能であることを確認したかったのです。私はこれをいくつかのパイプラインで簡単に管理しました。



モントリオール：

nc -l -p 4000 > /dev/null

それからロンドンで：

cat /dev/zero | nc mtl 4000

再試行サイクルのランダム性と微調整の要因を考えると、以前の結論についての疑問を払拭するいくつかのパッケージを受け取りました。パッケージの1つの一部は次のとおりです。





バグを再現して、損傷が発生した17ホップの1つを見つける必要がありました。すべてのクラスターのプロバイダーに電話して、システムをチェックするように依頼することはできませんでした。



各ルーターに順番にpingを実行することにしました。役立つ場合があります。 576バイトの安全制限を超えるのに十分な大きさの特別なICMPパケットを書き込み、ゼロで埋めました。次に、これらのパケットの助けを借りて、ロンドンからモントリオールサーバーにpingを実行しました。



パッケージはそのまま返されました。



私は速度、内容、サイズのすべての組み合わせを試しましたが、役に立ちませんでした。返されたICMPpingパケットに損傷は見つかりませんでした。



netcatパイプラインでは、TCPをUDPに置き換えました。繰り返しますが、損傷はありません。



損傷を再現するにはTCPが必要であり、TCPには2つの通信エンドポイントが必要でした。私は、すべてのルーターが直接通信できる開いたTCPポートを持っているかどうかを調べようとしましたが無駄でした。



障害のあるホップを外部から特定することは不可能のように思われました。それとも可能ですか？

壁にミラーミラー

損傷が発生したかどうかを判断するには、次のいずれかのシナリオを使用する必要がありました。

• 通信しているTCPノードを介して宛先でパケットを確認します。
  
  
  • チェックサム検証中にエラーが発生した場合にパケットが配信されないユーザースペースではありませんが、rootとtcpdumpを使用して、受信したパケットに損傷がないか確認してください。
• エコーサーバーとして機能し、受信したデータをミラーリングするTCPノードを使用して、送信ノードでパケットを確認します。

突然、2番目の測定ポイントが利用可能であることが判明しました。直接利用することはできませんが、それでも問題を解決するための最初のアプローチで、損傷を与えるホップを介してSSHサーバーと通信するときにSSHクライアントがハングすることに気付きました。これは、アクティブな「エコー」信号の代わりに使用できる優れたパッシブ信号です。



そしてこれでは、インターネット上の多数のオープンSSHサーバーによって支援することができます。



これらのサーバーに実際のアカウントは必要ありません。SSH接続を開始するだけで、暗号交換フェーズが成功するかどうかを確認できます（偶発的な損傷を考慮して妥当な回数の再試行を行います）。



計画はこれでした：

• 「ランダムIP」モードですばらしいnmapツールを使用して、地理的に分散したオープンSSHサーバーのリストを作成します。
• :
  
  
  • , → .
  • N- → «».
  • telltale N- → «».
• «» «».

私はこれを考えました：すべての「悪い」サーバーのトレースでは、いくつかの同一のホップが使用されます。疑わしいホップを分離し、「良好な」サーバーのトレースで使用されているホップを特定することができます。 1つか2つが残ることを期待して。



サーバーを手動で分類するのに1時間費やした後、データの調査を停止しました。私は16の「悪い」サーバーと25の「良い」サーバーを持っていました。



最初のステップは、不良サーバーのすべてのトレースで見つかったホップのリストを作成することでした。リストをクリーンアップした後、誤検知のホップを削除するために「良い」リストに移動する必要さえないことに気付きました。悪者は1つの共通のホップしか持っていませんでした。



ただし、その前には2つのプロバイダーがありました。ロンドン→Nホップアップストリーム1→Yホップアップストリーム2です。



これは、upstream1とupstream2の境界にあるupstream2の最初のYホップでした。ランダムなTCPパケットが破損し、多数の再送信が発生し、プロトコルデータ交換の詳細に応じて、送信量がフリーズまたは減少しました。



ロンドンのデータセンター運用部門と協力して、このホップのIPアドレスを追跡しました。アップストリーム1に直接接続することで、強制的に修正できることを期待していました。



アップストリーム1を通じて、指定したホップ（アップストリーム2の最初のホップ）に、BGPと2つの内部ネットワーク間のルーティングに影響を与える内部「制御モジュール障害」があるという確認を受け取りました。彼らは故障したデバイスを再ルーティングし、交換が完了するまでオフにしました。

ロックミュージックフィルター

ストリーミングオーディオアプリケーションのユーザーがLANエクスペリエンスをセットアップするのを手伝いました。ユーザーはクラシック音楽のみを演奏し、ロック音楽は演奏しませんでした。真剣に。クラシックはシームレスにストリーミングされ、ロックミュージックをストリーミングしようとすると、数分後に接続が切断されました。



アプリはオーディオのチャンクを受信し、ロスレス圧縮コーデックを使用してそれらを圧縮してから、各チャンクを個別のUDPパケットでエンドポイントに送信しました。必要に応じてIPv4で動作する可能性はありますが、LAN環境よりも信頼性が高いため、アプリケーションは可能な限りIPv6を使用しようとしました。



問題の原因を際限なく退屈に探した後、私はついに何が問題なのかを理解しました。どういうわけか、ユーザーはネットワークインターフェイスでMTUを1200バイトに設定しました。また、MTUが1280バイト未満の場合、IPv6はIPレベルでパケットを自動的にフラグメント化しないため、より大きなパケットを送信することはできません。ストリーミングアプリケーションは、1200バイトを超えるオーディオパケットを送信しようとし、エラーを受信して​​、切断します。



なぜこれはロックミュージックでのみ起こったのですか？簡単だ。ロスレスコーデックは可変ビットレートを使用し、クラシック音楽はロック音楽よりも圧縮されています。クラシックをストリーミングするとき、オーディオは一貫して1200バイト未満のパケットに圧縮され、ロックミュージックのパケットはランダムにこのしきい値を超えました。



ユーザーは自分のMTUが減少した理由を知りませんでした。彼はそれを必要としなかったので、値を増やしてすべてが正常に機能しました。

自己消滅するインターネットの混乱

1999年に大学に入学したとき、私はこれ以上の余裕がなかったので、古くて老朽化した学生寮に住んでいました。しかし、少なくともホステルにはかなりまともなインターネットがありましたが、それは私の国ではまだ普及していませんでした。また、建物の変更が禁止されていたため、一時的なスキームに従ってネットワークケーブル（まだ同軸）が離婚しました。彼らは廊下の偽の天井の後ろに隠され、戸口を通って部屋に引き込まれ、そこで彼らは単に床に横たわっていた。通信が途絶えると、フロア全体がネットワークなしで放置される可能性があります。私はコンピューターサイエンス学部で勉強していたので、ネットワークの経験はまったくありませんでしたが、すぐに無意識のうちにかなり頻繁な中断を修正する人になりました。



中断がプロバイダー側​​にある場合もあれば、問題がプロキシに関連している場合もありますが、多くの場合、誰かがケーブルを切断してターミネーターを挿入しなかっただけです。



ある夜、インターネットがダウンしましたが、ほんの数分でした。それから彼は再び現れたので、私はそれについてあまり考えませんでした。しかし、翌日、短い中断が繰り返され、3日目も繰り返されました。通常、それは約20時間発生し、正確な時間は変動しましたが、まったく発生しなかった場合もありました。しかし、ネットワークがダウンするたびに、私のオンサイトの電話が鳴り始め、人々はこれらの繰り返される中断にますます悩まされました。



各中断は数分しか続かなかったため、ネットワークが再表示される前に特定の場所を特定できませんでした。私は床を横切ってすべてのドアをノックして、誰かがケーブルを抜いたのか、それで何かをしたのかと尋ねようとしましたが、そのアイデアは役に立ちませんでした。最後に、信頼できるマルチメーターを手に、毎日の中断を待つことにしました。一週間以内に、私は容疑者から次々と部屋を追放した。最後に、部屋のケーブルの1つで、次の中断中に抵抗が急増していることに気づきました。



私はノックしましたが、彼らはそれを開けませんでした。城は施錠されていました。しかし、部屋にコンピューターやケーブルで何かをする人がいない場合、なぜ接続が中断されるのでしょうか。そして、なぜそれは回復しているのですか？翌日、すべてが再び起こりました、彼らは再びドアを開けませんでした。フロアの残りの部分でインターネットが機能するように、この部屋を完全にオフにすることにしました。



翌朝、その部屋の入居者からインターネットが機能していないとの連絡がありました。私は彼らのところに行き、すべてのケーブルの抵抗を測定し、すべての接続とターミネーターをチェックしました。すべてのケーブルのオームはゼロで、すべてが完璧な状態です。私はその男に昨夜何をしていたのか聞いた。私は試験の前に教科書を読みましたが、コンピューターとは何の関係もありませんでした、と彼は答えました。 2回目と3回目にすべてを再確認しましたが、問題はありませんでした。私はほとんどあきらめました、そしてそれから私は気づきました：ケーブルはベッドの下に固定されていました。もちろん、ケーブルの銅芯はこの場所で正確に壊れていましたが、シースでしっかりと保持されていたため、通常の状態では、ベッドに座っていても接触が維持されていました。しかし、私がそれを振り始めたとき、接触は押すたびに数秒間消えました。



あなた自身は、ロックされたドアの後ろで、ノックへの答えなしで、毎晩数分間そのベッドで何が起こったのかを推測することができます。

メルの話

実際のプログラマーはFortranで書き込みます

これは、非アルコールビール、計算機、「ユーザーフレンドリー」なアプリケーションの退廃的な時代に当てはまるかもしれませんが、古き良き時代には、「ソフトウェア」という用語が面白く聞こえ、Real Computersが磁気ドラムとラジオチューブでできていたと、RealProgrammersは次のように書いています。マシンコード。 FORTRANではありません。 RATFORにはありません。アセンブリ言語すらありません。マシンコード内。実際の、飾られていない、理解できない16進数について。ちょうどそのように。何世代にもわたるプログラマーは、この輝かしい過去を知らずに成長してきました。世代間のギャップを埋めて、リアルプログラマーがどのようにコードを書いたかについて話すべきだと思います。それが彼の名前だったので、私は彼をメルと呼びます。



メルに会ったのは、タイプライターメーカーの現在は廃止された子会社であるRoyal McBee ComputerCorp。に就職したときです。同社はLGP-30（今日の基準では）小型で安価なドラムコンピューターを構築しており、RPC-4000の生産を開始したばかりで、これもドラムメモリ上で大幅に改善され、より大きく、より高速になりました。磁気コアは高価すぎて、競争に耐えることができませんでした（そのため、この会社やそのコンピューターについて聞いたことがありません）。私はこの新しい奇跡のためにFORTRANコンパイラを書くために雇われました、そしてメルはその能力への私のガイドでした。 Melはコンパイラを不承認にしました。 「プログラムが独自のコードを書き直すことができないのは、どんなに良いことですか？」と彼は尋ねました。 Melは、同社で最も人気のあるプログラムを16進数で作成しました。彼女はLGP-30で働き、コンピューターショーで潜在的なバイヤーとブラックジャックをしました。それは常に劇的な効果をもたらしました。すべてのトレードショーにLGP-30ブースが展示され、IBMベンダーが集まって話し合いました。コンピューターの販売に役立ちましたか？この問題について話し合ったことはありません。



Melの仕事は、RPC-4000のブラックジャックプログラムを書き直すことでした。 （移植？それは何ですか？）新しいコンピューターには、1プラス1のアドレス指定スキームがありました。各マシン命令には、opcodeと必要なオペランドのアドレスに加えて、次の命令が回転する磁気ドラムのどこに書き込まれたかを示す2番目のアドレスもありました。 ..。つまり、各命令が実行された後GO TOです！これをパスカルパイプに詰めて喫煙します。



Melは、コードを最適化できるため、RPC-4000が大好きでした。リールに命令を配置して、1つが完了するとすぐに、2つ目が「読み取りヘッド」のすぐ下にあり、すぐに実行できるようにします。これを行うために、アセンブラーを最適化するプログラムが作成されましたが、Melはそれを使用することを拒否しました。 「データがどこに配置されるかはわかりません。そのため、個別の定数を使用する必要があります」と彼は説明しました。私はこのフレーズの本質をずっと後に理解しました。メルはすべての操作コードの数値を知っていて、ドラムメモリに自分のアドレスを割り当てたので、彼が書いた各命令は数値定数と見なすことができます。たとえば、彼は以前の「追加」命令を選択し、適切な数値があればそれを乗算することができます。コードを変更できる人はほとんどいません。Melの手動で最適化されたプログラムを、最適化アセンブラーによって処理されたものと同じコードと比較したところ、Melのコードは常に高速に実行されました。事実、建築を構築するトップダウンの方法はまだ発明されておらず、Malはとにかくそれを使用していなかったでしょう。最初に、彼はプログラミングループの内部を作成して、リールで最適なアドレスを最初に取得したようにしました。そして、最適化アセンブラーはそれができませんでした。巨大なFlexowriterが文字出力の間に遅延を必要とした場合でも、Melは時間遅延ループを作成しませんでした。メルは、次の指示を読まなければならないときにそれが通過するように、単に指示をリールに置いた。トップダウンアーキテクチャの方法はまだ発明されておらず、メルはとにかくそれを使用していなかったでしょう。最初に、彼はプログラミングループの内部を作成して、リールで最適なアドレスを最初に取得したようにしました。そして、最適化アセンブラーはそれができませんでした。巨大なFlexowriterが文字出力の間に遅延を必要とした場合でも、Melは時間遅延ループを作成しませんでした。メルは、次の指示が読まれるときにそれが通過するように、単に指示をリールに置いた。トップダウンアーキテクチャの方法はまだ発明されておらず、メルはとにかくそれを使用していなかったでしょう。最初に、彼はプログラミングループの内部を作成して、リールで最適なアドレスを最初に取得したようにしました。そして、最適化アセンブラーはそれができませんでした。巨大なFlexowriterが文字出力の間に遅延を必要とした場合でも、Melは時間遅延ループを作成しませんでした。メルは、次の指示を読まなければならないときにそれが通過するように、単に指示をリールに置いた。巨大なFlexowriterが文字出力の間に遅延を必要とした場合でも。メルは、次の指示を読まなければならないときにそれが通過するように、単に指示をリールに置いた。巨大なFlexowriterが文字出力の間に遅延を必要とした場合でも。メルは、次の指示を読まなければならないときにそれが通過するように、単に指示をリールに置いた。読み取りヘッドを通過すると、ドラムはそれを見つけるために別の回転を行う必要があります。 Melは、この手順に特有の用語を見つけました。 「最適」（最適）という言葉は、「一意」だけでなく絶対的な意味も持っているため、口頭での会話では、「最適ではない」、「最適ではない」、「最適ではない」などの相対的な意味を持つことがよくあります。メルは、ラグタイムが最も長いドラム上の場所を「最も悲観的」（身体が許容できる最悪の環境条件）と呼びました。



ブラックジャックプログラムを完了して実行した後（「イニシャライザーも最適化されています」と誇らしげに言った）、メルは営業部門から変更を求めるリクエストを受け取りました。エレガントな（最適化された）ランダムナンバージェネレーターは、カードのシャッフルとプログラムのデッキからの処理を担当していました。また、一部の営業担当者は、買い手が負けることがあったため、正直すぎると考えていました。彼らはメルに、コンソールのタッチスイッチがプレーヤーのオッズを変えてバイヤーが勝つことができるようにプログラムを変更するように頼んだ。メルは拒否した。彼はそれが不誠実であると考えました-それはそうだった-そしてそれは彼のプログラマーの道徳を侵害した-それはそうだった-それで彼は参加を拒否した。メルは、営業部門の責任者、ビッグボス、そしてボスの主張で仲間のプログラマーに説得されました。ついにメルはあきらめてコードを書いたしかし、逆にチートチェックを行いました。スイッチをオンにすると、プログラムがチートして常に勝ちました。メルは彼の決定に喜んだ。彼は彼の潜在意識が制御不能な倫理を示し、プログラムを修正することをきっぱりと拒否したと主張した。メルがより高い給料のために会社を辞めたとき、ビッグボスは私にコードを見て、バリデーターを見つけてそれがどのように機能するかを変えることができるかどうか教えてくれるように頼んだ。私はしぶしぶ同意しました。検証モジュールを見つけて、その動作方法を変更できますか？私はしぶしぶ同意しました。検証モジュールを見つけて、その動作方法を変更できますか？私はしぶしぶ同意しました。



メルのコードを扱うことは本当の冒険でした。プログラミングは、この不思議な芸術を理解している人だけが真の価値を認めることができる芸術形式であると私にはよく思われました。それは本物の宝石と華麗な動きを含み、プロセスの本質によって、時には永遠に、人間の視界と賞賛から隠されています。コードを読むだけで、16進数でも、人について多くのことを学ぶことができます。メルは認識されていない天才だったと思います。おそらく最も強力なショックは、私が見つけた無実のサイクルであり、不正な検証はありませんでした。検証なし。いいえ。



常識では、これは閉ループである必要があり、その中でプログラムは永遠に無限に循環します。ただし、ソフトウェア制御は正常に通過し、反対側で安全に終了しました。これを理解するのに2週間かかりました。 RPC-4000には、最新のデバイスであるインデックスレジスタが装備されていました。これにより、プログラムループを作成でき、その中でインデックス付きの命令が使用されました。ループを通過するたびに、レジスタからの番号が命令アドレスに追加され、シリーズの次の位置を参照します。残ったのは、パスごとにインデックスレジスタをインクリメントすることだけでした。メルはこれを利用しませんでした。代わりに、彼は命令をマシンレジスタにプルし、そのアドレスに1を追加して、保存し直しました。そして、変更された命令をレジスタから直接実行しました。サイクルは、余分な実行時間を考慮して作成されました。命令が完了するとすぐに、次の命令がドラムのリードヘッドの下に表示されました。しかし、ループには不正なチェックはありませんでした。保存の手がかりは、インデックスレジスタのビットがオンになっていることでした。これは、アドレスと操作コードの間のコマンドコードにありました。ただし、Melはインデックスレジスタを使用せず、ゼロのままにしました。



私のエピファニーが来たとき、私はほとんど盲目になりました。彼が作業していた高レベルのメモリ（命令が参照できる最大のアドレス）の近くで作業していたデータは、最後の位置が処理された後、命令アドレスをインクリメントするとオーバーフローが発生するように配置されました。転送中に、1つが操作コードに追加され、セット内の次のコードに変更されました：ジャンプ命令。もちろん、この次の命令はアドレス0にあり、プログラムは喜んでそこに行きました。私はメルと話をしていませんし、それ以来プログラミングが殺到している変化の洪水に直面して彼が諦めたかどうかはわかりません。私はあきらめなかったと思うのが好きです。私は非常に感銘を受けたので、チートチェックを探すのをやめ、ビッグボスにそれが見つからないと言いました。彼は驚かなかった。会社を辞めたとき右のスイッチをオンにした場合、ブラックジャックプログラムはまだ不正行為を行っていたと思います。私は本物のプログラマーのコードをハッキングするのが好きではありませんでした。

例外的にUSBの問題

大学を出てすぐに、私は会社に参加し、一般に公開される前に5か月間消費者向けデバイスに取り組みました。デバイスはLinuxを実行していました。そして、カーネル空間を甘やかすというアイデアに慣れている間、バグを優先するための会議に引っ張られました。多数のバグ。何百ものバグ。それらのそれぞれは、「これは不可能です、これはどのように起こったのですか？」と読みます。



彼らは叫んだ：「記憶の損傷！」 「ホスパディ、バグを直して」と思いました。クラッシュダンプを見て、私たちは見ました...それは何ですか？プログラムは、標準ライブラリの関数を使用して2つの文字列を連結することにより、禁止された命令を実行しました。うーん、奇妙な...次のログ：ページングスペースがまったく割り当てられていないデバイスのページングファイルからページをフェッチできません（ページをフェッチできなかった理由は理解できたと思います！）。



私はかつて短いプログラムを書きました。システムメモリの80％を1つのアレイに割り当て、シーケンシャル整数を書き込みました。次に、Enterキーが押されるのを待ち、配列の内容が変更されたかどうかを確認しました。このプログラムをダウンロードし、30秒待ってから、チェックを実行しました。問題ない。私はさらに数回試しました-ハ、私はメモリの損傷がないことを知っていました！デバッグケーブル（USB）を引き出し、10秒後にすばやく挿入して引き出し、再度挿入しました。バム！ 90エラー。



あなたのもの。



さて、USBポートをいじくり回す必要があります。それで、問題は彼に関係していますか？ USBドライバーは、ビットエラーをランダムにスローする魔法のビットフェアリーアルゴリズムを実装していないようです。おそらくハードウェアに問題がありますか？いいえ、彼と一緒ではありませんが、それは私たちがUSBポートであらゆる種類のスケベなことをするのを止めませんでした。彼らはずっと前に別の製品に切り替えたエンジニアを呼びました、そして今彼らは問題について困惑していました。ハードウェアが完全で、完全で、ooooooの順序になっていることを証明するためにどれだけの時間を費やしたかは覚えていません。接地は整然としていて、電圧は安定していて、時計は正確に動いていて、DDRラインは完璧だったので、それを見たときに幸せに泣いたでしょう。



エンジニアによってテストされたデバイスはますます不安定になりました。マシンがデータをメモリにロードし、ビットエラーを取得してから、おそらく間違った場所にある場合でも、フラッシュメモリにダンプして戻すことができると想定しました（ページテーブルが頻繁に破損しているため、これはファイル追跡構造でも発生すると想定できます）コンテンツが間違った場所に書き込まれたり、ファイルシステムの構造が壊れたりする可能性があります。）時間の経過とともに、デバイスが大幅に劣化し、確実に起動できなくなりました。最後に、エンジニアの1人が故障し、自分のラップトップにあった画像を上書きしました。この画像は比較的古いものでした。



-おい。それはソフトウェアについてです。



- 何？！？！？！私たちはあなたに保証します、私たちは少し妖精を書きませんでした！



いいえ：彼は3か月前にアセンブリをアップロードし、問題は解決しました。その瞬間、私は非常に長く無意味なベンチャーに多くの人々を巻き込んだことに責任を感じたので、私は一晩滞在し、過去数か月にわたってすべてのパッチをバイナリ検索しました（OS全体の完全なアセンブリを研究するのに私が望むよりも時間がかかりました...）。



それで、その魔法のパッチは何でしたか？誰かが分析したチップのドライバーをカーネルに追加しました。このチップはデバイスにありませんでした。



ハ！魔女を見つけました！それを燃やす！



多くの人が問題が解決したと発表しました。彼らは、次のリリースでパッチをロールバックして先に進むことができたことに満足していました。私たちはそれを非常にうるさくロールバックし、画像をまとめ、テストしましたが、すべて問題ありませんでした。数日で同じ欠陥が核に現れるとは予想していませんでした。



待つ。チップがボード上になかった場合、ドライバーはどのように私たちを防いだのですか？ lsmodを実行しましたが、ドライバーがロードされませんでした...「とにかく、違いは何ですか。モジュールファイルを削除してリロードしてください。ニフィガ、問題は残っています。これは正常ではありません...」



今、私は一人で、悪魔が起こっているのを見ました。パッチの注意深い分析を開始しました。これは、チップメーカーから提供された素晴らしい10KラインCファイルでした。 「カオス」という言葉でそれを説明するのはあまりにも軽蔑的です（公平に言えば、数週間後、彼らは私たちにはるかに思慮深いドライバーを送ってくれました）。少し掘り下げた後、私はドライバーがビットジャグリングフォーファンを実装していないと判断しました。それで、取引は何ですか？ 5行のコードから48バイト。チップを探すバスアドレスを示すブートファイル内の小さな構造。ほとんどのドライバーを削除しましたが、別の構造を残しました。問題は解決しませんでした。



だから男の子と女の子、私たちはアライメントの問題があります！どういうわけか、この48バイトの構造はメモリ内で何かを移動していて、それがエラーにつながります。 32バイトより大きく64バイト未満のものをファイルに入れると問題が発生することがわかりました。この知識はあまり役に立ちませんでしたが、少なくとも進歩の感覚を生み出しました。



カーネルのコンパイルにより、きちんとしたSystem.mapファイルが生成されました。カーネルの仮想アドレス空間のどこに、カーネルにコンパイルされたすべての変数があるかをリストしました。私の小さな構造が「.data」セクションの真ん中にあることがわかりました。このセクションには初期化された変数が含まれているため、カーネルバイナリがメモリに解凍されると、コンパイルされたイメージからそれらすべての変数が書き込まれます。 System.mapを参照として使用して、かなり間抜けなバイナリ検索を実装しました。ほとんどの場合、私はさまざまなCファイルのリンカーを検索しました。比較する変数を見つけました。それを含むカーネルファイルが見つかりました。私の魔法の構造をランダムなファイルに入れて、問題が再発するかどうかを確認し始めました。



検索は最後のいくつかの.data要素に進み、手ぶらで戻ってきました。初期化された変数を持つメモリに必要なデータはありませんでした。 System.mapファイルをスクロールすると、初期化されていない変数を含む.bssセクション全体に注意を払っていないことがわかりました。過去の過ちから学び、まずは始まりと終わりをチェックしました。もちろん、セクションの先頭にある初期化されていない変数はエラーになりましたが、セクションの終わりにある変数はエラーになりませんでした。犯人を見つけるのは時間の問題でした。動きが問題を引き起こした変数は...



関数ポインタ？！



関数ポインタの配置はどのようにシステムをクラッシュさせますか？ ARMアーキテクチャでは、アライメントなしでアクセスするときにワードを読み取ることはできません。つまり、各32ビット変数は4の倍数のアドレスでメモリに配置する必要があります。関数ポインタも例外ではなく、常に最小アドレスを取得します。問題のある状況では、アドレスは2 ^nの倍数であり、64以上であることがわかりました。このしきい値未満の値はすべて、問題は解消されました。ポインタの位置合わせの順序もありました。



良い配置はありません。少なくともこのバグが発生する前は。



現在、この関数ポインターは「祖父」ポインターではありませんでした。彼は何か特別なことを言っていました。 CPU SRAMには、RAMを使用できない場合に、負荷関連のタスクに使用できる領域がありました。アイドル時のエネルギーを節約するために、この領域にサブルーチンをコピーし、それを参照する特別なポインターを設定してから呼び出しました。サブルーチンは何をしていましたか？アセンブラーを見てみましょう。私はARMアセンブラーの専門家ではありませんが、コメントは非常に雄弁でした。

//       ... 
... 
//       LPDDR   

何してるの？！基本的なレジスタ操作からメモリコントローラの無効化にすばやく移行しました。サブルーチンを書いたメーカーにメールを送り、何か足りないものがないか尋ねました。



3日後、「ああ、記憶の壁があるに違いない」という答えが返ってきました。 L2キャッシュの構造上、誤って64の倍数をメモリアドレスに書き込んだ場合は、TLBを追加でサポートする必要があることがわかりました。このような場合でも、コントローラがオフの場合でもRAMを使用できます。



変数の配置には最小4の多重度が必要であり、最後のレコードの多重度を64以上にすることはできないことを考慮すると、各コンパイルで、データの16分の1がシステムで完全に使用できなくなりました。



結局、メモリバリアを備えた信頼性の高い製品を出荷し、顧客はそれを愛していました。はい。ご参考までに、USBの使用により低電力モードに入ることができなかったため、USBケーブルでは気づきませんでした。これは純粋にUSBの問題です。

無効なエラーメッセージ

WebTVサービスの開始予定日の前日の1996年9月17日の最後の時間に、私たちのグループはパロアルトのオペレーションセンターに集まりました。ネットワークシステム管理者とサービスソフトウェア開発者の群衆は、公式の立ち上げを目撃するために近くにたむろしました。



指定された時間が経過すると、ネットワーク担当者の1人が自分のWebTVデバイスに登録し始めました。良いニックネームはすぐに終わることを理解していたので、ユーザーがそれを始める前に登録することが重要でした。さらに、最初の「実際の」サービスに最初に登録できてよかったです。それ以前は、すべてのアカウントは「1回限りの」テストアカウントでした。



何人かの人々が群がり、彼がキーボードでタイプするのを見て、期待と睡眠不足でめまいを感じました。ブライスは自分の名前、住所、その他の情報を入力してから、ニックネームを入力し始めました。それが彼のメールアドレスの名前でした。彼は「jazz」と入力しました。これは、彼のメールが「jazz@webtv.net」であることを意味します。彼がワイヤレスキーボードのEnterキーを押すと、エラーメッセージの表示を示す独特の音が聞こえました。誰もが画面を見ました。



次に何が起こったのかを理解するには、サービスについて1つか2つのことを知ることが重要です。 WebTVはファミリーTVとして位置付けられていたため、不正な言語をチェックし、ユーザー名やユーザーに表示されるその他の情報を除外する必要がありました。すべてをキャッチすることは不可能ですが、明らかなものを除外することは難しくありません。



カスタム名は通常の式のリストと比較され、パターンと照合することができました。たとえば、「fu。* Bar」は、「fu」で始まり「bar」で終わるすべての名前と比較されます。パターンを慎重に選択すれば、呪いが組み込まれている「シタケ」や「マツシタ」などのひどいバリエーションをキャッチして拒否することができます。



同じメカニズムを使用して、ユーザーが「postmaster」、「root」、「admin」、「help」などの「禁止」名を選択できないようにしました。次のようなテキストファイルがありました。

admin.*
      "admin".
postmaster
  postmaster.
poop
  .
weenie
  .

各エントリは2行で構成されていました。 1行目は比較対象の正規式で、2行目はユーザーに表示されたエラーメッセージです。システムは一度に2行ずつファイルを読み取り、ユーザーが名前を入力すると、すべての通常の式と比較されました。最初に一致したものが見つかった場合、エラーメッセージが表示されました。一致するものがなかった場合、カスタム名が受け入れられました。



ファイルを読み取るコードは、コメントをスキップする方法を知っていました。しかし、彼は空の行を処理する方法を知りませんでした。



「予約済み」の名前の後、誓いの言葉の前に1行の空白行を追加する途中で、誰かが誓いのファイルに変更を加えました。コードがリストを読み取るとき、空の文字列を通常の式として受け取り、それに続く単語をエラーメッセージとして受け取りました。空の文字列式は何にでも一致します。



真夜中。私たちは皆、少しばかり進んでいます。ブライスが名前を書き、システムは簡単なメッセージで応答します。





ヒステリックに笑い始めました。他の人たちが何が起こっているのかを知るために私たちのところにやって来ました。画面に見せました。彼らはヒステリックに笑い始めました。



このとき、別の建物で、マーク・アームストロング（QAを担当）とブルース・リーク（会社の創設者の1人）が16個のWebTVセットトップボックスのカウンターの前に座っていました。 「ラックスビル」と呼ばれるこのラックは、ビデオマルチプレクサを介して、16個のボックスすべてからの画像を同時に表示する大型テレビに接続されていました。マークとブルースは、赤外線送信機付きのキーボードを使用してセットトップボックスの登録を開始しました。私たちはインターコムで彼らに電話しました：



-調子はどうですか？



-すべて完璧です。



- ああ、いいね。登録時にいくつか気づいたかもしれません。



- はい？何も奇妙なことに気づきませんでした。



-通知。



- はい。郵便番号を入力しています...これまでのところすべて問題ありません。OGO !!!



16台すべてのコンソールからの画像にわかりやすいメッセージが表示されました。上司は、このグリッチをできるだけ早く修正する必要があるかもしれないと提案しました。これは私たちにとって素晴らしいアイデアのように思えました。



ファイルを修正し、空の行を認識して無視するようにコードを教えました。私の知る限り、WebTVはどの顧客にも「f--k」と言っていません。

Xboxクラッシュの問題

当時、チームはXboxと呼ばれるまったく新しいコンソールの最初のゲームの1つに取り組んでいました。最終テストが加速されると、QAはインストールバッチから3つのセットトップボックスを起動して、夜間に自動テストを実行しました。昨日のゲームのビルドがまだ午前中にテストされていた場合、これはその安定性を示しています。



残念ながら、コンソールの1つが午前中にクラッシュしました。クラッシュは常に悪いものですが、それは非常に悪いケースでした。ビデオカードによって実行された何かがシステム全体をクラッシュさせました。グラフィックカードの問題の診断は困難です。デバッガー、スタックトレース、printf。を使用したデバッグはありません。コードを読んで実験することしかできません。



このようにしてバグハントが始まりました。リードエンジニアは毎日、入手可能な証拠を検討し、可能性を仮定して除外しました。毎晩、QAは理由もなく「ランダムな」ドロップを受け取りました。 「これは不可能です」、「これはどのように発生しますか？」、「これはコンパイラのバグかもしれませんか？」 -すべての最も人気のあるヒット。



エンジニアの車では、ゲームは何日も完璧に機能しました。しかし、ゲームを印刷して店舗に発送する期限が近づいていたため、これは少し慰めになりました。



幸いなことに、かなり奇妙なパターンではありますが、すぐにパターンが見つかりました。ゲームは夜間にのみクラッシュし、3つのコンソールのうちの1つでのみクラッシュしました。私たちはそれらの違いを探し始めました。それは電源ケーブルについてではありませんでした。コントローラにはありません。 DVDが故障して焼けました。コンソールをテーブルに転送します-落下しません。彼らはそれを元に戻しました-それは落ちます。 QAが使用した特定のスタンドについてでした。



ここで、すべての変数を除外するために必要な要素を除外するプロセス。結局、絶望して、エンジニアはテーブルのアタッチメントを交換しようとしました。



誤動作しているのは特定のプレフィックスではないことが判明しました。このテーブルのプレフィックスはすべて落ちました。夜中に。科学のために時々あなたは奇妙に行動しなければなりません、そしてこれはそれらのケースの1つでした。エンジニアはストイックに椅子に腰を下ろし、レッドブルの缶をかぶせ、バグハントはバグウォッチングに変わりました。エンジニアは、自分の目で失敗を確認するまで、このいまいましいテーブルのコンソールで自動テストが実行されるのを見ると誓いました。



夜はゆっくりと、そしてすぐに過ぎ、そしてついに夜明けが訪れました。ゲームは実行を続けました。それは刺激的でした。太陽が昇り始めた。



そしてついに面白いことが起こりました。昇る太陽の光がテーブルに落ちました。毎分、ビームがテーブルを横切ってアタッチメントに忍び寄り、その暖かい輝きがアタッチメントの黒いドームを静かに包みました。



すぐに落ちました。



最初のXboxには問題がありました。コンソールの温度が特定の値に達すると、ビデオカードが誤動作する可能性がありました。ソフトウェアはそれとは何の関係もありませんでした。ハードウェアの問題が報告され、ゲームがリリースされ、RedBullがビールに置き換えられました。さて、正直に言って、ウイスキーです。1：科学の場合はゼロ。