How to debug codes

筆者の個人的な経験によるデバッグの仕方 [最近やらかしたバグ、失敗][Top]

目次: 具体例; デバッグの仕方; 標準となるプログラムを用意しておくこと; 考えが煮詰まったらしばらくうっちゃっておく; その他、デバッグのための（経験的な）常套手段; 常套手段（まとめ）; どんな時でもデバッグは大変である; 予想されるバグの例; 並列化作業でのバグの例（parallel.htmlページへ）

（関連文献）筆者が２００９年１０月から２０１０年９月まで雑誌「金属」で連載した[記事 ]の第九回参照。

具体例

ここでは各論（各サブルーチンの説明）に入る前に、最近やらかしたバグの話しをしてみたいと思います。バグがあったのはこのルーチンです。

このルーチンは希土類計算を目的として、非局所ｆ部分に対応するルーチンをｓ、ｐ、ｄ非局所に対応していた元のプログラムに付加したもので、この改良過程で生じたバグです。全エネルギーの計算結果とストレスの計算結果が一致しないとうい問題が生じました。十分にエネルギーカットオフを取れば、全エネルギーの最小なところでストレスの値はゼロになるはずですが、実際計算してみると、全エネルギー最小なところで、ストレスの値が有限で大きな値をもってしまいました。

このルーチンの問題を以下に説明します。文番号１４００の変数Ｌに関するループの外側で、ＣＷＬなる配列に値を代入しています。ここで、ＣＷＬ（１０）は扱う原子がｓ、ｐ、ｄ非局所かｓ、ｐ、ｄ、ｆ非局所かで値が異なります。それを次のループ（文番号１９２２、１９２３）の内側のＩＦ文で条件設定しています。

実はこれが間違いで文番号１９２３のループは個々の原子に関するループで、このループ内ではＺＦＣなる配列変数の初期化を行なっているだけです。そしてＣＷＬが実際に使用されるのは次の文番号１４２０、１４１０のループです。ところが、ＣＷＬの値は前の文番号１９２３のループで定義されています。

扱う系が原子１種類だけの場合は問題ないのですが、ｓ、ｐ、ｄ非局所な原子とｓ、ｐ、ｄ、ｆ非局所な原子からなる系を扱う場合には正しい計算を行なわなくなります。最初、Eu（ｂｃｃ構造）の計算を行なった時は、全エネルギーとストレスの値の関係は正しいものでした。ところがEuS（岩塩構造）では正しい関係にならず、先に述べたような不一致が出てきました。これは、このルーチンのままだと、最初の原子（Eu、希土類、CWL(10)=3.0D0）の段階で、次の原子Sの設定（CWL(10)=1.0D0）が行なわれてしまっています。

このためｓ、p、ｄ非局所とｓ、ｐ、ｄ、ｆ非局所の２種類以上の原子からなる系を扱う場合はバグが存在することがわかります。ここでバグを修正した正しいルーチンを示します。
この修正された（必ずしも速度的なチューンアップや、プログラムの構造的な正しさ美しさを考慮していません。）ルーチンをみればわかるように、ＣＷＬ（１０）のＩＦ文による条件別設定を文番号１４１０のループ内で行なうようにしました。これでEuS岩塩構造でも全エネルギーとストレスの関係は正しく出るようになりました。（但し、希土類金属としての計算が正しくできるようになったわけではない。実は、希土類金属の擬ポテンシャルによる計算は大変難しく、まだ検討しなければならないことが多数残っています。）

デバッグの仕方

バンド計算プログラムを作っていると、いろいろな局面でバグに遭遇し、何日も何週間も、場合によっては何カ月も悩まなければならないことがあります。ここでは、そのような場合（特に、何カ月もデバッグに費やさなければならない時）での対処の仕方について述べていきたいと思います。

