Debugging C/C++ and CPython using GDB 7’s new Python extension support
I’ve recently been looking into ways to improve my debugging experience with mixed Python and C/C++ programs. I spend a fair amount of time working on systems built using both languages in tandem, and the tools available for debugging across the languages have historically been very limited. Often, logging and/or intimate knowledge of the Python C-API (and, in my case, boost.python) were the prima
gdbでアセンブルしてSEGVしている箇所を特定するTips - I am Cruby!
gdbこれは-gでコンパイルされていない所でSEGVが発生するときにどの行で落ちているのか見当を付ける方法。 こんなコードを用意してみた。特徴三つのSEGVの可能性がある関数呼び出しありもちろん-gでコンパイルしていない前の記事の使いまわし #Include #include struct hoge { int id; char *comment; }; void throw_segv(char *comment) { int test[1000]; if(!strcmp(comment, "Hellow!")) test[-100000] = 9; } int main(void) { struct hoge *hg; hg = malloc(sizeof(struct hoge)); hg->id = 2565; hg->comment = "Hellow!"; throw_se
メモリ破壊の現場を見つける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
MySQL のGDBによるデバッグ環境構築メモ - yoshifumi1975's diary
MySQL5.1からは、自作のストレージエンジンや自作の関数用のAPIが公開されている。 自作のストレージエンジンは気軽には作れないと思うが、自作の関数については検討の価値ありだと思う。 その際に役立つかもしれないデバッグ環境の構築メモ。 その前に、ここ の手順で、ソースを取得してデバッグオプション付きでMySQLをビルドしておく。 gdbでデバッグするには、下記のライブラリが「not stripped」でなければならない。そうじゃない場合は、glibcの再コンパイルが必要。CentOS5は「not stripped」なので問題ない。 # file -L /lib/libthread_db.so.1 /lib/libthread_db.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Lin
使いながら覚えるGDB
はじめに プログラムのデバッグと言えばひたすらprintfを挿入しまくっていたある日、 デバッガなる便利な代物があるということを知った。なんでもプログラムを一行 ずつ実行できて、変数の値をその場で確認できるらしい。これは是非使ってみねばと 思い、UNIX環境で使えるGDBというデバッガを試してみた。が、何がなんだかさっぱり 分からない。Webを検索するとマニュアルの日本語訳が見つかった。これで勉強すれば 使えるようになるかも、と読み始めるも、いきなりm4がどうのこうのだの、意味不明 の文章が続く…。 これは私がGDBを使い始めた時の話だが、似たような経験を持っている人が他にもいる と思う。 GDBのマニュアルは初心者にはすこし敷居が高い。 GDBに限らずマニュアルというものは初学者が参考書として用いるのには 適していない。というのも、マニュアルの類は情報量が多い分、重要な部分を 見つけ出す
GDBで歴史をさかのぼれるように!なりました! GDB 7.0 の新機能Reverse Debuggingを使ってみた - 日記を書く [・w・] はやみずさん
Twitter上で、@alohakun が言及していた GDB の reverse debugging の機能を使ってみました。 GDB にトレースと逆実行機能入ったのか。 http://www.gnu.org/software/gdb/news/reversible.html http://twitter.com/alohakun/status/4481139191 まずは簡単な使い方を説明したあとに、インストール方法を説明します。 こんなときに便利 「変なこと」が起きている大体の場所がわかっているとき デバッグ中に、大体どこで変なことが起きているかはわかっているけど、細かい場所は特定できていないとき、reverse debuggingが効果を発揮します。 GDBでステップ実行をしていて、「しまった!行きすぎた!」という経験はよくあると思います。こういうとき、今まではプログラムの実行を最
![GDBで歴史をさかのぼれるように!なりました! GDB 7.0 の新機能Reverse Debuggingを使ってみた - 日記を書く [・w・] はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/5525a2830381c6797ff7950668c3d6fe91891b31/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128190416%2F1557447110)
~jk GDB: auto-stacktrace
While developing mysql-proxy I sometimes have to step-by-step refactoring that usually result in unstable code for a while until the unit-tests are happy again. When a unit-test fails I usually use gdb as a wrapper and let it create a stack-trace for me: $ gdb --command=backtrace.gdb --args /path/to/my/testcase The --command option is used to automate gdb: run thread apply all bt quit If the test
アセンブラで遊ぶ時に便利なgdb設定 - memologue
アセンブラで遊ぶ時に便利な ~/.gdbinit を紹介します。まず ~/.gdbinit を次のように記述してください。 # # ~/.gdbinit # # .so を shlib コマンドで手動で読み込む # set auto-solib-add 0 # スレッド生成時のSIG32でブレークしない handle SIG32 nostop # ニモニック構文の選択 # set disassembly-flavor intel set disassembly-flavor att # フラグレジスタの可読化関数 define pf printf "eflags: %s%s%s%s%s%s%s%s%s (= 0x%08u)\n",\ $eflags & 2048 ? "O":"-",\ $eflags & 1024 ? "D":"-",\ $eflags & 512 ? "I":"-",\
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to debug a multithreaded application in C++ which is hung (deadlock)?
https://heather.cs.ucdavis.edu/~matloff/cgdb.html