Cygwinのstackdumpファイル

win*Cygwin*gccの環境でC言語プログラムをgdbでデバグする。(ビルド時-gオプション必須)

本来セグメンテーションエラーが出ると、gccはcoreファイルというものを吐き、
こいつをgdbに食わせることで、バグの起きた箇所を探れるというわけなんですが、
Cygwin環境では、このcoreファイルが吐かれず、
代わりに、エラー時のCPUレジスタ値、関数スタック値などが数行かかれた、
stackdumpファイルというものが生成されます。

こいつは、coreファイルに比べ圧倒的にデバグ情報が少なく、gdbに食わせることもできません。
が、頑張ればスタックを逆アセンブルして、バグ箇所を特定できたりするというお話。

まず、gdbでプログラムを起動(run)し、main関数でbraekする。

gdb [execute file]
(gdb) break main
(gdb) run

そこで、stackdumpファイルのスタックトレース情報を参照すると、
エラー発生時の関数スタック(最上部がスタックトップ）の16進の関数アドレスが記されているので、
そのアドレスを元に、逆アセンブル。

(gdb) disas 0x(hogehoge)

すると、指定した関数まわりのアセンブリコードが表示されるので、
後はそれと、該当するCのソースコードを読みながらデバッグ。
これで、エラー箇所が特定できちゃいます。*1

Cygwinにcoreファイルを吐くよう設定

どうやら、環境変数CYGWINにerror_start=dumperという変数を設定すると、
coreファイルを吐いてくれるそうです。

当然こうしておくのがcoolですねw

背景

最初、coreを吐かせる設定を知らずに、
丸2日間にもわたるテストプログラムを実行してしまい、
不幸にもsegmentation faultが出てしまった。。
再設定しても、coreファイル手に入れるまで時間がかかりすぎるので、
stackdumpファイルから気合でデバグするしかないという。。。w

source：
http://kkindoh.exblog.jp/7924830/
http://www.sixnine.net/cygwin/cygwin-doc/smalltips.html

*1:あくまでもエラー発生箇所であり、原因は他にあることもある。