（１）標準となるプログラムを用意しておくこと
これは既存のプログラムを拡張、改良する場合には当然必要なことです。つまり改良、拡張中にバグが見つかり、デバッグ中の場合、最低この段階まで戻れば正しい結果を与えるオリジナルプログラムを用意しておくことが必要です。このオリジナルプログラムが必ず正しい結果を与えるのならば、改良、拡張中のプログラムの実行結果のチェックがいつでも可能で、万が一、不一致が生じてもプログラムの変更箇所が容易にわかり、デバッグの助けになります。

（この時、改良、拡張は一気に行なうのではなく、適当な段階毎にコンパイル、実行し常に計算結果のチェックを行ないながら仕事を進めていくのが良いかと思います。こうしておけば、結果の不一致があっても、最初のオリジナルではなく直前まで正しく動いていたバージョンと比較できるので、変更箇所の量がオリジナルと比べてずっと少なくて済み、間違っている部分を発見することが非常に楽になります。〔その変わりバージョン管理をしっかりやらねばなりません。〕）

もし正しい結果を与えるオリジナルプログラムがない場合、実行結果が明らかにおかしかったりする場合はまだいいのですが、どうも微妙にとか、何となくおかいし場合に、よって頼るべきもの（つまり、この段階での計算なら正しいと自信が持てるもの）がないので、デバッグが非常に困難なものとなります。

（２）考えが煮詰まったらしばらくうっちゃっておく
デバッグというものは非常に困難な作業であり、プログラムのコーディングは、数日、数週間でできても、デバッグは何カ月もかかってしまうことがあります。何カ月もかけてバグがとれれば良いのですが、場合によってはにっちもさっちもいかなくなることもあります。ほとほと考えが煮詰まってしまって万策尽き、もし、他にも重要な仕事があったり、逆にそれほど時間的に切迫していなければ、思い切ってデバッグ作業を一時中断し、別の仕事を行なうか、家に帰って寝てしまうかして、気分転換を計るという手があります。
これはあくまで、経験的な話しですが、２週間とか１カ月ほどデバッグ作業をしないでいて、久しぶりに問題のプログラムを眺めていると、ふとバグに気付くことがあります（必ず気付くわけではないし、何の根拠もない）。

他にも、”間際効果”というものがあり、学会発表や、Ｄ論の発表が近付くと、不思議とバグが見つかり、一気に仕事が進むことがあります。（この間際効果なるものにも、その存在を証明する根拠はどこにもないです。）

（３）その他、デバッグのための（経験的な）常套手段
いくつかありますが、思いつくまま以下に挙げていきます。

（イ）取り敢えずデバッガーを使ってみる
対象となる計算規模がさして大きくなく、エラーもすぐに出てくる場合は、この方法は非常に有効であると思われます。但し、デバッガーの使い方を熟知していることが必須です。また計算規模が大きい場合、デバッガーが動かない場合があります。更に、コンパイラーの種類にもよりますが、UNIX系のコンパイラではデバッグオプション（普通 -g）を付けると最適化を行ないません（最適化モード用のデバッグオプションのあるコンパイラ〔例DEC-FORTRAN〕もあるにはあります。）。従って、エラーの出てくる箇所まで到達するのに大変な時間が掛かってしまうことがあります。

従って、どのような場合にもデバッガーが万能であるとは言えません。因みに筆者はめったにデバッガーは使いません（使い方も良くわかっていないのも理由の一つ）。

（ロ）計算の途中結果を出力する
これは、一番確実で正統的な方法かもしれません。とにかく、エラー箇所に到達するまで、各ルーチン毎に計算結果を片っ端から出力するという手です。この場合、前述の確実に正しい結果を与えるプログラムによる途中結果との比較ができればエラー箇所を見つけることは比較的容易な場合があります。但し、気を付けないと、大規模な繰り返しＤＯループ中に下手にＷＲＩＴＥ文を書いておくと、大変な量の出力が生じます。もしこれをファイルに書き込むようにしておくと、たちまちディスクが溢れてしまい、システムが止まってしまう可能性すらあります。またバッチジョブ形式でジョブを投入してると、例え６番に書き出して（WRITE (6,100) A(N)等）いても、ジョブ用のバッファが溢れてしまいジョブが異常終了してしまいます（場合によっては、これもシステムを止める原因になります）。

