個人で便利ツールを開発しているOさんが、過去に遭遇した出来事です。
当時、Oさんは自作ツールの信頼性を高めるため、想定外のエラーが発生してもプログラムが突然強制終了しないよう、全体に丁寧な例外処理(try-catch)を記述していました。
開発も終盤に差し掛かったある日の深夜、テスト実行を行っていた時のことです。
それまで一度も出たことがなかった場面で、 catch ブロックが作動し、自作のエラーログ出力処理が画面に通知を吐き出しました。
[Error Code: 0x5461736b... - Unknown Exception]
メッセージはシステム標準の「NullPointerException」や「FileNotFoundException」といった既存のクラス名ではなく、定義した覚えのない謎の16進数コード(HEX)でした。
「どこかでメモリの値でも化けたか?」
Oさんはログファイルを開きました。通常なら数行で終わるはずのエラーログですが、なぜか数メガバイトにも及ぶ大量の16進数がびっしりと書き込まれていました。
ただのスタックダンプやバイナリのゴミデータかとも思いましたが、よく見ると特定の範囲のバイト列(0x20〜0x7E)に偏っていることに気づきました。これはASCII文字の可読範囲です。
気になったOさんは、テキストエディタの置換機能や簡単なデコードツールを使って、その16進数を文字列(ASCIIテキスト)へ変換してみることにしました。
変換ボタンを押した瞬間、画面いっぱいに表示されたのは、プログラムのエラーメッセージではありませんでした。
日本語混じりの、びっしりと敷き詰められた文章でした。
「…は?」
Oさんの背筋に、冷たいものが走りました。
自分が書いたコードのどこを探しても、そんな文字列を扱う処理や変数は存在しません。ネットからのライブラリ呼び出しもなく、完全なローカル環境で動かしていたツールです。
「イタズラか? いや、一人で書いてるコードだぞ…」
恐怖を振り払おうと、Oさんはデバッガを立ち上げ、その例外(Exception)を発生させている発生元(throw)の行を特定しようとしました。
しかし、ブレークポイントを設定してステップ実行を開始すると、プログラムは処理を通過するのではなく、一度も呼び出していないはずの空のメモリブロックで勝手に停止します。
そして、キーボードを叩くわけでもないのに、コンソール画面に新しい16進数がリアルタイムで「カカカカ…」と高速で追記され始めました。
あわてて画面上のデコード用ウィンドウを見ると、リアルタイムで訳された文章が更新されていきます。
文字の追記スピードがどんどん加速し、モニターのスピーカーから「ジジジ…ジジ…」と、ノイズに混じってキーボードを乱打するような音が響き始めました。
パニックになったOさんは、マウス操作すら諦めてPCの電源プラグをコンセントから引き抜きました。
ブツン、と音がして画面が消えると、深夜の静まり返った部屋に自分の荒い息遣いだけが残されました。
翌日、明るくなってから恐る恐るPCを起動し、そのプロジェクトのソースコードを開いてみましたが、ログファイルも、昨夜の現象を再現するコードも綺麗に消えていました。
ただ、そのツールをビルドしようとすると、今でも稀に、処理の途中で1ミリ秒だけ「Unknown Exception」のダイアログが一瞬だけ画面を横切ることがあるそうです。
Oさんはそれ以来、自作ツールに「try-catch」を書くのが怖くなり、例外処理をすべて外してしまったということです。



0 件のコメント:
コメントを投稿
I'm sorry, Japanese text only.
荒らし目的と思われるコメントは気づき次第対処します。