インフラエンジニアがSegmentation fault をなんとか治してみる - メモとかそんな感じなやつ
普段Webサーバを運用していて、めんどくさいトラブルのひとつに「Segmentation fault」があります。 あれー？なんか500エラーがでるなーなんて思ってログを見るとSegmentation faultになってるときは死にたくなります。 そもそもSegmentation faultはメモリ上にあるデータに対して不正が行われたときに起こるもので、 インフラエンジニアにとってはなかなか手がだせないところでもあります。 それでもなんとかして治さないといけないわけなので せめてどのプログラムが悪さしてるかどうかぐらいは調べ上げてみます。 apacheでのログ apache + mod_perl での環境です。 こんな感じでエラーがでます。 #tail error_log [notice] child pid 26028 exit signal Segmentation fault (11
Phactory: C言語：メモリ破壊検出ツール electric fenceの使い方
C言語に限らず、プログラム開発においてデバッグに多くの時間がかかるバグの一つとして、 メモリ破壊系バグが挙げられます。このバグは主に確保した配列を飛び越えてデータを書き込むことで 発生します。このようなプログラムは単純にprintf()等でシーケンスでバッグをしても、入力の種類に よって停止する位置が変わったりするので、まったくの無力です。逆にgdbでひとつひとつステップごとに 様々な変数やシーケンスをチェックしだすと、ものすごい時間を浪費します。 そんなとき、大活躍してくれるのがメモリ破壊検出ツールです。 いろんな検出ツールがあると思いますが、C言語で実装しているならば、手軽で実績もある electric fenceを試してみてください。 このツールは、プログラム中の動的配列(malloc等で確保した配列)の開始位置・終了位置を覚えて これらの配列の領域をポインタ等が踏み越えたときに
非対話的デバッガ YouDebug - 川口耕介のブログ
バグ修正はプログラマの仕事の一つですが、このうちのかなりの時間は問題を再現することに費やされます。 症状からバグの全容が推察できる時もあるのですが、多くの場合には、手元で問題を再現し、更なるデータを集めることによって始めてバグが理解されるからです。しかし、環境に依存する問題などは再現が難しい場合もあります。どうしたらよいでしょうか。 ロギングというのがよく行われる解決・予防策ですが、「デバッガを走らせて変数xの値を教えてくれればいいのに！」と思った事があるのは私だけではないと思います。ロギングと異なり、デバッガは予めプログラムに障害発生を予期するコードを埋め込んでおく必要はありません。また、呼び出し元のローカル変数をアクセスしたり、任意の式を評価したり、あるいは変数の値を変更することもできてしまいます。当たり前ですが、障害分析ツールとしてはデバッガはずっと強力だからです。 ではなぜユーザー
Jeliot :: Description
Jeliot 3 Jeliot 3 is a Program Visualization application. It visualizes how a Java program is interpreted. Method calls, variables, operation are displayed on a screen as the animation goes on, allowing the student to follow step by step the execution of a program. Programs can be created from scratch or they can be modifyed from previously stored code examples. The Java program being animated doe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