計算途中のデータを書き出すときは、くれぐれもこのようなことにならないように細心の注意（特に所属組織の共通〔共有〕の計算機システムを使っている時）が必要です。データの出力は何も全部出す必要がなく、例えば大きなＤＯループ内の変数の場合、可能ならその和をとり、それ同士を比較するという手があります。

（ハ）コンパイル時のオプションを変えてみる
コンパイラの最適化が厳し過ぎるため、正しくない結果を与えることがあります。途中で異常終了する、計算結果が明らかにおかしい場合に、コンパイラーの最適化レベルを下げて再度計算してみると正しい結果を与えることがあります。この場合、コンパイラーのバグなのか、プログラム側のバグなのか判然としない場合もありますが、他機種では最適化しても正しい結果を与える場合はそのコンパイラーのバグを疑ってみる必要があります。

このようなコンパイラーのバグと思われる場合、エラーの起こる箇所付近にＷＲＩＴＥ文（時にはコメントなど）を挿入するだけで正しく動いてしまうことがあります。このような場合、プログラム上の問題が残っている場合もあり得ますが、コンパイラーのバグも疑ってよいかと思います。このような時には、コンパイラーの製造元（普通、大型機やワークステーションの世界ではコンパイラーとマシンの製造元は一致します）になるべく早く問題を指摘することを勧めます。相手側が適確に動いてくれるかどうかは当該するメーカーに強く依存します。

ただ、この手のコンパイラーのバグに引っかかるプログラムは、プログラム側にも何らかの問題（プログラムの内容に非常にトリッキーな部分がある、例えばサブルーチンの呼び出す側と呼び出される側の引数〔変数〕の型を〔高速化のため〕わざと一致させない場合があります。本当はやってはいけないことですが、それでも大抵コンパイラーは通ってしまい、正常な結果を与えてしまいます。）を抱えている場合が多くあります。一概にコンパイラーだけを悪者にすることは（もっと重大な問題を見落す可能性があり）大変危険なことになります。

（ニ）異なるシステム同士で比較する
異なる計算機上で、問題のプログラムを動かし、エラーの出方を比較するという手があります。これはどのような場合でもうまく行くというわけではありません。かなり特殊な状況の場合と思ってください。

デバッグの場合、時にはエラーの箇所が判然とせず、エラーの原因も皆目見当もつかない場合があります。この時、異なるシステムで問題のプログラムを動かし、計算途中の結果やエラーメッセージの違いからエラーの原因を見つけ出せることが（たまに）あります。ただし、これは互いのシステムをある程度以上熟知しており、この手の計算やデバッグの経験が相当ないとこの手の手法は使えないと思います。

（ホ）誰かに相談する。または誰かとエラーについて議論してみる
意外とバグというのは、担当している本人には気付きにくいものですが、他人がみるとすぐに指摘できてしまう時があります。また、共同研究者や、同じ研究室の同僚（テーマは違っても大抵バンド屋さんと思われます）とプログラム上の問題について話し合っている内に、ふと解決策が頭に浮かんでくることがあります。場合によっては、全くの門外漢の人との議論からエラーの原因がわかることもあります（あるでしょう）。

（ヘ）バグも仕様の内（「マーフィーの法則」アーサー・ブロック著、アスキー出版局刊より）としてしまう
これは大変危険な解決策です。明らかに、バグが致命的でなく、計算上もさして重要な影響を与えることはないと判断できるなら、バグをそのままにしておくという手もあります。特に、単なる出力フォーマット上の問題のような、明らかに計算そのものに全く影響を与えないようなバグは、一時無視してほうっておくことも可能です。

