良いデバッグログはプロジェクトの資産であるhttp://eventdots.jp/event/591027 (2016-07-30追記：Rails 5.0からproductionでもDEBUGがデフォルトらしいです) (2020-09-23追記：https://github.com/rails/rails/pull/39707 INFOに戻りそう)
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
Hello, wonderful logging world! - Cube Lilac
この糞のような，素晴らしき（デバッグ）人生． と言う程でもないのですが，少し真面目に（デバッグ）ログの残し方について学習します．「えーマジ Logger 知らないの！？Logger 知らないで許されるのは小学生までだよね！」と言われそうですが，「最近の小学生は賢いですね」と言って流す事にします． Log4J ざっと見ていると，Log4J のようなインターフェースが主流のようです．そう言えば，以前に C# のコードをデバッグしている時もこれに似た形の Logger でした． Log4J には 3 つの主要なコンポーネントがあります。 Logger Appender Layout Logger は Log4J パッケージの中心クラスで、ロギングを行う部分をグループ化し、必要なグループのログだけを出力したり、カテゴリーに優先順位をつけることにより様々な出力方法を指定することができます。 Appe
メモリーリークの検出：mtrace , valgrind：プログラマー社長のブログ：オルタナティブ・ブログ
以前の記事にもLinuxでのメモリーリークの検出に関する事を書いたのですが、もう少し一般的なやり方を紹介しましょう（というより、自分で毎回忘れるので備忘録として・・・）。 【mtraceを使う方法】 まず、mtraceを使う方法です。リークのテストを開始したい場所でmtrace()をコールし、終了したい場所でmuntrace()をコールするようにします。 #include <stdio.h> #include <stdlib.h> char *test() { char *test=malloc(10); return(test); } int main() { char *ptr; mtrace(); ptr=test(); //*(ptr+10)='\0'; //free(ptr); muntrace(); return(0); } -gつきでコ
メモリ破壊の現場を見つける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
Google が公開しているソフトウェアの解説（その4）- Performance tools -
Google が Google Code でオープンソースとして公開しているソフトウェアの解説シリーズ(前回のエントリ)の第 4 回です。今回は Performance tools について紹介します。この Performance tools は、実際に Google 社内で広く使われており、特に、C++ でテンプレートを使用するマルチスレッドアプリケーションを開発する際に役立ちます。Linux 環境を主に対象としています。 Performance tools とは? C や C++ でプログラムの書いたことのある多くの人は、「プログラムを高速化したいけれど、どこが一番のボトルネックか分からない」とか、「メモリリークがあるようだけれど、どこで発生しているか分からない」といった問題で苦しめられた経験が一度くらいはあると思います。もちろん、こうした問題の解決策として、アドホックにプログラムをチ
Google Japan Blog: Google が公開しているソフトウェアの解説 ( その2 )
このエントリは、Google が Google Code でオープンソースとして公開しているソフトウェアの解説シリーズの第2回です。 今回は、Google CoreDumper というソフトウェアを紹介します。 このソフトウェアはアプリケーションプログラムから任意のタイミングでコアダンプを出力する機能を提供するライブラリです。 「 コアダンプ 」 はプロセスのある時点での状態を保存したファイルで、デバッグのときなどに利用されます。通常、プログラムが異常終了したときや特定のシグナルを受信したときに OS カーネルがコアダンプファイルを出力し、そのプロセスは終了します。開発者はそのダンプファイルを gdb などのデバッガなどで解析して問題の原因を調査します。 問題が発生してコアダンプが生成される場合以外にも動作中のプロセスのスナップショットをコアダンプファイルとして生成できれば、その時点でのプ
Emacs + GDB チートシート - higepon blog
Emacs + GDB を利用したいならば、何よりも GNU Emacs Manual: Debuggers（英語） を読むことを強くおすすめします。 和訳も存在しますが内容が古く、マウスを利用した操作やグラフィカルな機能についての記述がありませんでした。 マニュアルを読んで理解したあとは実践で覚えていくわけですが、以下にまとめたチートシートを利用すれば時間が節約できるかもしれません。 もしも便利な機能に関して漏れがあれば是非教えてください。 .emacs ;;; GDB 関連 ;;; 有用なバッファを開くモード (setq gdb-many-windows t) ;;; 変数の上にマウスカーソルを置くと値を表示 (add-hook 'gdb-mode-hook '(lambda () (gud-tooltip-mode t))) ;;; I/O バッファを表示 (setq gdb-use
C++ のプログラムのデバッグを楽にする方法
Google が公開しているソフトウェアの解説シリーズ(→その1 , その2)の続きです。今回は google-glog を使ってスタックトレースを表示する方法についてご紹介します。 C++ でプログラムを書いているとよく遭遇するのがセグメンテーション違反というエラーです。不正なアドレスへのアクセスなどによりセグメンテーション違反が起きると、通常、 UNIX 系の OS では SIGSEGV というシグナルによってプログラムが終了するとともに、 core というファイルが作られます。 core ファイルにはデバッガから参照できるいろいろな情報が残っていますが、多くの場合に役に立つのは、スタックトレースという情報です。スタックトレースを見れば、プログラムがどこでクラッシュしたのか、どのような関数を経由してそこにたどり着いたのかがわかります。プログラムがクラッシュした箇所を特定できれば、単純な
常駐型サーバープログラムのデバッグ手法
BOOK: WEB+DB Press TITLE: 常駐型サーバーのデバッグ手法(ドラフト版) AUTHOR: (株)プリファードインフラストラクチャー 太田一樹 ＊注: この文章はWEB+DB PRESS Vol.48に掲載された記事のドラフト版です はじめに 今回はデバッグ関連特集ということで、常駐型サーバープログラムを作成する際のハマりどころやそれに対する解析方法・解析ツール・対策を、実際の経験を交えながら紹介したいと思います。 筆者は(株)プリファードインフラストラクチャーでインメモリ分散検索エンジン「Sedue (セデュー)」を開発しています。モバイル向け検索エンジン「エフルート」や、2008/11/6にリニューアルされました「はてなブックマーク2」などの検索バックエンドとして使われております。 この検索エンジンはいくつかの常駐型サーバープログラムから構成されており
Debugging
"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs." Last changed on $Date: 2003/04/15 04:18:55 $. A practicing programmer inevitably spends a lot of time tracking down and fixing bugs. Debugging, particularly debugging of other people's code, is a skill separate from the ability to write programs in
デバッグのこつ
_ デバッグのこつ わたしがprintf()デバッグをしない理由とか わたしがprintf()デバッグをする理由とかを見て、 私も何か書こうかと思ったんですが、 面倒くさくなってやめてました。 でもちょっとだけ書くことにします。 前にも書いたんですけど、 Ian Lance TaylorのDebuggingというエッセイ を読んでください、でお終いだったりします。 特にここ。 Of course, sometimes a debugger does not help. [省略] In such cases simple print statements can sometimes help locate the source of the bad behaviour. Add print statements to relevant locations, rebuild the progr
Cowboy Programming » Debugging Memory Corruption in Game Development
Definition: Memory corruption is an unexpected change in the contents of a memory location. The symptoms of memory corruption can range from hard crashes, all the way through minor glitches, to no symptoms at all. The causes of memory corruption are many and varied, and include memory corruption itself. In this article I attempt to classify the various ways in which memory corruption can man
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
hogetrace - 関数コールトレーサ - memologue
でかいソフトウェアの、大量のソースコードを短時間で読む必要が生じたので、その補助ツールとしてptrace(2)ベースのLinux用関数トレーサを自作しました。こういうツール上でまずソフトウェアを実行してみて、どのファイルのどの関数がどういう順で呼ばれるか把握おけば、いきなりソースコードの山と格闘を始めるより楽かなーと思いまして。せっかく作ったので公開します。 http://binary.nahi.to/hogetrace/ straceはシステムコールだけ、ltraceは共有ライブラリ(DSO)の関数呼び出しだけ*1をトレースしますが、このツールは、実行バイナリ中の自作関数の呼び出しもトレースします。例えば再帰で1から10まで足し算するソースコードを用意して % cat recursion.c #include <stdio.h> int sum(int n) { return n ==
ウノウラボ Unoh Labs: gdbの使い方
今年の2月にマカーになったbokkoです。どうも僕の使っているフォントがほかの人には見づらいらしく、「そのフォントはねぇよw」と言われたり、外付けのキーボードを使っているせいか、「MacBookの意味なし!」と社内で言われてたりしています。 今日はgdbのお話です。gdbは非常に広く使われているデバッガで、特にC、C++のプログラムをデバッグするのによく使われています。 デバッガの使い方 プログラムをデバッグする際、例えば以下の方法が挙げられます。 1. ソースコードを読む 2. ソースコードに出力関数を仕込む(例えばprintf) 3. ソースコードを書き換えて実行してみる これで十分な場合もありますが、そうでない場合もあります。これらの方法ではプログラムを実行している最中にこちらからソースコードレベルでのアクションを起こすことが難しいので、例えば、プログラムをある時点で止めて変数の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Debugging in Haskell
What is a good way to debug haskell code?
gdbで特定の関数をアセンブルする - I am Cruby!