gdbで効率的にデバッグするためのTips
Tips for Productive Debugging with GDBの抄訳。 Tips 1: GDB Dashboardを使おう GDB Dashboardは単一の.gdbinitファイルで、ブレークポイントで止まるたびに下図のようなクールな画面を表示してくれる。 https://github.com/cyrus-and/gdb-dashboard gdbには標準でTUIモード（cursesベースのUI）が搭載されているが、そちらは画面の乱れが頻繁に起こる。GDB Dashboardはcursesを使っていないので乱れが起きない。 スクショではOutput/messages, Source, Assembly, Threadsなど多数のモジュールを全部入りで表示しているためゴチャゴチャしているが、設定で自分に必要なモジュールだけを表示するようにできる。 訳者もしばらく使っているが、
GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ
RubyやPythonなどのスクリプト言語では実行中に例外が発生するとバックトレースを出力してくれます。バックトレースがあるとどこで問題が発生したかがわかるためデバッグに便利です。一方、CやC++では不正なメモリアクセスをすると、バックトレースではなくcoreを残して1終了します2。デバッガーでcoreを解析するとバックトレースを確認できます。 このように、CやC++でデバッグするときにデバッガーはなくてはならない存在です。スクリプト言語にもデバッガーはありますが、デバッガーを使わなくてもデバッグできる範囲が広いため、CやC++をデバッグするときのほうがデバッガーのありがたさがわかります。 この記事では、広く使われているデバッガーであるGDBをもっと便利に使うためのGCCのコンパイルオプション-g3を紹介します。 サンプルプログラム まず、この記事で使うサンプルプログラムを示します。マクロ
Segmentation Faultの傾向と対策 - minus9d's diary
C/C++のコードを書いてよく遭遇するのがSegmentation Fault、通称セグフォ。その傾向と対策をまとめてみた。 傾向 セグフォがよく起こるのは以下のとき。 メモリ違反 見てはいけないメモリ領域を参照したときに起こる。コード例は以下。 #include <stdio.h> int main(){ int array[10]; int i; for(i = 0; i < 20; ++i){ array[i] = i; } return 0; } 無限再帰 または 再帰が深すぎる 関数の無限再帰から抜け出せない時にもセグフォが起こる。コード例は以下。 #include <stdio.h> void loop(){ loop(); } int main(){ loop(); return 0; } また、理論上はどこかで再帰が終わるはずであっても、あまりに再帰が深すぎる場合も、やはり
gdbでのマルチスレッド処理のデバッグや制御について - 千里霧中
マルチスレッド処理のデバッグや解析において、gdbで各スレッドの実行・停止を制御する操作についてメモ。 なお今回は解説で以下のサンプルコードを使用する。ここでは３つのスレッドがそれぞれ「m_count 」「t1_count 」「t2_count 」の３つの変数をインクリメントしている。 //main.c #include <stdio.h> #include <unistd.h> #include <pthread.h> static unsigned int m_count = 0, t1_count = 0, t2_count = 0; void *thread1(void *args) { while (1) { t1_count++; } return NULL; } void *thread2(void *args) { while (1) { t2_count++; } ret
ソフトウェアが止まったり落ちたりした状態をgdbで解析する - 千里霧中
ソフトウェアがデッドロックや無限ループ等で応答しなくなったり、Segmentation Fault等で強制終了したりする場合での、gdbを使った解析手法について簡単なまとめ。 なお今回の内容はunixやlinux開発での基本知識となっていると思うけれど、例えば組み込みlinux開発などでは活用できるのを知らずに、printfデバッグで頑張っている所が結構あるようだ。開発が楽になるので基礎として知っておいて損はないと思う。 ソフトウェアが落ちる状態の解析 まず例外発生などでソフトウェアが異常終了する場合の解析について。 例えば以下のコードを実行すると、メモリアクセスエラーで異常終了する。 //main.c void hoge1(void) { int *hoge = (int *)0xDEADBEEF; hoge[0] = 100; } void hoge2(void) { hoge1();
gdbで標準ライブラリの中を探検する - 組み込みの人。
Linuxの標準ライブラリの中の動きをデバッガで調べたいときには、デバッグ情報つきのライブラリを追加インストールし、パッケージのソースアーカイブを持ってきてその場所をデバッガのソース検索パスに追加すると便利です。 Ubuntu 12.04 (x86_64)を使用しています。 以下のようなa.cをサンプルプログラムとして #include <stdlib.h> main() { abort(); } デバッグ情報付きで(-g オプション)コンパイルしてgdbの中で実行させます。 $ gcc -g a.c $ gdb a.out (gdb) r Starting program: /proj/koba/work/tmp/a.out Program received signal SIGABRT, Aborted. 0x00007ffff7a51425 in raise () from /lib
gcc+gdbによるプログラムのデバッグ 第2回 変数の監視、バックトレース、その他のコマンド
前回までに、デバッガを使用する上での最低限のことを覚えました。 ステップ実行 変数の表示、変更 ブレークポイント 今回は少しレベルを上げて、よりデバッガを使いこなすためのコマンドを紹介します。 ウォッチポイント ウォッチポイントはブレークポイントに近いものですが、ブレークポイントのように「ある地点に遭遇したら停止」ではなく、「監視している変数を操作したら停止」という流れになります。 ファイル内から該当する変数名を探せばいいと考えるかもしれませんが、C言語ではポインタによる変数の別名を付けることが可能であるため、そう単純にはいきません。 書き込みの監視 あまりよいサンプルが思いつかなかったため、簡単で無意味な例を示します。 counter.c #include <stdio.h> void set_counter(int *); int count = 1; int watchee = 0;
デバッグコンソールを活用しよう | SpiriteK Blog
XcodeのコンソールをNSLogの出力結果を確認するためだけの場所だと思っていませんか？ ええ、筆者は思っていました。 Javaでの開発環境にEclipseを使っていると、コンソールは実質的に出力専用でした。標準入力を受け取ることもできますが、自分でそういうコードを書かない限りは使いませんし。 Xcodeはデバッガとしてgdbが使われており、コンソールはそのままgdbのコマンドラインインタフェースになっています。 Xcodeでアプリ実行中に一時停止ボタンを押すと、コンソールにgdbのプロンプトが出ます。ブレークポイントやクラッシュによって停止したときも同様です。 ここで対話的にコマンドを実行することができます。 gdbには呆れるほどたくさんのコマンドが用意されていますが、基本的な操作はXcodeのGUIからも実行できるので無理に覚える必要はないと思います。 しかし、print-objec
gdb で void* 型の変数をデバッグする
C言語で実装されたライブラリやアプリケーションでは、汎用的な型として随所で void* が使用されますが、これをgdbからデバッグすると、そのままでは型情報が無いためタダのポインタとして扱われてしまいます。これではデバッグ時の都合がよろしくないです。 (gdb) print 0xfee65c0 $1 = 267281856 (gdb) print (void *)0xfee65c0 $2 = (void *) 0xfee65c0 こんなとき、この void* が指し示している先の型がわかりきっている場合は、その型でキャストしてやって: (gdb) print (struct imap_session_state_data *)0xfee65c0 $4 = (struct imap_session_state_data *) 0xfee65c0 (gdb) print $4 $5 = (st
Cocoaの日々: [Mac][iOS] GDB - infoコマンド
iOS/iPhone/iPad/MacOSX プログラミング, Objective-C, Cocoaなど デバッガコンソールにプロンプト "(gdb)" が出ている状態で info と打ち込むと利用可能なサブコマンドの一覧が表示される。 "info" must be followed by the name of an info command. List of info subcommands: info address -- Describe where symbol SYM is stored info all-registers -- List of all registers and their contents info args -- Argument variables of current stack frame info auxv -- Display the infe
![Cocoaの日々: [Mac][iOS] GDB - infoコマンド](https://cdn-ak-scissors.b.st-hatena.com/image/square/401d45199c10c432aec301329c6c6f18fdfeaf0d/height=288;version=1;width=512/http%3A%2F%2F2.bp.blogspot.com%2F_ZoUhefzk0CI%2FTR3ARjP_bfI%2FAAAAAAAAF_M%2FHb3PsPvRQ_8%2Fs1600%2F%2525E5%252590%25258D%2525E7%2525A7%2525B0%2525E6%25259C%2525AA%2525E8%2525A8%2525AD%2525E5%2525AE%25259A.png)
gdb の使い方・デバッグ方法まとめ
たとえば、変数 var の値を2進数で表示したい場合は、次のように指定します。 (gdb) p/t var 一覧表示 whatis 変数の型を調べる。 info b 今設定しているブレークポイントの一覧を表示 セグメントフォルトをした後に利用すれば、どの関数で発生したか確認できます。 info stack 関数の呼び出しスタックの一覧を表示 info Thread 存在しているスレッドの一覧を表示 異なるアドレスにおける処理継続 以下のコマンドを使用することで、ユーザが選択したアドレスにおいて実行を継続させることができます jump linespec linespecで指定される行において、実行を再開 jump *address addressで指定されるアドレスにある命令から、実行を再開 アドレスが分かっている場合のメモリリーク出力 xはhexの意味です。 (gdb) p (char*)
gcc のデバッグ術
Unix系コマンドラインユーザーのための、 gcc/g++/g77 による開発におけるデバッグ術を簡単に紹介します。 以下の内容は gcc 2.7.2.3 での動作は確認しています。 g++/g77 でも恐らくは通用すると思うのですが、 ひょっとすると異なる部分があるかもしれません。 筆者は g++/g77 の使用経験がないので、その場合は御容赦を願います。 実行前 キーワード「コンパイルオプション, -Wall, -O2, -O4」 まずは gcc にオプション opt'-Wall' を付けてコンパイルし、 警告がなくなるまでソースを修正します。 これは 常識 です。 次に opt'-O4 -Wall' でコンパイルします。 「未初期化変数の使用」の警告 (`foo' might be used uninitialized in this function) は、 opt'-O4' を付
gcc+gdbによるプログラムのデバッグ 第1回 ステップ実行、変数の操作、ブレークポイント
しかし、ブレークポイントという機能はデバッガの手助けなしでは実現できません。 ブレークポイントとはプログラムの強制一時停止を行うポイントで、実行中のプログラムがブレークポイントに遭遇するとプログラムは一時停止され、デバッガによるプログラムへの介入を行えるようになります。 ブレークポイントは次のような場所に設定できます。 指定した行番号のプログラムを実行しようとする瞬間 関数を呼び出した瞬間 その他、C++などでは「例外が発生した瞬間」などにもブレークポイントを設定することができます。 行番号ブレーク ブレークポイントとしてよく使用されるのは、「プログラムの特定の位置」です。 例として、bubblesort.cプログラムのsort関数内で、隣り合う二つの要素を比較している箇所にブレークポイントを設定してみます。 25|/* bubble sort */ 26|void sort(int *a
bichir's blog: GDB の使い方
【GDB の使い方】 gdb を使うのにこれだけ知っておけばいいかな(てゆーか私も gdb はこの位しか知らない)。と思われるものを列挙してみました。（間違ってる可能性もあります。） Q1: プログラムをデバグするには？ Q2: GDB を起動するには？ Q3: core file をデバッガで調査するには？ Q4: 起動中のプロセスをデバグするには？ Q5: プログラムを開始させるには？ Q6: ブレークポイントを設定するには？ Q7: 条件付きでブレークポイントを設定するには？ Q8: 変数の値が更新されたタイミングで停止させるには？ Q9: 設定したブレークポイントを表示したい。 Q10: 設定したブレークポイントを削除したい。 Q11: 設定したブレークポイントを無効化したい。 Q12: 設定したブレークポイントを有効化したい。 Q13: 今どこにいるの？ Q14: ソースを見たい
メモリ破壊の現場を見つけるTips - I am Cruby!
RubyAdventJP, GC, Ruby（この記事はRuby Advent Calendar jp: 2009 : ATNDの4日目です。前日はmrknさんでした） 健全なるRubyistであれば、RubyのGCをいじることが週に一度はあるでしょう。そのときに困るのが、GCをいじってしまったことによるバグの修正です。GCをいじるというのは想像以上に難しく、少しでも書き間違えるとメモリ破壊が発生します。そのときに使えるTipsをこの記事で書くことにします。 みなさんご存じの通り、メモリ破壊というのは原因を特定するのが困難です。これは問題が発覚する場所とメモリ破壊が起こった現場が位置的に遠いことに起因しています。偉大なるハッカーのまつもとさんですら、その発見は困難です。 [ruby-dev:38628] Re: [BUG: trunk] called on terminated objec
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
