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
今日は一日中EXC_BAD_ACCESSと戦っていました・・・・ どこかメモリ関係でだめなところがあるんだなということしかわからず、 かなり時間を食ってしました 開発をしている人なら誰もが通る道ではないでしょうか？ 検索とかすると、よく出てくるのは NSZombieEnabled をYESにしてどんな現象が起きているのか をしり、そこから推測してがんばるっていうものがよく引っかかります。 しかし！！ それでも具体的にどこが悪いよ！って言ってくれる訳ではないので、 なかなかバグを見つけるのは難しいとろ個がありますよね そんなかゆいところに手が届いてくれるやつがいました！ NSZombieEnabled に加えてこれを使うことで、もう今までの苦労は何だったんだろう？って言うぐらい簡単に見つけられちゃいます！ つかいかたはちょっとめんどくさいけど、それだけの価値はあります！ 使い方ですが、あらか
自分用にgdbコマンドをメモ。別のサイトに載せていたのですが、サイトが消えたのでこちらに載せ直しました(^^; list ソースコードを表示。 sample.cの10行目あたりを表示する場合、以下のコマンドを実行します。 (gdb) list sample.c:10 5 #define LED3 0x40 6 7 void wait() 8 { 9 static int status; 10 static unsigned int t; 11 12 do{ 13 status = *DGA_CSR20 & TT0_BIT; 14 t = (*DGA_CSR13 & 0x00ffffff); print (p) 変数の値を表示。 statusという変数の値を表示する場合、以下のコマンドを実行します。 (gdb) p status $1 = 104857 (gdb) p/x status $2
Sometimes programs crash. This annoys users and developers alike. Users are frustrated because they cannot use crashing software, developers are frustrated because they have to hunt bugs instead of doing something creative and rewarding. How do we communicate if an iPhone application crashes? I’ll start with a disclaimer. I’m not sure whether the information provided in this post is covered by iPh
iPhoneの素晴しいところの一つは、Crash Logが本体に保存される事なんですが、 Thread 0 Crashed: 0 libobjc.A.dylib 0x300c8c18 objc_msgSend + 20 1 Fastweet2k 0x00016240 0x1000 + 86592 2 UIKit 0x30b2b414 -[UITextView keyboardInputChanged:] + 80 3 UIKit 0x30bcaf1c -[UIWebDocumentView keyboardInputChanged:] + 40 このように、デバッグバイナリでもシンボルが出ないときがあります。 symolicatecrashを使ってもだめでがっかり。 でも、dSYMがあるから頑張ればなんとかなるんじゃね？とやってみたらなんとかなった。 普段VisualStudioの微温湯に
Debugging with GDB The GNU Source-Level Debugger Ninth Edition, for GDB version 6.3.50.20050815-cvs Richard Stallman, Roland Pesch, Stan Shebs, et al. Summary of GDB Free software Free Software Needs Free Documentation Contributors to GDB A Sample GDB Session Getting In and Out of GDB Invoking GDB Choosing files Choosing modes What GDB does during startup Quitting GDB Shell commands Logging output
このテクニカルノートは、Mac OS X において、GDB（Mac OS X のデバッガ）を使った、C、C++、Objective-C による一般的なデバッグ作業の方法（Java には専用のデバッガがあります）、および開発者にとって役に立つヒントとこつを説明します。 本文書は、GDB のすべてを説明する文書ではなく（詳細なマニュアルについては参考文献の節を参照）、GDB を初めて使う開発者が抱くと考えられる一般的な疑問に答えることを目的としており、今後必要なときに簡単に参照できるようになっています。また、プラットフォームに依存しないように書かれている GDB に関するほかの文献とは異なり、本書ははっきりと Mac OS X に的を絞っています。 本文書は、「Project Builder における GDB」、「GDB を使ったアプリケーションの接続、起動、終了」、 「ブレークポイント、バッ
Debugging with GDB The GNU Source-Level Debugger Ninth Edition, for GDB version 6.3.50.20050815-cvs Richard Stallman, Roland Pesch, Stan Shebs, et al. Summary of GDB Free software Free Software Needs Free Documentation Contributors to GDB A Sample GDB Session Getting In and Out of GDB Invoking GDB Choosing files Choosing modes What GDB does during startup Quitting GDB Shell commands Logging output
デバッグやテストを行っていると、プログラムが無限ループに入り込んで返ってこないような状況が発生することがあります。 そのバグが再現の難しいものであれば「gdbを使って起動しとけば良かった。。。」というような気分になる時があります。 しかし、gdbには既に起動しているプログラムの制御を横から奪い取ってデバッグするというありがたい機能があります。 ここでは、既に起動しているプログラムをgdbでいじる方法を説明したいと思います。 実際にデバッグをする方法を説明するというよりは、gdbで動いているプロセスにアタッチする例を説明します。 その後のデバッグに関しては、いつものgdbの使い方をしていただければ大丈夫です。 とりあえずアタッチしてみる 既に起動しているプロセスをgdbを解析するのは非常に簡単です。 単にgdbでプロセスにアタッチするだけです。 gdbでプロセスにアタッチする方法は2つありま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く