但し、バグが計算に関わっている場合は、安易にそのままにしておくことは決して勧められません。余程その計算に熟知し、この手のバンド計算に熟練していなければ、鷹をくくることは非常に危険です。今、問題がなくても後々大問題になる可能性が大きいです。

これからバンド計算に手を出そうとする人は、バグがあれば徹底的に原因をつきとめ、問題を解決するような習慣を最初からつけておくことを強く勧めます。

以上を簡単にまとめると
１、正しい結果を与える標準となるべきプログラムを必ず用意する。
２、取り敢えずデバッガーを使ってみる。（アナライザもあれば役立つかも）
３、他に迷惑をかけない範囲で途中結果を出力する。（１、と比較）
４、計算条件（系のサイズや原子の種類など）を変えてみる。
５、コンパイラーのオプションを変えて実行（例、最適化のレベルを下げる）。
６、異なるシステム（ＯＳ、機種など）同士で実行、比較してみる。
７、デバッグ作業の履歴をきちんと記録しておく。
８、デバッグに伴うプログラムの変更箇所には必ず注釈をつける。
９、バグが見つからない時は、いろいろな方法を試してみる。
１０、信頼できる人々（１人だけでなくてよい）に相談（議論）する。
１１、バグは大抵単純（時に見つけ難い）で深刻な影響を与えるものがほとんど。
１２、先入観（思い込み）を棄てる。（虚心坦懐に）
１３、デバッグ作業を面倒がらない。（急がば回れ）
１４、可能な限り妥協してはいけません。（結局問題を先送りするだけ。）
１５、いよいよ煮詰まったら、しばらくほうっておいてみる。（気分転換）
１６、末期段階、バグも仕様の内と開きなおる（本当は絶対やっちゃいけない）。

やはり、１６に関して、明らかに間違っている計算結果をもってして、研究を進めて（間違いを承知していながら、それを正しいデータと偽って研究発表等を行なうこと）いくことは研究者の態度としては論外といえるものです。良い研究者はこのようなことをしてはいけません。

（４）どんな時でもデバッグは大変である
特に、バグの中で問題なのは、何が何だか分らないバグ（原因不明で止まり、どうして止まるか分らない場合、系のサイズを大きくしたりと、ある条件にすると原因不明で止まる場合など）、正しい計算結果と比べて微妙（無視できない程度）に値が異なるバグ（これが一番厄介だと私は思っています。）などです。

何がなんだか分らないバグの場合、先に述べた（イ）から（ホ）までの手段や１から１５までの事柄を踏まえて、とにかく原因を突き止めることです。むしろ途中で止まるバグや、計算結果が全くでたらめ（大き過ぎたり、小さ過ぎる）な場合は、ある程度以上の経験を積むと対処できるようになっていきます。それまでは、いろいろなデバッグ手段をためし、いろいろな条件設定の下での計算結果の比較検討を行ない、わからないことはマニュアルや参考文献を探し、それでもわからない時は、良く知っていそうな人（指導教官、所属研究室の助手、先輩、同僚などで頼りになりそうな人で、できればあまり忙しそうにしていない時）に質問するなり、助けを求めるなりして、経験を積んで貰うしかないと思います。

むしろ、微妙に値が違う場合は、原因がはっきりしていれば対処できますが、大抵こういうような局面では原因がさっぱり分らないことが多いです。但し、この手のバグは大抵単純（故に見つけ難い）ながら、計算結果に深刻な影響を与えている場合が多いです。
（予想されるバグの例）これらの例をいくつか挙げると、

単純な係数の間違い。（例４＊を２＊とした、や単位系の間違いなど）

計算すべき式が、もともと間違っていた。（論文の式は鵜飲みするな）

（配列）変数等の初期化の間違い。（例、ゼロにしたつもりでそうなっていない。）

（配列）変数の定義の間違い。（例、型の不一致）

配列変数で、定義した外側の領域にアクセスしようとした。

サブルーチンへの（配列）変数の受け渡しの間違い。（変数の数や型の不一致）

（配列）変数名のスペルミス。

