Rustプログラムのデバッグ辛すぎ問題 - Qiita
この記事は Rust Advent Calendar 2023 シリーズ2 の1日目の記事である。 Rustは良くも悪くもシステムプログラミング言語なので、何も工夫しなければデバッグの体験がC言語と同じレベルになってしまう。例えば「rust lldb」でググると上位に Debugging Rust programs with LLDB is a nightmare というスレッドが出てきてしまう。 使うべきツールを知っていれば幾分かマシな体験にできる。Rustコンパイラはデバッガとして LLDB, GDB, WinDbg/CDB をサポート していて、僕はWinDbGは10年くらい触ってないので、この記事ではLLDBとGDBについて書く。 LLDB Apple SiliconのMacだとGDBが使えないので、必然的にLLDBを使うことになる。 CodeLLDB GDBと同じく、LLDBにも
デバッガと和解せよ
2022/08/28 Kernel/VM探検隊online part5 (https://kernelvm.connpass.com/event/256248/) の @nullpo_head (https://twitter.com/nullpo_head) の発表資料です。 ptraceを使って対象コマンドの全子プロセスにattachしてDwarfを見つつデバッグしたいプロセスを探し、最終的には他のデバッガに処理を流すような不思議なデバッガ(?)を作ることで、zero configurationでvscodeでブレークポイントを打ったプロセスのデバッグを始めてくれる dbgee (https://github.com/nullpo-head/dbgee) という便利ツールを作ったときの話をしました。
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
自分がコンパイルしていないライブラリの中をGDBで追跡する
多くのプログラムはすべての機能を自前で実装しているわけではなく， ライブラリと呼ばれる外部のプログラムに依存しています． よく使われるライブラリには， 数学関数(cos, sinなど) 各種データ形式(XMLなど)の読み書きを扱うライブラリ GUIを構成するライブラリ. GTK, Qtなど グラフィクス (X Window) などがあります．あるプログラムの内部を調べようと思って， ソースからコンパイルしたとしても， それらのライブラリまでコンパイルされるわけではなく， ライブラリは元々システムにインストールされているものが使われることがほとんどです． なので，プログラムの実行がライブラリ内に突入すると， ソースコードを見ながらデバッガで追跡することが困難になります． 通常，ライブラリ関数の中身まで追跡する必要はないので， このことはあまり問題になりません． ライブラリ関数の呼び出しに差し
ptraceシステムコール入門 ― プロセスの出力を覗き見してみよう！ - プログラムモグモグ
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
リバース実行を用いた gdb によるデバッグ - troushoo
プログラムを逆に実行するリバース実行を用いた、gdb によるデバッグ方法を紹介します。 「変数 x が不正な値になっていたが、いつ不正な値になったのか」といった場合のデバッグに便利です。 サンプルプログラム 変数 x の初期値が 0 で、その後 func1() により 1 に変更される、単純なサンプルプログラムを用います。 プログラム終了時から、プログラムを逆に実行し、いつ変数 x が変更されたかを調べます。 「gcc –g gccreverse.c」でビルドしておきます。 #include <stdio.h> int func1(){ return 1;} int main(void){ int x = 0; x = func1(); printf("%d\n",x); return 0;} リバース実行を用いて gdb でデバッグ 1. 「gdb a.out」を実行し、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)
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など多数のモジュールを全部入りで表示しているためゴチャゴチャしているが、設定で自分に必要なモジュールだけを表示するようにできる。 訳者もしばらく使っているが、
実行中のマルチスレッドプログラムの特定スレッドのみ停止(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を使っていい感じにプロセスツリーを手元の端末に繋ぎ変えるシェルスクリプト - ももいろテクノロジー
次のエントリにあるように、gdbを使うとプロセスの標準入出力を別の端末（tty）に繋ぎ変えることができる。 コンソールから切れたプロセスを標準出力につなげなおす - 絶品ゆどうふのタレ しかし実際にはあるプロセスからサブプロセスが複数呼ばれている状況もあり、そのような場合にはそれぞれのプロセスについてgdbでアタッチして端末を繋ぎ変える必要がある。 そこで、この操作を楽に行うためのシェルスクリプトを書いた。 #!/bin/bash # grabtty.sh rootpid="$1" newtty=$(tty) if [[ $(whoami) != "root" ]]; then echo "must be root." exit 1 fi if [[ -z "$rootpid" ]]; then echo "Usage: $0 PID" exit 1 fi grabpid() { loca
Linux 上のC++ アプリをVisual Studio でリモートデバッグ - troushoo
概要 Visual Studio GDB 拡張機能を利用すると、Linux 上のC++ のアプリをVisual Studio からリモートデバッグすることができます。 内容 Visual Studio でLinux 上のC++ アプリをリモートデバッグする方法を、以下の4つのセクションに分けて順に紹介します。 Visual Studio のバージョンは、Visual Studio 2015 Community かそれ以上が必要です。 1. Visual Studio GDB 拡張機能のインストール 2. Linux への証明書を使ったSSH 接続のための準備 3. Linux にコンパイラ、デバッガーをインストール 4. Visual Studio でLinux 上のC++ アプリをリモートデバッグ 1. Visual Studio GDB 拡張機能のインストール 1.1. Visual
ELF実行ファイルのメモリ配置はどのように決まるのか - ももいろテクノロジー
Linux x64環境において、ELF実行ファイル、共有ライブラリ、スタック領域、ヒープ領域のアドレスがどのように決まるのかについてのメモ。 環境 Ubuntu 12.04 LTS 64bit版 $ uname -a Linux vm-ubuntu64 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.4 LTS Release: 12.04 Codename: precise $ gcc --version gcc (Ubuntu/Linaro 4
Go言語のトラブルシューティング用機能
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
5.3.5. 個別スレッドのデバッグ Red Hat Enterprise Linux 6 | Red Hat Customer Portal
開発者ガイド 1. Eclipse の開発環境 Expand section "1. Eclipse の開発環境" Collapse section "1. Eclipse の開発環境" 1.1. Eclipse プロジェクトの開始 1.2. Eclipse ユーザーインターフェース Expand section "1.2. Eclipse ユーザーインターフェース" Collapse section "1.2. Eclipse ユーザーインターフェース" 1.2.1. クイックアクセスメニュー 1.2.2. キーボードショートカット 1.2.3. パースペクティブのカスタマイズ 1.3. Eclipse での C/C++ ソースコードの編集 Expand section "1.3. Eclipse での C/C++ ソースコードの編集" Collapse section "1.3. Ec
脆弱性検査ツールまとめ - Qiita
Medusa John the Ripper Hydra Paros BeEF 全般 Nessus OpenVAS Metasploit QualysGuard：NTTデータ先端技術株式会社さんが使ってるみたいですね。 Paraben P2 EnCase Fuzzer Peach Fuzzer Ruby on Rails Brakeman Android PenTest Tools List：リストとはいえ便利です。 WordPress WPScan Webアプリケーション Recon-ng ratproxy skipfish Nikto2 OWASP Zed Attack Proxy sqlmap WebProbe HTTPプロキシ Burp Suite Charles Fiddler x5s Ammonite Watcher intruder21 ソースコード iCodeChecker
gdbに構造体定義を読み込ませて使う - ももいろテクノロジー
ヘッダファイルなどから構造体の定義などがわかっているとき、gdbにこれを読み込ませることでメモリ内容を構造体定義に合わせて表示させることができる。 これを行うには、gccでデバッグ情報付きのオブジェクトを作った後、gdbのadd-symbol-fileコマンドで読み込ませればよい。 ここでは、link.hおよび内部でインクルードされるelf.hを使って、実行時のELFセクションの内容をたどってみる。 まずはヘッダファイルをC言語ソースとみなして、デバッグ情報付きでオブジェクトファイルにする。 ここでは、コンパイルまでを行いリンクは行わないので、-cオプションをつける。 さらに、-fno-eliminate-unused-debug-typesオプションを使い、変数宣言されていない型もデバッグ情報に含めるようにする。 $ gcc -g -fno-eliminate-unused-debug-
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
monit 5.4 のバグ - マルチスレッドでfork(2)してデッドロック - hibomaの日記
プロダクション環境で使用していた monit 5.4 がデッドロックを起こしていたので調査をしていました。なお、本エントリで記述されているバグは monit 5.5 で修正されています 要約 長い内容なので最初にまとめておくと monit はマルチスレッドアプリケーションである monit 5.4 には fork(2) 後に localtime_r(3) を呼び出す処理があり、これらが稀にデッドロックを引き起こす monit 5.5 系では fork(2) 前に 変更された。 /usr/bin/gstack は便利ツール マルチスレッド + fork(2) でデッドロックするパターンに要要注意 これらの内容に興味がある方は読み進めていただければ ... 問題になった monit プロセスの運用について 該当の monit は 定期的に監視プロセスを再起動する役割で使われています。再起動をす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gdbgui/README.rst at master · cs01/gdbgui · GitHub