GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ
RubyやPythonなどのスクリプト言語では実行中に例外が発生するとバックトレースを出力してくれます。バックトレースがあるとどこで問題が発生したかがわかるためデバッグに便利です。一方、CやC++では不正なメモリアクセスをすると、バックトレースではなくcoreを残して1終了します2。デバッガーでcoreを解析するとバックトレースを確認できます。 このように、CやC++でデバッグするときにデバッガーはなくてはならない存在です。スクリプト言語にもデバッガーはありますが、デバッガーを使わなくてもデバッグできる範囲が広いため、CやC++をデバッグするときのほうがデバッガーのありがたさがわかります。 この記事では、広く使われているデバッガーであるGDBをもっと便利に使うためのGCCのコンパイルオプション-g3を紹介します。 サンプルプログラム まず、この記事で使うサンプルプログラムを示します。マクロ
Cのプログラムの中でブレークポイントを設定する - bkブログ
Cのプログラムの中でブレークポイントを設定する Cのプログラムをデバッグする際には GDB などのデバッガが役立ちます。通常、ブレークポイントはデバッガの中から設定しますが、デバッグ対象のCのプログラムの中で設定することもできます。 Linux なら #include <signal.h> して、任意の箇所に raise(SIGTRAP); を挿入すれば OK です。 raise() 関数を用いて SIGTRAP シグナルを発生させています。 あるいは x86 限定なら __asm__("int3"); でも OK です。ここでは SIGTRAP を発生させるために int3 (0xcc) 命令を埋め込んでいます。GDB もソフトウェア的にブレークポイントを設定するときは当該箇所に int3 を書き込んでいるので、やっていることは割と似ています (GDBの場合は int3 を書き込む部分の
iOSのプログラミング中に gdb で recursiveDescription を使うのは良いアイディア!! - 強火で進め
こちらの記事で書かれていた内容。 Debugging with GDB: Print-Object and UIView recursiveDescription http://iphonedevelopertips.com/debugging/debugging-with-gdb-print-object-and-uiview-recursivedescription.html ブレークポイントで止めて、コンソール(gdb)で po [[self view] recursiveDescription]とすれば [self view] のビュー構造が確認出来ます。 自分は今までプログラムの中に書いていたのですがこちらの方が簡単で良いですね。うっかり、プログラムの中に残したままにする様な事も発生しませんし… 同じ様な内容を日本語で書かれてるブログも見つけました。こちらの方が書かれた時期は早い
Technical Note TN2124: Mac OS X Debugging Magic
このテクニカルノートでは、Mac OS X のさまざまな「隠れた」デバッグ機能、つまり環境変数、環境設定、GDB から呼び出し可能なルーチン、特別なファイルなどについて説明します。 Mac OS X 向けの開発をしている場合は、開発作業を楽にしてくれるものを見逃していないか確認するために、このリストに目を通してください。 はじめにMac OS X には、個々のサブシステムの開発とデバッグを支援するために、エンジニアリングチームが追加したデバッグ機能がいくつか含まれています。 これら機能の多くは、リリース後のシステムにも残っており、コードのデバッグに利用できます。 このテクニカルノートでは、広く役立つデバッグ機能をいくつか説明します。別の場所で文書化されているデバッグ機能については、機能の簡単な概要と既存ドキュメントへのリンクを記載しています。このテクニカルノートでは、デバッグ機能を網羅的に
GDBの便利技: (gdb)> でコードビューアを立ち上げて快適デバッグ - 佐野デジタル研究所
はじめに はてなダイアリーのスーパーpre記法(ブログ本文にソースコード等を貼り付けるための記法)で始まるテキストがクリップボードに入った状態で、間違って、gdbのシェルに貼り付けてしまった。そしたら、見たことの無い画面が出現。これは便利すぎる。 Linuxカーネルのコードを読むのに欠かせない技になりつつあるので、メモとして残しておこう。 使い方 めちゃくちゃ簡単。「>」を入力するだけ。 (gdb) >バックトレースが取れる状態で、フレームを選択して、「>」を入力すると、そのフレーム周辺のコードを見るためのビューアーがgdb内に立ち上がる。ビューアを良く見ると、左上に、閲覧中のファイルのパス、左端に行番号が表示されている。 ↑↓キーでコードを移動できる。ちょっと前後のコードも確認したい時に重宝する。(gdb)のコマンド履歴を遡りたい場合はCtrl+P。その逆は、Ctrl+N。Emacsと同
Book: Debug Hacks
TOPICS Hacks , Programming , Linux , Ruby 発行年月日 2009年04月25日 PRINT LENGTH 424 ISBN 978-4-87311-404-0 FORMAT PDF ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 Debug Hacks推薦の言葉 プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれ
死んだプロセスのスタックトレースを自動収集するデーモンを書いた (そして、その出力を開発者に送ってあげると喜ばれるよという話) - kazuhoのメモ置き場
死んだプロセス (あるいは kill したプロセス) の core イメージから自動的にスタックトレースを収集するデーモンを書いたので、これをセットアップしてサーバにインストールしとくといいかもです (kaztools/bt_cores at master · kazuho/kaztools · GitHub)。Linux のみ対応*1。使い方は bt_cores --help とするか、perl Makefile.PL && make install して man bt_cores。 具体的にいうと、Q4M とか Incline とか kazuho product が落ちたり固まったりしたらスタックトレース送ってくれると、私がうれしいです (古いバージョンのスタックトレースだととても悲しいです)。コアファイルは内部データがいろいろ入ってるから外部の人には見せられないけど、スタックトレース
gdb tips - bkブログ
gdb tips gdb を使う上で便利な tips を紹介します。基本的な使い方をマスターしている人向けです。 .gdbinit の設定 ホームディレクトリに .gdbinit を置いておくと、gdb の起動の際に読み込まれます。私の場合は次のような設定をしています。 set history save on set history size 10000 set history filename ~/.gdb_history set print pretty on set print static-members off set charset ASCII set history から始まる最初の 3行は履歴に関する設定です。それぞれ、 gdb のコマンドラインの履歴をファイルに保存する、保存する行は最大 10000 行、ファイル名は ~/.gdb_history 、という意味になります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Howto: GDB Remote Serial Protocol
ほげめも: gdb hacksアーカイブ