入力データの間違い。

計算制御変数の間違い。（例、時間刻み幅のミスや結晶対称性の間違い）

その他

などなどです。

特に、サブルーチンで受け渡す側と受け取る側の変数の数や型が合わなかったり、変数名のスペルミスはコンパイラーがエラーを出さない、出せない場合があります。また入力データの間違いや、計算条件の設定ミスもコンパイル時にはエラーが出ません。（サブルーチンの変数受け渡しの問題は、コンパイラーの種類によって、標準ではエラーの出ないものが多いですが、大抵はオプションでエラーを出せるようにはなっています。オプションについてはmanコマンドか、マニュアルを参照してください。）

配列変数で、定義した外側の領域にアクセスしたというのは、つまり配列ＡがＡ（１０００）と定義してあったとして、１００１番目以降のＡについて演算、代入等の操作をしようとしたことを意味しています。（動的なメモリーの割付けが行なわれ、それに配列Ａが対応するようにできていれば〔本当にできるかは、いまのところ私にはわかりません。〕問題ないかもしれません。）

この場合、コンパイルの時点ではエラーは出ない場合がほとんどです。大抵は実行時に記憶領域を壊したとか、セグメントが壊れたとか、記憶領域障害とかエンドユーザーにはさっぱりわけの分らないエラーメッセージが出て、プログラムが止まってしまいます。これは、定義した以外の配列の領域を使用したため、メモリー（記憶領域）上のデータがおかしくなってしまうためで、この場合、エラーも配列の操作を間違えたところとは全く関係ないところで止まってしまいます。このため、エラー箇所が見つけ難くなっています。

このエラーを見つけるためには、デバッガーを使うことが有効かもしれません（コンパイル時にデバッグオプションが必要、またデバッガーの操作も熟知していることが必須）。またコンパイルオプション（詳細は各システムのマニュアルを調べるか、そのシステム〔UNIXを想定〕上でman f77としてみる。）で実行時の配列領域違反している部分を指摘するようにさせることができるものがあります（大抵できると思います）。ただ、この方法はこのような場合には全く無力であることも多く、非常にデバッグに苦労することがあります。

この逆の場合として、考えていた数より、ずと少ない数の配列しか使っていないバグもあります。”やさしいバンド計算プログラムの作り方”のところで、変数、配列定義用のインクルード文ＰＡＣＶＰＰの説明をしたかと思います。そこに、KNGとKNG1という変数が定義されています。この変数の大小関係は必ずKNG > KNG1です（大体KNG=8*KNG1）。

以前、計算ルーチン内のＤＯループ変数で、KNGとすべきところをKNG1として計算していたことがありました。一文字違うだけですが、このバグで大変苦労しました。KNG > KNG1で、関係する配列等はちゃんとKNGまで定義してあったので、記憶領域障害等のエラーもでず、計算そのものも何のエラーも示さず、正常に終了していました。しかし、どうも計算結果が微妙に（表現が難しい）おかしいと思いました。当初は計算機誤差だろうと鷹をくくっていたのですが、どうも気になって、いろいろなテスト計算をしていく内に、何らかのバグと考えるようになりました。しかし、このバグの追求は困難を極め、バグ取りを試みて、疲れてほうっておいて、またバグ取りを試み、また疲れて他の仕事をするというのを繰り返して、何カ月もかかって、プログラムリストを何度目かの点検をしている時に、ふとＤＯ文の制御変数が１からKNGではなく、KNG1になっていて、実際このループではKNGではないかと気付いて、バグがようやく取れた経験があります。バグとしてはたった一文字の違いで、非常に単純でしたが、非常にデバッグに苦労した例です。

また並列化作業の上で犯したバグの例が”ＦＡＣＯＭＶＰＰ３００、５００での並列化”編にあります。

[先頭][総目次 ][最初に戻る][ＦＡＣＯＭＶＰＰ３００、５００での並列化 ][最近やらかしたバグ、失敗]
[大阪弁]