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

バグが完全に信じられないほどの症状を示すことがある方法についてのインターネットからのストーリーのコレクションの継続。最初の部分はここにあります。

もっと魔法

数年前、MITAIラボに所属していたPDP-10コンピューターが収納されていたクローゼットを調べました。いずれかのキャビネットのフレームに小さなスイッチが接着されているのに気づきました。それが実験室の職人の一人によって追加された自家製の製品であることは明らかでした（誰が正確に誰であるかを誰も知りませんでした）。



コンピュータが破損する可能性があるため、何をするのかを知らずにコンピュータの不明なスイッチに触れることはありません。スイッチは完全に理解できないように署名されました。 2つの位置があり、「魔法」と「もっと魔法」という言葉が金属の本体に鉛筆で走り書きされていました。スイッチはより魔法の位置にありました。技術者の一人に電話して見てもらいました。彼はそのようなことを見たことがなかった。よく調べてみると、スイッチに接続されているのは1本のワイヤーだけであることがわかりました。ワイヤーのもう一方の端はコンピューター内のケーブルの寄せ集めに姿を消しましたが、電気の性質上、2本のワイヤーを接続するまでスイッチは何もしません。



これが誰かの愚かな冗談であることは明らかでした。スイッチが何もしないことを確認した後、切り替えます。コンピューターはすぐに亡くなりました。



私たちの驚きを想像してみてください。偶然にそれをチョークで書いたが、それでもコンピュータを起動する前にボタンを「もっと魔法の」位置に戻した。



一年後、私は覚えている限り、この話を別の技術者、デビッド・ムーンに話しました。彼は私の妥当性に疑問を呈したり、そのスイッチの超自然的な性質を信じている疑いがあるか、私が彼の偽の話にだまされていると思った。私の主張を証明するために、私は彼にこのスイッチを見せました。まだフレームに接着されていて、1本のワイヤーでまだ「もっと魔法の」位置にあります。スイッチとワイヤーを詳しく調べたところ、接地されていることがわかりました。それは二重に無意味に見えました。スイッチは電気的に動作しないだけでなく、何にも影響を与えない場所に接続されていました。別の位置に移動しました。



コンピューターはすぐに空白になりました。



近くにいたMITの長年の技術者であるRichardGreenblattに連絡を取りました。彼もまた、スイッチを見たことがありませんでした。調べてみると、スイッチがダメだと判断し、ワイヤーカッターを取り出してワイヤーを切った。次に、コンピューターの電源を入れると、静かに動作し始めました。



このスイッチがどのようにコンピューターをシャットダウンしたのかはまだわかりません。接地接点の近くで小さな短絡が発生し、スイッチ位置の移動によって電気容量が変化し、100万分の1秒のパルスが通過すると回路が遮断されたという仮説があります。しかし、私たちは確かに知りません。スイッチは魔法だったとしか言えません。



それはまだ私の地下にあります。これはおそらくばかげていますが、私は通常それを「より魔法の」位置に保ちます。



1994年に、この話の別の説明が提案されました。スイッチの本体は金属製であることに注意してください。2本目のワイヤーのない接点が本体に接続されているとします（通常、本体は接地されていますが、例外があります）。スイッチ本体は、おそらく接地されているコンピューターケースに接続されていました。その場合、機械内部の接地回路の電位がフレーム接地回路と異なる可能性があり、スイッチの位置を変更すると電圧が低下または急上昇し、機械が再起動しました。この効果は、潜在的な違いを知っていて、そのようなジョークスイッチを作ることに決めた誰かによっておそらく発見されました。

OpenOfficeは火曜日には印刷されません

今日のブログで、興味深いバグについての言及に出くわしました。一部の人々は文書の印刷に問題がありました。後で、誰かが彼の妻が火曜日に印刷できないことについて不平を言ったことに気づきました！



バグレポートでは、他のすべてのアプリケーションから問題なく印刷されたため、OpenOfficeのバグである必要があると最初に不満を述べた人もいました。他の人は、問題が起こったり消えたりすることに気づきました。あるユーザーが解決策を見つけました。OpenOfficeをアンインストールしてシステムをワイプしてから、再インストールします（Ubuntuでの簡単なタスク）。ユーザーは火曜日に彼の印刷の問題が解決されたと報告しました。



2週間後、彼は（火曜日に）自分の解決策が機能しなかったと書いた。約4か月後、Ubuntuハッカーの妻は、OpenOfficeが火曜日に印刷されなかったと不満を漏らしました。この状況を想像してみてください。



妻：スティーブ、プリンターは火曜日は休業です。



スティーブ：それはプリンターでの休日です、もちろん火曜日には印刷されません。



妻：本気です！火曜日はOpenOfficeから印刷できません。



