How to debug codes

筆者の個人的な経験によるデバッグの仕方（大阪弁モード） [Top]

本ページは、Satoshi Takahara先生の、”ホームページ大阪弁化計画”によって、大阪弁化されたものです。変換による、原文との微妙な相違や、不具合はチェックしていません。

この大阪弁化ホームページは実質上使用不能になってしまっていたのですが、最近新たに[大阪弁化ページ ]（大阪弁以外にも多数の方言などに変換できます、上記Satoshi Takahara先生のページのパクリだそうです）を発見しました（本ページは、この新たなページでの再変換は行なっておりません）。

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

ここでは各論（各サブルーチンの説明）に入る前に、きょうびやらかしたバグの話しをしてみたいと思うで。バグがあったのはこのルーチンや。クリック

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

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

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

扱う系が原子１種類だけの場合は問題ないのやが、ｓ、ｐ、ｄ非局所な原子とｓ、ｐ、ｄ、ｆ非局所な原子からなる系を扱う場合には正しい計算を行なわなくなるんや。最初、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ではおまへんかと気付いて、バグがようやっと取れた経験があるんや。バグとしてはたった一文字の違いで、どエライ単純やったが、どエライデバッグに苦労した例や。

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

[アタマ][総目次 ][最初に戻る][ＦＡＣＯＭＶＰＰ３００、５００での並列化 ][きょうびやらかしたバグ、シッパイ ]
[原文]