プログラミングは難しい・・・

数値シミュレーションを生業とする研究者でも、最近は自分でプログラムコードを書かずに、できあいの解析ソフトを使っている人もいるらしい。私は、別に数値シミュレーションだけやっているわけでもなく、別に古風（？）んばこだわりを持っているというわけでもないけど、自分で書き起こすことが多い。

別にできあいのソフトで良いのがあれば、それでも良いと思っているんだけど、実際には妥協せずにあれこれ機能にこだわりだすと、結局どれも自分の理想に合わないので、自作せざるを得ないというのが、一番の原因。

ただ、自作すればしたで、悩みが多いのも事実。当たり前だけど、やはり、自分で書いているだけあって（笑）、バグが多い。

もちろん何年もやっているので、プログラムの動作に致命傷を与えるようなものは、簡単に取り除けるようにはなったけど、問題はまともに動いてるフリして、答えが間違っているというタイプ。当然、自分の用意しているエラー検知システムをかいくぐってくる。しかも、大間違いならすぐ気づくけど、ちょっとだけ「？」という程度の症状のもの。

そういうのは、大体が、わずかなバッファーオーバーフローが原因だとは分かっているのだけど、その場所を探し出すのが大変。

バッファーオーバーフローは、OSなどでそういうバグがあると、そこからウイルスを実行させるスキになったりするということで、セキュリティ用語として有名かも知れません。私のプログラムは、別にスキになったりすることはないけど、要は、メモリ上に予定で用意した領域サイズ以上の情報を送り込んでしまい、そして、知らないうちに予定外のメモリ領域を浸食し、不思議な動作を始めてしまう・・・。予定外の領域なので、何も変更の命令を与えていないはずのところが書き換わってしまっていたりする。

まあ、要は、勝手にパンクして誤動作し、自爆しているということなわけですが・・・。

そんなの簡単に検知できそうだけど、意外に簡単ではない。たとえば、私はコード内に自作で埋め込む検知システム以外に、普段から配列のオーバーフローを検知するような命令も与えてコンパイルしているので、理論上は見逃さないはず。しかし、おそらくその命令も完璧ではなく、現実には、わずかに見逃してしまうケースがあるということのようだ。

コンピュータ自身が気づかないわずかなほころび・・・。それをどうやって探すかというと、結局、最終的には、どこで破綻が開始しているかを前後から挟んでいって確認するという原始的な方法で探すことになる場合がほとんど。そして、絞り込んできたら、アルゴリズム上は順番が逆でもいいものを逆にしたりして、動作の変わり具合を見て当たりを付け、あとはじっと眺めて誤りを探すという感じ。

探し当てたときには、嬉しいと言えばそうですが、なぜにこんなにダイレクトにおかしいものが気づかれないで実行されてしまうのか、コンピュータの神秘にも首をかしげます。

もちろん、いい加減でも動いてくれる部分があるから、「多くの場合まっとうに動くけど、まれに誤動作する程度のバグを含むプログラム」という段階でも、答えが出てくるようになるわけで、それがメリットになるときもあるとは分かっているのですが・・・。

それにしても、ミクロには０と１という単純な仕組みで動作しているものが、マクロな結果としてファジーな挙動を見せるのは、何とも不思議。

バッファーオーバーフローを厳しく検知できる一般的な仕組みが、未だに開発されておらず、日々そのバグを含んだソフトが世に供されている現状を見ると、その不思議な挙動は、未だ人間の完全なる理解の支配下におけていないのかもしれません。

それとも、そのような厳しい仕組みを作ってしまうと、逆にあまりにも厳しすぎて、ミスの多い人間では永遠にコードが完成させられないということもあるのかも・・・？

まあ、何にしても間違っているものは直していかないと行けないので、やることは一緒。

日々、間違い探し。これは、しょうがない。

今作っているのは、意図したとおりに動いてくれれば、私の分野で50年来の謎とされてきた部分に対して、自分の開発した最新理論を組み込んで解析できる世界で一つのプログラム。その夢を励みに、地味にコツコツ頑張るのです・・・。

タグ：コンピュータ