スティーブ:(信じられない）わかりました、見せてください。



妻：お見せできません。



スティーブ:(目を転がして）なぜ？



妻：今日は水曜日です！



スティーブ:(うなずく、ゆっくり話す）そうです。



この問題は、と呼ばれるプログラムにまでさかのぼりfileます。この* NIXユーティリティは、テンプレートを使用してファイルタイプを検出します。たとえば、ファイルがで始まる場合%!そしてそれは行きますPS-Adobe-、そしてそれはPostScriptです。OpenOfficeがそのようなファイルにデータを書き込んでいるようです。火曜日に彼は彼のユニフォームを取ります%%CreationDate: (Tue MMM D hh:mm:...)。Erlang JAMファイルのテンプレートのエラーは、TuePostScriptファイルがErlang JAMファイルとして認識されたため、おそらく印刷用に送信されていなかったことを意味します。



ErlangJAMファイルのテンプレートは次のようになります。

4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2

そしてそれはこのように見えるはずです：

4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2

このプログラムが認識しようとするファイルタイプが多数（1600以上）あることを考えると、テンプレートエラーは驚くべきことではありません。しかし、比較の順序も頻繁な誤検知につながります。この場合、ErlangJAMタイプはPostScriptタイプにマップされました。

デスパッケージ

彼らはまさに死の小包だったので、私は彼らをそれと呼び始めました。



Star2Starは、ローカルクライアントシステムの最後の2つのバージョンを作成したハードウェアメーカーと提携しています。



約1年前に、このハードウェアのアップデートをリリースしました。ムーアの通常の法則に従って、すべては非常に単純に始まりました。より大きく、より良く、より速く、より安く。新しいハードウェアは64ビットで、メモリが8倍多く、ドライブが多く、4つのIntelギガビットイーサネットポート（私のお気に入りのイーサネットコントローラーのメーカー）がありました。これらのポートの使用方法については、多くのアイデアがありました（そしてまだあります）。全体的に、鉄片は美味しかったです。



目新しさは、パフォーマンスと機能のテストを通して急上昇しました。速度も信頼性も高いです。理想的には。次に、機器をいくつかのテストサイトにゆっくりと展開しました。もちろん、問題が発生し始めました。



Googleですばやく検索すると、Intel82574Lイーサネットコントローラーに少なくともいくつかの問題があったことがわかります。特に、EEPROMの問題、ASPMのバグ、MSI-Xのトリックなど。私たちはそれらのそれぞれを数ヶ月間解決してきました。そして、私たちは終わったと思いました。



しかし、違います。悪化しただけです。



完璧なソフトウェアイメージ（およびBIOS）を設計して展開したと思いました。しかし、現実は異なっていました。モジュールは引き続き失敗しました。再起動後に回復することもあれば、回復しないこともありました。ただし、モジュールを復元した後、テストする必要がありました。



ワオ。状況はおかしくなってきました。



奇妙なことが続き、ついに私は袖をまくり上げることにしました。私がデータを収集している間、3時間私の電話で私と一緒にいた非常に忍耐強くて親切な再販業者を見つけたのは幸運でした。そのクライアントポイントで、何らかの理由で、ネットワークを介して音声トラフィックを送信しているときにイーサネットコントローラーが停止する可能性があります。



これについて詳しく説明します。イーサネットコントローラが「ダウンした可能性がある」と言うとき、それはそれが故障している可能性があることを意味します。システムとイーサネットインターフェイスは正常に見え、ランダムな量のトラフィックを送信した後、インターフェイスはハードウェアエラー（PHYとの通信の喪失）を報告し、接続を失う可能性がありました。スイッチとインターフェースのLEDは文字通り消えました。コントローラーは死んでいた。



電源を入れ直すだけで、生き返らせることができました。カーネルモジュールまたはマシンを再起動しようとすると、PCIスキャンエラーが発生しました。マシンが物理的に抜かれ、再び差し込まれるまで、インターフェースは死んだままでした。ほとんどの場合、クライアントにとって、これは機器の取り外しを意味しました。



この非常に辛抱強い再販業者でデバッグしているときに、インターフェイスがクラッシュしたときにパケットの受信を停止し始めました。結局、私はパターンを特定しました。インターフェースからの最後のパケットは常に100 Trying provisional responseであり、常に特定の長さでした。それだけではありません。最終的に、この応答（Asteriskから）を、メーカーの電話の1つに固有の元のINVITE要求までさかのぼりました。



私は再販業者に電話し、人々を集めて証拠を示しました。金曜日の夕方でしたが、全員が参加し、このメーカーの新しい機器と電話でテストベンチを組み立てました。



私たちは会議室に座って、できるだけ速く番号をダイヤルし始めました。問題を再現できることがわかりました！すべての通話やすべてのデバイスではありませんが、時々イーサネットコントローラをオンにすることができましたが、そうでないこともありました。電源を切った後、再試行して成功しました。いずれにせよ、技術的な問題を診断しようとした人なら誰でも知っているように、最初のステップは問題を再現することです。ようやく成功しました。



私を信じてください、それは長い時間がかかりました。 OSIスタックがどのように機能するかを知っています。ソフトウェアがどのようにセグメント化されているかを知っています。 SIPパケットの内容がイーサネットアダプタに影響を与えるべきではないことを私は知っています。それはすべてナンセンスです。



最後に、デバイスに到着してからスイッチのミラーリングポートに到着するまでのパケットの問題を切り分けることができました。問題はINVITE応答ではなく要求にあることが判明しました100 Trying。ミラーリングされたポートでキャプチャされたデータに応答はあり100 Tryingませんでした。



これに対処する必要がありましたINVITE。問題は、ユーザースペースデーモンによるこのパッケージの処理に関連していましたか？多分送信が問題100 Tryingでしたか？私の同僚の1人は、SIPアプリケーションを閉じて、問題が解決するかどうかを確認することを提案しました。このアプリがなければ、パッケージ100 Trying送信されませんでした。



問題のあるパケットの送信を何らかの方法で改善する必要がありました。電話から送信されたパケットを分離し、INVITEを使用して再生しましたtcpreplay。機能した。数か月ぶりに、1つのパケットでコマンドでポートをドロップすることができました。これは大きな進歩であり、家に帰る、つまり、ホームラボでテストベンチを繰り返す時が来ました！



話を続ける前に、私が見つけた素晴らしいオープンソースアプリケーションについてお話ししたいと思います。 Ostinatoはあなたをパケットマスターに変えます。その可能性は文字通り無限です。このアプリケーションがなければ、私はそれ以上進むことができなかったでしょう。



この用途の広いパッケージツールを装備して、私は実験を始めました。私は見つけたものに驚いた。



それはすべて奇妙なSIP / SDPの癖から始まりました。このSDPを見てください：

v=0
o=- 20047 20047 IN IP4 10.41.22.248
s=SDP data
c=IN IP4 10.41.22.248
t=0 0
m=audio 11786 RTP/AVP 18 0 18 9 9 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv

はい、そうです。音の伝達の提案は複製されます。これは問題ですが、繰り返しになりますが、イーサネットコントローラーはこれと何の関係がありますか？！さて、イーサネットフレームのサイズを増やすものは他にないという事実を除けば...しかし、待ってください、送信されたパケットには多くの成功したイーサネットフレームがありました。それらのいくつかはより小さく、いくつかはより大きかった。それらに問題はありませんでした。私はさらに掘り下げなければなりませんでした。 Ostinatoを使ったカンフーのトリックと一連の電気的再接続の後、問題のある関係（問題のあるフレームとの関係）を特定することができました。注：16進数の値を見ていきます。



インターフェイスのクラッシュは、特定のオフセットの特定のバイト値によって開始されました。私たちの場合、それは16進値32c0x47fでした。 ASCIIでは、16進数32は2..。それがどこから来たのかを推測し2ます。

a=ptime:20

すべてのSDPは同一でした（を含むptime）。すべてのソースURIと宛先URIは同一でした。唯一の違いは、発信者の番号、タグ、および一意のセッションIDでした。問題のあるパケットには、呼び出しID、タグ、およびブランチのこのような組み合わせがあり、そのptime結果、値2にオフセットがありました0x47f。



ブーム！正しいID、タグ、およびブランチ（または任意のランダムジャンク）を使用すると、行ptimeが特定のアドレスで終了するとすぐに、「適切なパッケージ」が「キラー」パッケージに変わる可能性があります。とても不思議でした。



パッケージを生成するとき、私はさまざまな16進値を試しました。状況はさらに複雑であることが判明しました。コントローラの動作は、最初に受信したパケットの指定されたアドレスにあるこの特定の値に完全に依存していることが判明しました。写真はこんな感じでした：

 0x47f = 31 HEX (1 ASCII) -  
 0x47f = 32 HEX (2 ASCII) -  
 0x47f = 33 HEX (3 ASCII) -  
 0x47f = 34 HEX (4 ASCII) -  (inoculation) 

私が「影響しない」と言ったとき、私はインターフェースを殺さないだけでなく、（多かれ少なかれ）接種もしないことを意味しました。そして、「インターフェースがクラッシュしている」と言ったとき、私の説明を覚えていますか？インターフェイスが死にかけています。完全に。



新しいテストの結果、FreeBSDを使用し、起動可能なメディアなしでマシンの電源を入れても、見つけたすべてのバージョンのLinuxで問題が解決しないことがわかりました。それはOSではなくハードウェアに関するものでした。ワオ。



さらに、Ostinatoの助けを借りて、HTTP POST、ICMPエコー要求などのさまざまなバージョンのキラーパケットを作成することができました。私が欲しかったほとんどすべて。 （ヘッダー、ホストなどに基づいて）バイト値でデータを生成する変更されたHTTPサーバーを使用すると、デスパケットを含み、ファイアウォールの背後にあるクライアントマシンを強制終了する200番目のHTTPリクエストを簡単に作成できました！



全体の状況がいかに奇妙であったかについては、すでに説明しました。しかし、最も奇妙なことはワクチンでした。最初に受信したパケットに（私がテストした）値が含まれている場合1、2または3、インターフェイスがパケットの停止（値2またはを含む3）に対して無防備になった場合は例外であることが判明しました。また、コードおよび属性がptime10の倍数となっています：10、20、30、40。コールID、タグ、ブランチ、IP、URIなどの組み合わせ（このバグのあるSDPを使用）に応じて、これらの有効な属性ptimeが完全な順序で並んでいます。信じられない！



問題が散発的に発生している理由が突然明らかになりました。私がそれを理解できたのは驚くべきことです。私は15年間ネットワークを扱ってきましたが、そのようなものを見たことがありません。そして、また会えるとは思えません。うまくいけば...



私はIntelの2人のエンジニアに連絡し、問題を再現できるようにデモを送信しました。数週間実験した後、彼らは問題が82574LコントローラーのEEPROMにあることに気づきました。彼らは私に新しいEEPROMと書き込みツールを送ってくれました。残念ながら、配布できなかったほか、e1000eカーネルモジュールをアンロードしてリロードする必要があったため、このツールは私たちの環境には適していませんでした。幸いなことに（EEPROMの回路図について少し知識があれば）、bashスクリプトを記述して、魔法のように書くことができました。ethtool「修正された」値を保存し、バグが発生したシステムに登録しました。これで、問題のあるデバイスを特定できました。パッチを出荷する前に、すべてのデバイスにパッチを適用するようにベンダーに連絡しました。これらのIntelイーサネットコントローラーがすでにいくつ販売されているかは不明です。

もう1つのパレット

2005年、私は仕事で原因不明の問題を抱えていました。計画外のシャットダウン（ハリケーンによる）の翌日、データベースに接続する際のタイムアウトについて不満を言っているユーザーから電話がかかってきました。 32ノードの非常に単純なネットワークがあり、帯域幅が実際には使用されていないため、データベースを備えたサーバーが15〜20分間正常にpingを実行し、その後「要求がタイムアウトしました」という応答が約2分以内に届いたことに驚いた。このサーバーは、パフォーマンスモニタリングやその他のツールを実行し、さまざまな場所からpingを実行していました。サーバーを除いて、残りのマシンは他のネットワークメンバーと常に通信できます。障害のあるスイッチまたは接続を検索しましたが、ランダムで断続的な障害の説明が見つかりませんでした。



さまざまなデバイスをトレースして再接続しているときに、倉庫のスイッチのLEDを確認するように同僚に依頼しました。同僚がラジオで「これはオフ、起きた」と言ったので、45〜50分かかりました。私は彼に何かパターンに気づいたかどうか尋ねました。



-はい...気づきました。しかし、あなたは私がおかしいと思うでしょう。フォークリフトがパレットを出荷ホールから取り出すたびに、サーバーで2秒後にタイムアウトが発生します。



- 何？？？



-ええ。また、ローダーが新しい注文の発送を開始すると、サーバーが復元されます。



私はフォークリフトを見に走りました、そして彼がいくつかの巨大なマグネトロンをオンにすることによって注文の成功した完了をマークしていると確信していました。間違いなく、コンデンサからの電磁波は時空間の連続性を破壊し、50メートル離れた別の部屋にあるサーバーネットワークカードの動作を一時的に中断します。番号。フォークリフトは、ワイヤレスバーコードスキャナーで各ボックスをスキャンしながら、パレット上に大きなボックスを積み上げ、その上に小さなボックスを積み上げました。あはは！データベースサーバーにアクセスしているのはおそらくスキャナーであり、他のクエリが失敗する原因になっています。いいえ。調べてみると、スキャナーはそれとは何の関係もないことがわかりました。出荷ホールのワイヤレスルーターとそのUPSは正しく構成され、正常に機能していました。ハリケーンによる閉鎖の前は、すべてがうまく機能していたので、理由は別のものでした。



次のタイムアウトが始まるとすぐに、私は船積みホールに走り、ローダーが次のパレットをいっぱいにするのを見ました。彼が4つの大きなシャンプーボックスを空のトレイに置くとすぐに、サーバーは再びダウンしました！私は何が起こっているのか不条理を信じていませんでした、そしてさらに5分間、私はシャンプーの箱を取り出して入れました、同じ結果でした。船ホールのルーターがパレットの箱の高さから約30cm下にぶら下がっているのに気づいたとき、私はひざまずいてイントラネットの神の慈悲を祈ろうとしていました。手がかりがあります！



大きな箱がパレットに置かれると、ワイヤレスルーターは外部の倉庫への視界を失いました。 10分後、私は問題を解決しました。これが起こったことです。ハリケーンの最中に、UPSに接続されていない唯一のデバイス（私のオフィスのテストワイヤレスルーター）を落とした停電がありました。デフォルト設定はどういうわけかそれを船積みホールにぶら下がっている唯一の他の無線ルーターのためのリピーターに変えました。両方のデバイスは、間にパレットがない場合にのみ相互に通信できましたが、それでも信号はそれほど強くありませんでした。ルーターが通信すると、小さなネットワークにループが作成され、データベースサーバーへの他のすべてのパケットが失われました。サーバーにはメインルーターからの独自のスイッチがあったため、ネットワークノードとしてははるかに離れていました。他のほとんどのコンピューターは同じ16ポートスイッチ上にあったので、問題なくそれらの間でpingを実行できました。



1秒で、4時間苦しんでいた問題を解決しました。テストルーターの電源を切りました。サーバーでタイムアウトは発生しませんでした。

Tronムービーのように、AppleIIgsコンピューターでのみ

子供の頃の私のお気に入りの映画の1つは、1980年代初頭に撮影されたトロンでした。それは、「デジタル化」され、パーソナライズされたプログラムが住むコンピューターの世界に夢中になっているプログラマーについて語った。主人公は抵抗グループに加わり、抑圧者のマスターコントロールプログラム（MCP）を倒そうとしました。これは、進化し、権力への欲望を獲得し、ペンタゴンのコンピューターシステムを乗っ取ろうとした反抗的なプログラムです。



プログラムの最も印象的なシーンの1つでは、キャラクターは光のサイクルでレースをします。二輪車はオートバイのように見え、壁を後にします。主人公の一人が敵のペペラトをアリーナの壁に衝突させ、貫通穴を作った。ヒーローたちは敵に対処し、穴から自由へと逃げました。これは、MCPの転覆に向けた最初のステップです。



映画を見たとき、何年も後に、Apple IIgsコンピューターで、トロンの世界、反抗的なプログラム、その他すべてをうっかり再現してしまうとは思いもしませんでした。



これが起こった方法です。プログラミングを学び始めたとき、トロンからライトサイクルゲームを作ることにしました。友人のマルコと一緒に、ORCA / PascalのAppleIIgsと65816アセンブラーでプログラムを作成しました。ゲーム中、画面は白の境界線で黒く塗られました。各線はプレーヤーの1人を表しています。画面下部にゲームのスコアを一列に表示しました。グラフィカルに、それは最も進んだプログラムではありませんでしたが、それはシンプルで楽しいものでした。彼女はこのように見えました：





ゲームは、1つのキーボードの前に座った場合、最大4人のプレーヤーをサポートしました。不便でしたが、うまくいきました。4つのライトサイクルすべてを使用するのに適切な人数を確保することはめったになかったため、マルコは合理的に競争できるコンピューター制御のプレーヤーを追加しました。

武器レース

ゲームはすでにとても面白かったですが、私たちは実験したかったのです。プレイヤーに差し迫った事故から逃れるチャンスを与えるためにロケットを追加しました。マルコが後で説明したように：

人間とAIはそれぞれ、ゲーム中に使用できる3つのロケットを持っていました。ロケットが壁にぶつかったとき、背景が黒く塗られた「爆発」があり、それによって前の光のサイクルによって残された道のセクションが削除されました。

すぐに、プレーヤーとコンピューターはロケットで困難な状況から抜け出すことができます。トロンの純粋主義者はそれに笑うでしょうが、映画のプログラムにはロケットの贅沢がありませんでした。

脱出

すべての異常で奇妙な出来事と同様に、それも予想外でした。



かつて、マルコと私が2人のコンピュータープレーヤーと対戦していたとき、AIループの1つを壁と画面の下端の間に閉じ込めました。差し迫った事故を見越して、彼はいつものようにロケットを発射した。しかし今回は、壁の代わりに、光のサイクルの1つの軌跡のように見える画面の境界を撃ちました。ミサイルは境界線にぶつかり、光のサイクルほどの大きさの穴を残し、コンピューターはすぐにそれを通って競技場を出ました。ライトサイクルがスコアラインを通過するときに、混乱して見つめました。彼は簡単にシンボルとの衝突を避け、画面から完全に離れました。



そしてその直後、システムがクラッシュしました。





何が起こったのかを把握しようとすると、心が揺れた。コンピューターはゲームから抜け出す方法を見つけました。ライトサイクルが画面を離れると、映画のようにコンピュータのメモリに逃げました。何が起こったのか気づいたとき、私たちの顎は落ちました。



システム全体を定期的にクラッシュさせる可能性のあるプログラムの欠陥を発見したとき、私たちは何をしましたか？もう一度やり直しました。最初に、私たちは自分たちで限界を超えようとしました。それから彼らはコンピューターを再び逃げさせた。魅惑的なシステムクラッシュで報われるたびに。ドライブが際限なく不平を言うと、ドライブライトが点滅することがありました。また、画面が無意味な文字でいっぱいになったり、スピーカーが鳴き声や低音を立てたりすることもありました。そして時々それはすべて一度に起こり、コンピュータは完全に混乱した状態にありました。



なぜこれが起こったのですか？これを理解するために、AppleIIgsコンピューターのアーキテクチャを見てみましょう。

（Un）保護されたメモリ

Apple IIgsオペレーティングシステムには保護されたメモリがありませんでした。これは、メモリの領域がプログラムに割り当てられ、外部アクセスから保護された後のオペレーティングシステムに登場しました。したがって、Apple IIgsのプログラムは、（ROMを除く）何でも読み書きできます。IIgsはメモリバウンドI / Oを使用してフロッピードライブなどのデバイスにアクセスしたため、メモリの特定の領域から読み取ることでフロッピードライブをアクティブ化することができました。このアーキテクチャにより、グラフィックプログラムは画面メモリに対して直接読み取りおよび書き込みを行うことができました。



このゲームでは、AppleIIgsグラフィックモードの1つであるSuperHi-Resを使用しました。16色のパレットで320x200ピクセルの驚くべき解像度です。パレットを選択するために、プログラマーは12ビットのカラー値に16のエントリ（0から15または$ 0からFまでの16進形式の番号）を指定しました。画面に描画する場合は、色を直接ビデオメモリに読み書きできます。

衝突検出アルゴリズム

この機能を利用して、ビデオメモリから直接読み取ることでクラッシュ検出器を実装しました。ゲームは、各ライトサイクルについて、現在の方向に基づいて次の位置を計算し、ビデオメモリからこのピクセルを読み取ります。位置が空の場合、つまり黒いピクセル（$ 0パレットのエントリ）で表されている場合、ゲームは続行されます。しかし、ポジションが取られた場合、プレーヤーはライトサイクルまたは画面の白いフレーム（パレット15または$ Fのエントリ）にクラッシュしました。例：





画面の左上隅がここに表示されます。色$ Fは白い境界線を示し、色$ 1はプレーヤーの緑色のライトサイクルを示します。矢印で示すように左に移動します。つまり、次のピクセルは空で、色は$ 0です。プレイヤーがこの方向に1ターン以上移動し続けると、壁（色$ F）に衝突して壊れます。

超えて

アセンブラ数学を使用して次のピクセルを決定するためのアルゴリズムは、現在のピクセルの上、下、左、または右の1つのピクセルのメモリアドレスをすばやく計算しました。画面上の任意のピクセルがメモリ内のアドレスであったため、アルゴリズムは単に新しいアドレスを計算して読み取りました。そして、ライトサイクルが画面を離れると、アルゴリズムは壁との衝突をチェックするためにシステムメモリ内の場所を決定しました。これは、ライトサイクルがシステムメモリを通過し、無意味にビットをオンにしてメモリに「クラッシュ」したことを意味します。



システムメモリ内のランダムな場所への書き込みは、賢明なアーキテクチャ上の決定ではありません。当然のことながら、これが原因でゲームがクラッシュしました。人間のプレイヤーは盲目的に乗ることはなく、通常はすぐにクラッシュするため、システムの問題の範囲が制限されます。そして、AIにはそのような弱点はありません。コンピューターは即座に周囲の位置をスキャンして、壁にぶつかって方向を変えるかどうかを判断します。つまり、コンピュータの観点では、システムメモリは画面メモリと同じでした。マルコが説明したように：

, , . , , 0. «» , . «», - - , , — . , - , .

その結果、映画からライトサイクルレースを再現しただけでなく、エスケープそのものも再現しました。映画のように、脱出は大きな結果をもたらしました。



オペレーティングシステムは保護されたメモリを取得しているため、これを今日繰り返すことは困難です。しかし、反乱軍のAIコードが国防総省を乗っ取ることを防ぐために、「保護されたスペース」を脱出しようとしているTronのようなプログラムがあるかどうかはまだ疑問です。



気が付くと思いますが、意識のデジタル化の発明を待つ必要があります。

座ってログインする

すべてのプログラマーは、デバッグが難しいことを知っています。ただし、優れたデバッガーの場合、作業は一見単純に見えます。取り乱したプログラマーは、何時間もかけてキャッチするバグについて説明し、マスターはいくつかの質問をし、数分後、プログラマーは彼らの前に欠陥のあるコードを見つけます。デバッグの専門家は、システムが一見不思議な動作をしていても、常に論理的な説明があることを忘れないでください。



この態度は、IBMヨークタウンハイツリサーチセンターで行われた話によって示されています。プログラマーは最近、新しいワークステーションをインストールしました。コンピューターの前に座っていたときはすべて問題ありませんでしたが、立っている間はログインできませんでした。この動作は常に再現されていました。プログラマーは常に座っているときにログインしましたが、立っている間は一度もログインできませんでした。



私たちの多くはただそこに座って疑問に思いました。コンピューターは、彼らがその前に立っているのか座っているのかをどうやって知ることができますか？ただし、優れたデバッガーは、理由があるはずだと知っています。最初に頭に浮かぶのは電気です。カーペットの下の断線、または静電気？しかし、電気的な問題が100％再現されることはめったにありません。同僚の1人がついに正しい質問をしました。プログラマーは座ったり立ったりしながら、どのようにログインしたのでしょうか。自分で試してみてください。



その理由はキーボードでした。2つのボタンが逆になっています。プログラマーが座っていたとき、彼は盲目的にタイプし、問題は見過ごされました。そして立ったとき、それは彼を混乱させ、彼はボタンを探してそれらを押しました。このヒントとスクリュードライバーで武装して、デバッグの専門家はボタンを交換し、すべてがうまくいきました。



シカゴに配備された銀行システムは、何ヶ月もの間うまく機能しました。しかし、国際データの処理に最初に使用されたとき、予期せず終了しました。プログラマーは何日もコードをいじくり回しましたが、プログラムの終了につながる単一のコマンドを見つけることができませんでした。彼女の行動を詳しく調べたところ、エクアドルのデータが入力されるとプログラムが終了することがわかりました。分析によると、ユーザーが大文字の名前（Quito）を入力すると、プログラムはそれを終了コマンドとして解釈しました。



ある日、ボブ・マーティンは「2回機能する」システムに出くわしました。最初のトランザクションを正しく処理し、その後のすべてのトランザクションで小さな問題が発生しました。システムが再起動されると、最初のトランザクションが再び正しく処理され、後続のすべてのトランザクションで失敗しました。ボブがこの動作を「2回実行する」と説明したとき、開発者は、プログラムのロード時に正しく初期化されたが、最初のトランザクション後にリセットされなかった変数を探す必要があることにすぐに気付きました。すべての場合において、正しい質問により、賢明なプログラマーは不快な間違いをすばやく特定することができました。「立っているときと座っているときの違いは何でしたか？どちらの場合もログイン方法を教えてください "、"プログラムが終了する前に正確に何を入力しましたか？ " 「クラッシュが始まる前に、プログラムは正しく機能しましたか？何回？」



Rick Lemonsは、デバッグについて学んだ最高の教訓は、魔術師の演技を見たときだと言いました。彼は十数の不可能なトリックをしました、そして、レモンは彼がそれを信じていると感じました。その後、彼は不可能は不可能であることを自覚し、この明らかな矛盾を証明するためにあらゆるトリックをテストしました。レモンは揺るぎない真実、つまり物理の法則から始め、そこから各トリックの簡単な説明を探し始めました。この姿勢により、レモンは私が出会った中で最高のデバッガーの1つになっています。



私の意見では最高のデバッグ本はある医療探偵、Berton Rouecheによって書かれ、1991年にPenguinによって公開されました。この本のヒーローは、中程度の病気の人から非常に病気の都市まで、複雑なシステムをデバッグします。そこで使用されている問題解決方法は、コンピューターシステムのデバッグに直接使用できます。これらの実話は、他のフィクションと同じくらい魅力的です。

500マイルのメールケース

ここでの状況です打診考えられない...私はほとんどそれが会議のための偉大な自転車があるので、それについて話すことを拒否しました。私は、犯人を保護し、無関係で退屈な詳細を破棄し、全体的にストーリーをより魅力的にするために、ストーリーを少し調整しました。



数年前、私はキャンパスで電子メールシステムを維持していました。統計局長から電話がありました。



-手紙の送付に問題があります。



- どうしたの？



「500マイルを超えて手紙を送ることはできません。



私はコーヒーを窒息させた。



- 理解されていない。



「500マイルを超えて部門から手紙を送ることはできません。実際、もう少し。約520マイル。しかし、これが限界です。



「うーん…実際、メールはそのようには機能しません」と私は自分の声でパニックを抑えようとして答えました。統計学科のような学科長との会話では、パニックを示すことはできません。 -なぜ500マイル以上手紙を送ることができないと決めたのですか？



「私は決めていません」と彼は重く答えた。 -ほら、数日前に何が起こっているかに気づいたとき...-数日



待ったのですか？私は震える声で彼を断ち切った。 -そして、あなたはいつも手紙を送ることができませんでしたか？



-送ることができました。それ以上は…



」「500マイル、はい」私は彼のために終わりました。 - 晴れ。しかし、なぜ早く電話しなかったのですか？



「まあ、この時点まで、何が起こっているのかを確認するのに十分なデータがありませんでした。



まさに、これは統計の責任者です。



-とにかく、私は地質統計学者の1人にこれを扱うように頼みました



...-地質統計学者...-



はい、そして彼女は私たちが手紙を送ることができる半径を示す地図を作りました、500マイル強。このゾーンには、手紙がまったくまたは定期的に届かない場所がいくつかありますが、半径の外側では何も送信できません。



「なるほど」と言って、頭を両手に落とした。 -いつ始まったの？あなたは数日前にそう言ったが、私たちはあなたのシステムで何も変更していない。



-コンサルタントが来て、パッチを適用し、サーバーを再起動しました。しかし、私は彼に電話をしました、そして彼は彼がメールシステムに触れなかったと言いました。



「さて、見てみて、電話をかけ直します」私はそのようなことに参加しているとは信じられずに答えました。今日は4月の最初ではありませんでした。私は誰かが私にいたずらを借りているかどうかを思い出そうとしました。



私は彼らの部門のサーバーにログインし、いくつかの確認メールを送信しました。これはノースカロライナリサーチトライアングルで行われ、手紙は問題なく私のメールボックスに届きました。リッチモンド、アトランタ、ワシントンに送られた手紙もそうだった。プリンストン（400マイル）に送られた手紙もありました。



しかし、それから私はメンフィス（600マイル）に手紙を送りました。来なかった。ボストンでは、それは来ませんでした。デトロイトでは、それは来ませんでした。私は自分のアドレス帳を取り出して、それを通して手紙を送り始めました。ニューヨーク（420マイル）には到着しましたが、プロビデンス（580マイル）には到着しませんでした。



私は自分の正気を疑うようになりました。プロバイダーがシアトルにあったノースカロライナの友人に手紙を書いた。幸い、手紙は届きませんでした。問題がメールサーバーではなく受信者の場所にあるとしたら、私はおそらく突然涙を流したでしょう。



問題が（信じられないほど）存在し、再現可能であることがわかった後、sendmail.cfファイルの分析を開始しました。彼は元気そうだった。いつものように。ホームディレクトリのsendmail.cfと比較しました。違いはありませんでした-それは私が書いたファイルでした。そして、私はオプションを含めなかったとかなり確信していましたFAIL_MAIL_OVER_500_MILES。混乱して、私はSMTPポートに電話をかけました。サーバーはSunOSからのSendmailバナーで喜んで応答しました。



待ってください... SunOSからのSendmailバナー？当時、Sendmail 8はすでに完全に実装されていましたが、SunはまだそのオペレーティングシステムとともにSendmail5を出荷していました。私は優れたsysadminだったので、Sendmail8を標準として導入しました。また、私は優れたsysadminだったので、sendmail 5で使用されていた不可解な句読点コードではなく、Sendmail8で使用できるクールで長い自己文書化オプションと変数名を使用するsendmail.cfを作成



しました。そして、私はすでに冷やしたコーヒーを再び窒息させました。コンサルタントが「サーバーにパッチを適用」したとき、彼はSunOSバージョンをアップグレードし、そこから古いバージョンのSendmailをロールアウトしたようです。幸い、sendmail.cfファイルは存続しましたが、現在は機能しませんでした。



ほとんどのルールが同じであったため、Sendmail 5（少なくとも多くの改善が加えられたSun出荷バージョン）はSendmail8のsendmail.cfで機能することが判明しました。しかし、新しい長い構成オプションは認識されず、破棄されませんでした。また、Sendmailバイナリにはほとんどのデフォルト値がなかったため、プログラムはsendmail.cfで適切な値を見つけられず、ゼロにリセットしました。



これらのゼロ値の1つは、リモートSMTPサーバーへの接続タイムアウトでした。いくつかの実験の結果、この特定のマシンでは、通常の負荷の下で、タイムアウトがゼロの場合、3ミリ秒強で切断されることが判明しました。



当時、キャンパスネットワークは完全にスイッチベースでした。発信パケットは、POPを介して反対側のルーターに到達するまで遅延されませんでした。つまり、隣接するネットワーク内の負荷の弱いリモートホストへの接続時間は、ルーターによるランダムな遅延ではなく、光の速度でカバーされる距離にほとんど依存していました。



少し目がくらむように感じて、私はコマンドラインで入力しました：

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

「500マイル以上」

---

つづく。