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 、という意味になります。
人は誰しも108つの夢を持つと言いますが、読者の皆さんにも探偵を夢見た人は多いことでしょう。実際問題として探偵業をやろうと思ったら地道な聞き込み＆張り込みの日々でしょうし、逆に派手な探偵業は陰謀＆殺人で恐ろしい。わたしも自分の命は大事ですからどうするか。そう、探偵ごっこをするわけですね。 というわけでSEGV探偵です。死ぬのはプロセスなので安心。Rubyを使っていればSEGVなんて見慣れたものですが、いざ捜査しようと思うと意外とその辺には転がっていないもの。（むかしはつかみ取り出来るくらいいたそうですよ）とはいえ今でもいわゆる「バグ鉱脈」みたいなものはありまして、その一つが「最新のコンパイラでビルドしてみる」です。 今日はGCCの開発版であるGCC8を試してみましょう。FreeBSDだとsudo pkg install lang/gcc8-develで簡単に入れられるのですが、他の環境だと
オペレーティングシステムは、コンピュータのハードウェア管理、ファイル管理、データの入出力と管理、アプリケーションプログラムやユーティリティの実行、ユーザーとの対話などを効率的に行うための制御・処理プログラムの基本セットです。
ソフトウェアがデッドロックや無限ループ等で応答しなくなったり、Segmentation Fault等で強制終了したりする場合での、gdbを使った解析手法について簡単なまとめ。 なお今回の内容はunixやlinux開発での基本知識となっていると思うけれど、例えば組み込みlinux開発などでは活用できるのを知らずに、printfデバッグで頑張っている所が結構あるようだ。開発が楽になるので基礎として知っておいて損はないと思う。 ソフトウェアが落ちる状態の解析 まず例外発生などでソフトウェアが異常終了する場合の解析について。 例えば以下のコードを実行すると、メモリアクセスエラーで異常終了する。 //main.c void hoge1(void) { int *hoge = (int *)0xDEADBEEF; hoge[0] = 100; } void hoge2(void) { hoge1();
Run a program transparently, but print a stack trace if it fails gdb -batch -ex "run" -ex "bt" ${my_program} 2>&1 | grep -v ^"No stack."$ For automated unit tests I wanted my program to run normally, but if it crashed, to add a stack trace to the output log. I came up with this command so I wouldn't have to mess around with core files. The one downside is that it does smoosh your program's stderr
Enhance the display of gdb: colorize and display disassembly codes, registers, memory information during debugging. Add commands to support debugging and exploit development (for a full list of commands use peda help): aslr -- Show/set ASLR setting of GDB checksec -- Check for various security options of binary dumpargs -- Display arguments passed to a function when stopped at a call instruction d
The following instructions apply to the standard toolchain (the gc Go compiler and tools). Gccgo has native gdb support. Note that Delve is a better alternative to GDB when debugging Go programs built with the standard toolchain. It understands the Go runtime, data structures, and expressions better than GDB. Delve currently supports Linux, OSX, and Windows on amd64. For the most up-to-date list o
仕事で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の説明があります。
プロダクション環境で使用していた 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 は 定期的に監視プロセスを再起動する役割で使われています。再起動をす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
