gdbのリモートデバッグのextended-remoteモードを試す(2) - Qiita
前回の続き。 従来のremoteモードではできなくて、extended-remoteモードで可能になったこと それは、gdb側からの操作で新たなデバッグ対象プロセスを起動することです。つまり run コマンドの実行。 また、デバッグ対象プロセスをまだ起動していない状態で、gdbとgdbserverの間でファイルを転送することができます。 この2つを合わせると、「修正された実行ファイルをターゲットに送信して、それを起動してデバッグを開始する」というのがgdb内で完結できます。 リモートデバッグのサイクル 以下の1-5を繰り返す。 ソースコードを修正する コンパイル、リンクして実行ファイルを作成する 実行ファイルをターゲットに転送する 実行ファイルを起動する ブレークポイントをかけたり、変数を見たりしてデバッグ 従来のremoteモードでは3はscpで転送したりNFSにしたり別の方法での実現が
GDB で php プロセスの覗き見 - hibomaの日記
php を GDB でデバッグするのが便利。 以下のエントリで手法が説明されている qiita.com blog.anatoo.jp stackoverflow.com 以降、私が書くのはこれらのエントリに書かれている手順を真似たものなので、詳細を知るにあたっては是非リンク先も読んでほしい 検証: GDB で実行中の php プロセスを覗き見る GDB は実行中のプロセスを解析の対象とすることもできる。このエントリでは、無限ループするバグった php を GDB で覗いてみよう <?php function third($bar = "") { for (;;) { } } function second() { third(); } function first() { second(); } first(); 検証環境 CentOS7.4 (1708) php-5.4.16-42.el
実行中のマルチスレッドプログラムの特定スレッドのみ停止(SIGSTOP的な)させる方法 - ablog
@yoheia gdb -p LWP で特定のスレッドだけ止められますよ。— Tsukasa Hamano (@hamano) 2016年3月29日 @hamano "gdb -p LWP" でサクッとできました！ありがとうございます。 $ ps -u grid -lLf|grep css $ gdb -p 3449 -> LWP:3449 のステータスが t になりました— yohei-a (@yoheia) 2016年3月29日 @yoheia gdb -iex="set non-stop on" -iex="set target-async on" -p プロセス して cont -a してから特定プロセスを interrupt してもいいですね。こちらのほうが自由にスレッド間を行き来できていいかも。— Tsukasa Hamano (@hamano) 2016年3月29日
gdbを使ったrubyのデバッグ - クックパッド開発者ブログ
技術部の国分 (@k0kubun) です。 先日byebugの高速化を行っていた最中、変更を加えたbyebugを使っていると一定の確率でrubyがSEGVするバグを発見しました。 私はC言語のコードのデバッグの経験はなかったのですが、デバッガの使い方を調べながらSEGVの原因調査を行いパッチを送ったところ無事取り込まれ、最新の高速なbyebugが安全に使えるようになりました。 その際、ruby自体をデバッグするために必要な情報が分散していて大変だったので、まだrubyのデバッグをしたことがないけれどやってみたいという人を対象に、gdbというデバッガを使ったrubyのデバッグの方法を紹介します。 デバッグ用にrubyをビルドする デバッグ時に変数名やソースコードなどの情報を見るためには、最適化オプションをオフにしてデバッグ用にrubyをビルドしておく必要があります。 rubyのデバッグ用ビル
gdb で MySQL 5.0.96 のスロークエリログを追ってみる - takatoshiono's blog
1つ前のエントリ Query_time - Lock_time > long_query_time - takatoshiono's blog で以下のように書いた。 ソースコード MySQL 5.0.96 で Lock_time が 0 になるのが気になったのでソースをダウンロードしてきて追ってみた。Lock_time で grep すると以下のコードに辿り着くので変数名を頼りに少しさまよってみたのだが、力不足で追いきれなかった。無念。 Webエンジニアのための データベース技術[実践]入門 (Software Design plus) を読んで動的解析の方法を学習したので試してみる。 MySQL 5.0.96 をデバッグモードでインストール kamipo/mysql-build · GitHub を使って 5.0.96 を —with-debug でインストールした。 最初 sed で
ptraceを駆使してscreenifyっぽいことをするreptyrがすごい
reptyrというおもしろいものをみつけたのでご紹介 reptyr とは reptyrとは"re-ptying"するためのプログラムで、起動中のプロセスを新しい別のターミナルにもってくることができます。 例えば、うっかりscreenやtmuxの外で起動してしまった長い時間のかかるバッチ処理を、起動したままscreenの中にもってくることができます。 https://github.com/nelhage/reptyr 使い方 現在のターミナル内にもってきたいプロセスのpidを引数にします。 attach後は、そのプロセスの入出力は^Cや^Zも含めて新しいターミナル側を向きます。 それscreenifyでできるよ screenifyと呼ばれるスクリプトが昔からあって、それはgdbつかって似たようなことをやってるらしいです。 でもreptyrならもっとうまくできます。 例えば従来のscreeni
就職面接でプログラムの解読を求められた！ | POSTD
長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました（「解読してみろ」ということでしょう）。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。
QEMU上のLinuxカーネルをGDBでデバッグする
プログラムがセグメンテーションフォルトで不正終了した場合に、GDBで原因 調査するというのはよく聞く話である。しかし、こういったソフトウェア開発 の後行程で使用するだけではなく、前行程でも使うべきである。これは挙動が よく分からないプログラムの動作確認にGDBが有効であるからだ。 今回は特にprint文が動作しない段階のLinuxカーネルの動作をGDBで確認する。 ただし、あくまでQEMU上での動作である為、QEMUでサポートしていないハード やQEMUが再現しきれていないハードの動作部分については未対応である。そう いった場合はICEなどの治具を用いる必要がある。 1. カーネルコンフィグの設定 CONFIG_DEBUG_KERNELを有効にする。 Symbol: DEBUG_KERNEL [=y] Type : boolean Prompt: Kernel debugging Loca
gdbの使い方のメモ - ももいろテクノロジー
よく使いそうなものの覚書。 実行ファイルを指定して起動する $ gdb a.out 次のようにオプションを指定すると、 ライセンス表示を出さない アセンブリコードをIntel形式で表示する 停止するたびに直後の命令を表示する ようにできる。 $ gdb -q -ex 'set disassembly-flavor intel' -ex 'disp/i $pc' a.out 起動中のプロセスにアタッチする $ gdb -p [PID] ヘルプ、コマンド検索 (gdb) help break (gdb) apropos breakpoint 実行する main関数で止める場合。引数にはシェルの構文がそのまま使える。 (gdb) start AAAA main関数で止めない場合。 (gdb) run AAAA (gdb) r AAAA 引数を別途セットすることもできる。 (gdb) set ar
はじめてのgdbデバッグ | blog: takahiro okumura
仕事でagを利用していた時に出会ったバグを、先輩たちの力を借りてなんとかした話です。 先に結論を書くと、業務に用いていたagのバージョンが古いのが原因のようでした。version 0.15より古いとlockの実装に問題があるようです。 以下、問題の発覚からなんとかするまでの記録です。 発端 agが途中で止まる 時折、agのファイル操作が先へ進まなくなってしまう不具合がありました。 操作中に対象ファイルのロック状況が変わるとデッドロックが発生しているのでは？と想像。 気になってstraceでプロセスにアタッチすると、以下で停止していることが分かりました。 [pid 4589] futex(0x80517e4, FUTEX_WAIT, 32159, NULL FUTEX_WAIT futex(2)を引くと、futex(2)の書式に対する操作FUTEX_WAITの説明があります。
続・Debugger の Tips - Qiita
potatotips #1 で LT した内容が好評(？)だったのでもう少し紹介してみようかなと思います。 発表した内容は「Debugger の Tips」です。 当日のまとめは「クックパッドのLT会に参加してきたのでiOSのtipsをまとめる」がおすすめです。 さてさて LLDB がデフォルトの Debugger となり久しいですね。 しかし Xcode から LLDB を扱う情報をあまりみかけません。かなしいですね。 というわけで今回は LLDB にフォーカスをあてて少し紹介してみようと思います。 (決して GDB もあわせて書くのが面倒くさかったというわけではありませんｗ) 設定ファイル shell での .~rc ファイルみたいなものですね。 Xcode から起動した LLDB だと以下の２つのファイルのどちらかが読み込まれます。 ~/.lldbinit-Xcode ~/.lldb
Go言語のOS X上でのGDBデバッグ環境構築 - unknownplace.org
Go言語は gdbでのデバッグがサポートされている のだが、OS X でそれを使おうとしたらいろいろ罠にはまったのでここに記しておく。 (このエントリ執筆時の手元の環境は OS X 10.9(.0) Mavericks + Xcode 5.0.1) 罠一覧 OS X 付属のgdbが古い Xcode 5.0.1のclangだとgdbのビルドがこける ビルドするgdbはpython2にリンクさせないとGo付属のruntime-gdb.pyが動かない[1] ビルドしたgdbにコード署名をしないと他プロセスをアタッチできない OS X 付属のgdbが古い Goのコードをgdbでデバッグするには、gdb 7.1以上が必要ということだが、OS X (Xcode?) 付属のgdbは古くて使えない。 手元のバージョンは GNU gdb 6.3.50-20050815 (Apple version gdb-
CoreからRubyのバックトレースを表示するgdbruby.rbを作った
gdbperl.plというスクリプトがあります。そんｋする樋口証さん作の、gdbを操作してPerlのプロセスのバックトレースを取るツールです。生きているプロセスだけではなく、coreを取っておけばそのcoreからバックトレースが取れるのが特徴です。 gcoreというコマンドが/usr/binあたりにあって、これを使えば走っているプロセスのcoreを取得することができます。よって、本番環境で気軽にcoreを取ってgdbperl.plにかけることによって、刺さっているポイントを見つけたりすることができます。超便利。 くわしくは、Perlスクリプトをgdbでデバッグを参照ください。 んで、その便利なgdbperl.plをRubyに移植してみました。その名もgdbruby.rb。単純。 gdbruby.rb 使い方とか Rubyはデバッグシンボル付きのものをご用意ください。 生きているプロセスにア
gdb のRPM に付属する /usr/bin/gstack, /usr/bin/gcore コマンド - hibomaの日記
Scientific Linux 6 系の gdb の RPM に /usr/bin/gstack, /usr/bin/gcore というスクリプトが含まれているのを知りました。どちらも gdb をラップしたシェルスクリプトです。 (追記: CentOS5 の gdb にも入ってました ) /usr/bin/gstack 指定したプロセス(マルチスレッドの場合は全スレッド)のスタックトレースを表示します monit の例 # /usr/bin/gstack `cat /var/run/monit.pid` Thread 2 (Thread 0x7fd3ea10a700 (LWP 27548)): #0 0x0000003cb48dea63 in poll () from /lib64/libc.so.6 #1 0x000000000041c9c7 in can_read_ms () #2
CRubyでオブジェクトが生成された位置を突き止める - GC Advent Calendar - I am Cruby!
Garbage Collection Advent Calendarの1日目の記事です。 おそらく一人でけっこう長い日数を書くと思うので、軽いものからボチボチと…。 しかもGCとはあまり関係ないですが…。 とあるオブジェクトの生成位置を調べたいとき、どうするのか。 object_idを1bit左シフトするとだいたいそのオブジェクトのRVALUEのアドレスになるので p (hoge.object_id 1).to_s(16) # => fa83a4 上記のようにobject_idを出力するコードを混ぜておきましょう。 その後にgdbでrubyを動かしてみます。 この時、GC_DEBUG付きでビルドしたrubyなら実はソースコードとラインがわかります。 デバッグ用にGC_DEBUG付きのrubyがビルドできるようならそうしてみましょう。 rvmだったら.rvmrcに以下の設定するとできるんじゃ
Learning C with gdb - Blog - Recurse Center
Coming from a background in higher-level languages like Ruby, Scheme, or Haskell, learning C can be challenging. In addition to having to wrestle with C’s lower-level features like manual memory management and pointers, you have to make do without a REPL. Once you get used to exploratory programming in a REPL, having to deal with the write-compile-run loop is a bit of a bummer. It occurred to me r
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Debugging Go Code with GDB
デバッグ/gdb - S.T.K Wiki
Ruby プロセスを追いかけるツール(プロファイラとか)10選 - sonots:blog
한국 아이폰