第 6.5 回 fortran 勉強会 - it pass (informational … お品書き バグ・デバッグとは...
TRANSCRIPT
事前準備
● 以下のサイトから今回の資料をダウンロードする.– http://itpass.scitec.kobe-u.ac.jp/~fourtran/Nagoya-
Fortran/seminar-6.5.tar.gz
バグ・デバッグとは
● 「バグ」=コンピュータプログラムに含まれる誤りや不具合のこと. (『IT 用語辞典』より)– この用語の語源はいくつかあるようであるが割愛!
– 特にソフトウェアにおいて「ソフトウェアエラー」とも.
– バグは発生するステージに関して, いくつかの種類に分類できる.
● 「デバッグ」=「バグ」を発見し, 修復すること.– まず, 発見することが重要.
– 発見することができなければ修復はできない.
– バグの種類によってデバッグ方法を適切に変更する.
バグ(ソフトウェアエラー)の種類
● 構文エラー(コンパイルエラー)– プログラム言語の文法, 構文が正しくないときに発生するエラー.
● 変数の型が違う, 括弧の数が足りないなど.
● 実行時エラー(ランタイムエラー)– プログラムを実行したときに発生するエラー.
– 多くの場合, 異常終了する.
– コンパイルは通るので, コンパイラでは検出不可能.● 論理エラー
– プログラムの実行結果が期待していた結果と異なるなど, 計算式や論理的な間違いによって発生するエラー.
– 計算機側でエラーが検出不可能.
バグの分類
● セグメンテーション違反.– 主に, メモリアクセスについてのエラー.
● 書き込み権限のないメモリ領域へ書き込む.● 読み取り権限のないメモリ領域を読み込む.
– 領域外参照はこの1つ(読み込む範囲外を読み込もうとしている).
● 浮動小数点例外.– 浮動小数点演算(IEEE 浮動小数点数演算標準?)における演算処理で発生する例外.
– 以下は, 浮動小数点例外の例.● 算術オーバーフロー.
– その型で表せる数値の範囲を越えること(桁あふれ).● ゼロ除算.
構文エラー 実行時エラー 論理エラー
• 括弧の数が足りません.• 変数は定義されていません.• 引数の型が違います.• 配列の型が一致しません.• 引数の数が違います.
• セグメンテーション違反.• 領域外参照.• 浮動小数点例外.• 算術オーバーフロー.• ゼロ除算.
• 計算結果が違う.• 計算結果が返ってこない.
バグの検出
● 構文エラー– コンパイルの段階でコンパイラによって検出.
● 実行時エラー– コンパイル時にコンパイルオプションをつけることで, 実行時に
エラー内容を検出.● ソースファイルの何行目で何が原因で止まったかなど.
– デバッガにより検出.
● 論理エラー– デバッガの逐次実行により検出.
– 地道なソフトウェアテスト.
構文エラーの検出
● implicit none● 変数に属性を付加.
– intent, parameter, save 等
● ルーチンをモジュール化, 内部手続き化.● コンパイルオプション(ifort の場合)
– “-warn all” : コンパイル時にエラー・警告を出力.
– “-warn declarations” : implicit none と同義.
– ”-std” : 標準外機能を利用していることを警告.
Fortran はその固有の仕様(暗黙の型宣言等)により, 構文エラーの一部もコンパイルオプションなしでは検出できない可能性がある.
実行時エラーの検出
● 最も単純な方法– write 文を用いる方法.
● write 文で標準出力させることにより, どこまでプログラムが実行されたかを検出. 逐次修正.
● 非常に効率が悪い.– write 文を毎回挿入しなければならず, その度に再コンパイルが必
要.
実行時エラーの検出
● コンパイルオプションによる検出– “-CB”, “-check bounds”
● 配列の領域外参照を検出.
– “-check uninit”● 初期化されていない変数を検出.
– “-fpe0”● 浮動小数点例外発生を検出.
– “-traceback”● 異常終了したソースコードの行番号を検出.
実行時エラーの検出
● デバッガによる検出(推奨)– デバッグを支援するソフトウェアの総称.
– プログラムの段階的実行(逐次実行)が可能.
– 変数の書き換えなどを追跡・表示可能.● write 文をいちいち書いてコンパイルし直す必要がない.
– その他にもいくつか...
– 今回は実習では行わない(慣れが必要, 時間があれば実演).
– Fortran について代表的なデバッガ.● gdb (GNU Project Debugger) → コマンドプロンプト● idb (Intel Debugger for Linux) → コマンドプロンプト+マウス操作
GNU debugger (gdb)
● gdb における各種コマンド.– $ gdb : gdb を起動するコマンド.
– (gdb) : gdb を起動して入力待ち.● “file [ファイル名]”
– デバッグを行う実行ファイルを指定.● “break [数字]”
– ソースコードの[数字]行目まで到達したらそこで一時停止.● “watch [変数名]”
– ソースコードで定義されている変数名を指定すると, 変数の値が書き換わった場所(行数)と書き換わった値を出力.
● “run [ファイル名]”– [ファイル名] で指定された実行ファイルを実行する.
● “c”– break で停止したプログラムをその続きからスタートさせる.
● “p [変数名]” → write 文によるエラー検出を再コンパイルなしで行える.– 現時点でのソースコード内の [変数名] に入っている値を出力する.
GNU debugger (gdb)
● gdb のコマンドは他にも多数存在(参考文献参照).● gdb を使うには, コンパイルオプション “-g” が必要.● セグメンテーションフォルトしたときに出力される core ファイルの解析にも用いられる.– core ファイル : 異常終了時のメモリの内容をディスクに記録したファイ
ル.● (gdb) run [ファイル名] [core ファイル名]
– core ファイルは以下のように設定しておくと出力される.● $ ulimit -c unlimited
– Segmentation fault (core dump) と表記されていれば core ファイルが出力されている. ファイル名はデフォルトでは “core”.
– どのソースファイルの何行目・何という手続きの中でどのようなエラーが発生したかという情報を記録している.
論理エラーの検出
● デバッガによる検出– “break”, “watch” により逐次実行と変数の書き換えチェックをひたすら行う.
● 時間があれば実演.
● ソフトウェアテストによる検出– ユニットテスト
● サブルーチン・関数を最小単位として行われるテスト.– その関数が自明な返り値を返すと期待される値を入力して, 期待される返り値が返ってくるかを
チェックする.● ユニットテストは GUI ツールが存在する場合もある.
– 結合テスト● ユニットテストをパスしたサブルーチン・関数で結合されたソフトウェアを用いて行わ
れるテスト.
● いずれも地道な作業.
実習
● コンパイルオプションを用いたときと用いなかったときでのバグ検出の効率を比較する.
● 最初にダウンロードしたファイルを解凍すると, source 内に “fft_test.f90” というテストプログラムが入っている.
● このプログラムは STPK ライブラリの demo/unit 以下にある “fft_test.f90” にいくつかのバグを仕込んだものである.
● このプログラムのエラー箇所を特定せよ.● ただし, コンパイルオプションを用いて行う人と用いずに行う人に分かれて, どちらがエラーの特定・修復に要する時間が短いかを競う.
実習
● テストプログラムのコンパイルは以下のコマンドで行う.– $ ifort [option] -I[includedir] fft_test.f90 -L[libdir]
-lstpk -o fft_test● [option] : コンパイルオプションを用いてエラーチェックをする人はここに適切なオプションを指定.
● [includedir] : STPK インストール時の includedir.● [libdir] : libstpk.a が入っているディレクトリ.
まとめ
● write, print 文によるバグ検出は安直だが, write 文の挿入・再コンパイルなど手間がかかる.
● 効率的なデバッグを行うにはバグに種類があることを認識し, バグの種類ごとに異なったデバッグ方法を用いる.
● デバッグの方法(特にバグ検出の方法)はステージで異なる.– 構文エラー
● コンパイラがコンパイルすることで検出.
– 実行時エラー● コンパイルオプション・デバッガによって検出.
– 論理エラー● デバッガによる逐次実行・ソフトウェアテストの実行によって検出.
参考資料
● 『Fortran デバッグ用オプション』– http://www.rcs.arch.t.u-tokyo.ac.jp/kusuhara/fswiki/wiki.cgi?page=Fortran
%A5%C7%A5%D0%A5%C3%A5%B0%CD%D1%A5%AA%A5%D7%A5%B7%A5%E7%A5%F3
● 『@IT』– 情報マネジメント(ソフトウェアエラー)
● http://www.atmarkit.co.jp/aig/04biz/softerror.html
– Coding Edge(第1回ユニットテストはなぜ必要なの?)● http://www.atmarkit.co.jp/fcoding/articles/phptest/01/phptest01b.html
● 『IT 用語辞典』– http://e-words.jp/
● 『数理計画用語集』– http://www.msi.co.jp/nuopt/glossary/index.html
● 『ファイヤープロジェクト(GDB)』– http://www.fireproject.jp/feature/gdb/