プログラムの誤りのことをバグ（bug)という（由来）．また，プログラムの誤りを正すことをデバッグ(debug)という．バグがあると，
ため，バグを修正しなければならない
バグが見つかった場合、以下のことを思い出すようせよ(東京大学渡辺先生のページ; http://apollon.issp.u-tokyo.ac.jp/~watanabe/tips/debug.html)．
プログラムにわけのわからないバグが発生した場合、（中略）最後までプログラムを見終わって「うーん、合っているはずだよなぁ」と つぶやくのがせいぜいである。 合っていたらバグなんて発生しない。そもそもバグが起きたら 「なんでだよ～」と思う時点で罠にはまっていると言ってよい。 バグは全て自分のせいだということを思い返そう。
エラーには，コンパイルエラー(Compile Error)，ランタイムエラー(Runtime Error)，論理エラーの3種類がある。
コンパイル(翻訳)時に起こるエラーである．３種類のエラーの中で一番修正の容易なエラーであり、原因のほとんどは文法ミスである．エラーの箇所とその内容が画面に表示される（エラーメッセージという）ので，その内容をみてソースファイルを修正する．
よくあるコンパイルエラーの原因には次のようなものがある．
文法エラーの場合，エラーメッセージが示すバグの箇所より前に実際のバグが存在する場合があるので，注意せよ。
実行時に生じるエラーである．ランタイムエラーが起こったら、次のコンパイルオプションをつけてプログラムを再コンパイルして、プログラムを再実行せよ。ランタイムエラーが起こった場所が特定できる場合が多い。
Intel Fortranの場合：
-traceback -CB -fpe0
gfortranの場合:
-fbounds_check -fbacktrace -ffpe-trap=invalid,zero,overflow
これらのオプションの意味については、コンパイラのオプション (Compiler Options)を参照せよ。
これらのエラーが発生したときには、Segmentation faultというエラーメッセージがよく表示される。簡単に言うと、Segmentation faultとは、データがメモリにうまく納まらない場合に表示される。Segmentation faultの詳細に関しては、ここを参照のこと。
よくあるランタイムエラーの原因を以下に列挙する。
配列のサイズオーバー
例えば，
dimension A(10)
として配列Aのサイズを10としているのに，
A(11)を参照したような場合．
良くやるミス
dimension A(10) n=11 do i=1,n A(i)=0.0 enddoこのプログラムは，i=11のときエラーになる．
allocatable宣言をした配列の大きさを指定し忘れた
real,allocatable :: A(:)
と宣言しておいて、
allocate文を忘れると、Intel Fortran (ifort)の場合、segmentation faultというエラーメッセージが表示される。
この場合、
allocate(A(10))
などとして、配列Aの大きさを指定してやる必要がある。
存在しないファイルからデータを読もうとした
ファイル名が間違っていないかチェックすること
入力用ファイルのデータが足りない
データをどこまで読むことができているのかチェックすること
サブルーチンの引数の数があっていない
ifortの場合，実行時にSegmentation Faultというエラーが表示されることが多い．サブルーチン内部におかしいところが見当たらないときは，この種のバグがないかチェックせよ．
主プログラム
program main
real A
A=1.0
call sub(A)
.....
end program main
サブルーチン
subroutine sub(A, B)
real :: A, B
A=A+B
end subroutine sub
この例では、主プログラムとサブルーチンで引数の数が合っていないのでエラーになる。
サブルーチンの引数の型があっていない
主プログラム
program main
real A, B
A=1.0
call sub(A, B)
.....
end program main
サブルーチン
subroutine sub(A, B)
real(8) :: A, B
A=A+B
end subroutine sub
この例では、A, Bの型が合っていないのでエラーになる。これもSegmentation Faultというエラーが表示されることが多い。
バイトスワップオプションの指定ミス
バイナリデータの入出力をするときによくやるエラーです。
Intel fortran (ifort)では、コンパイル時に
-convert big_endian
というオプションを指定すると、バイナリ入出力時のデータの型がビッグ・エンディアンになります。データを作成したプログラムで、 -convert big_endianを指定しているのに、作成したデータを読むプログラムでは、 -convert big_endianを指定していないと、下記のようなエラーが出る。
forrtl: severe (39): error during read, unit ファイル番号, file 入力ファイル名
思ったとおりにプログラムが動作せず，おかしな値を返す場合である．これはプログラムに記載されている手順の誤り、ということなので、修正は人間がやる以外にない。修正するための処方箋としては，次のようなものがある．
重要なことは，上手く動くはずだ，という思い込みを捨てて，正常に動作するかどうか一つ一つ確認することである．
東京大学渡辺先生のページ (http://apollon.issp.u-tokyo.ac.jp/~watanabe/tips/debug.html)）の「特別編」は必見である。
要点をまとめると以下のようになる。
論理エラーのチェックのためにプログラムを変更する場合には，どんな些細な変更であっても必ずバックアップをとること．デバッグのための変更によって，新たなバグが入ることを防ぐことができる．ソースファイルの容量などたかがしれているので，ケチケチせず，バックアップを取るようにする．
参考：ここの、bksrc.shというシェルスクリプトを使うと、簡単にソースファイルのバックアップがとれる。
デバッグ用のツール（ソフトウェア）がいくつかある．有名なものとしては，GDB, DDD, Eclipseがある．ウェブサイトを検索してみるか，Matloff and Salzman (2009)を参照せよ。
また，参考になる文献として，
東京大学渡辺先生による資料(http://apollon.cc.u-tokyo.ac.jp/~watanabe/tips/debug.html)と小俣 (2007)を挙げる特に，渡辺先生の「特別編」は論理エラーのデバッグに非常に役に立つ。
渡辺宙志. デバッグの方法論, http://apollon.issp.u-tokyo.ac.jp/~watanabe/tips/debug.html
小俣光之 (2007): プログラミングでメシが食えるか. 秀和システム, 303pp.
Matloff, N. and P. Salzman. 相川愛三訳 (2009): 実践デバッグ技法. オライリージャパン, 270pp.