Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
ErrbitはRuby on Rails製のオープンソース・ソフトウェア（MIT License）です。 システムのエラー時にメール送信したりするライブラリがありますが、複数人で開発していてその修正状況を適切に管理するならば専用のエラー管理サーバを立てるのが良いでしょう。今回はErrbitを紹介します。 まずErrbitへログインします。ユーザは複数登録して権限管理ができます。 ログインしました。最初にアプリが一覧で表示されます。 アプリケーションを見ると、その設定方法が記載されています。 エラーの一覧です。 エラーの詳細です。ここにコメントもできます。 エラーメッセージ。エラーの詳細を確認して修正を行います。 パラメータも確認できます。 セッション情報です。 ユーザ一覧です。 Errbitを使えば運用しているサービスに対して発生したエラーを一元管理できるようになります。主にRuby向けで
わたしがprintf()デバッグをしない理由 ...くそぅ、まだまだバグベアード( why バグベアード？ )の知名度が足りねぇのか。 printf デバッグにおいてはバグベアードのようなモジュールを利用するかどうかで大きく話の前提が変わるんだけどなぁ。自分的には「この作者、頭おかしい！」と呼んでもらうに足るレベルの作り込み*1に達していると思ってんだけど、その存在を知ってもらってなけりゃそりゃお話にならんわな。('A`) しかもこの人、 Debug Hacks の著者かよ。あの様子だとデバッグツールの紹介としても一言も触れられていないんだろうなぁ。バグベアードの存在はまさに Debug における Hack だと言うのに。 printf デバッグの是非について少し自分の意見を述べておきますと、多くの場合、printf デバッグはそれが場当たり的に行われるものである点が非常にまずいものだと考
ソフトウェア開発で不可欠なデバッグですが、知識と経験が求められるため熟練プログラマのなかにもデバッグが苦手という開発者は少なくありません。洗練されたデバッガを利用できても、デバッガのどの機能がどの場面で有効かを見極めるのは簡単ではないからです。本書では、Linux/Unixプラットフォームでもっとも広く使われているGDB、DDD、Eclipseという3つのツールを取り上げ、各ツールに独自のデバッグテクニックはもちろん、コードに含まれるエラーを見つけ出して修正するプロセスを改善するための総合的な戦略についても解説します。翻訳版ではVisual C++でのデバッグ手法についても加筆しました。 関連ファイル サンプルコード（.zip） 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。
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」などの検索バックエンドとして使われております。 この検索エンジンはいくつかの常駐型サーバープログラムから構成されており
TOPICS Hacks , Programming , Linux , Ruby 発行年月日 2009年04月 PRINT LENGTH 424 ISBN 978-4-87311-404-0 FORMAT PDF ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 Debug Hacks推薦の言葉 プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれた蛾に
プログラムが機能を果たせない場合には、有用なエラーメッセージを返し、問題を解決する手がかりを提供するのが理想的だ。しかし残念ながら、このような理想的な状況は珍しく、アプリケーションでエラーが発生したときに、手元に何の情報もないことも多い。 ここで、デバッグツールの登場だ。私にとってなくてはならないツールの1つが、straceだ。straceはシステムコールトレーサで、すでに実行されているプログラムによって発せられたコールを追跡する（straceを既存のPIDにバインドする）ことも、テストしたいプロセスをstraceに開始させることもできる。 では、straceの使い方を実例とともに見ていくことにしよう。 KDE起動時の問題 以前、私はKDEを起動する際の問題をデバッグしていた。返されたエラーメッセージからは、何の手がかりも得ることができなかった。 _KDE_IceTransSocketCr
2008/12/23発売のWEB+DB PRESS Vol.48に「常駐型サーバーのデバッグ手法」というタイトルで短い記事を書かせて頂きました。 WEB+DB PRESS Vol.48 作者: 大沢和宏,高橋征義,山本陽平,高塚遙,高林哲,小飼弾,はまちや2,角田直行,田淵純一,伊野友紀,鈴木啓修,古谷洛人,伊藤直也,田中哲,太田一樹,松田明,鶴岡直也,佐藤竜一,cho45(さとう),吉田俊明,福島克輝,渡部広志,矢作浩,森田創,縣俊貴,大塚知洋,武者晶紀,ミック,下岡秀幸,nanto_vi,田中洋一郎,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2008/12/22メディア: 大型本購入: 4人 クリック: 32回この商品を含むブログ (30件) を見る 常駐型サーバープログラムにおいて、問題が起こりやすい点をまとめた他、問題解析に役立つ各種ツール(valgri
research | いろいろ思い悩んでいたが、意外とあっさりとカタがついた。maedaさんのおかげで･･･。手伝ってもらったおかげでできたのはよかったけれどまた「よし、これね」という感覚はお預け。とはいえ、次のことをやればいい、というのがわかったので収穫有り。今回の教訓。 構造上のバグの見つけ方はなんとなくはわかっていたけれど、どうも今回はそれじゃなかった。すでにできあがったパッケージを使ったりして構造上のバグがなくても、数値を実際に入れてみると途中で計算できなくなったりしてエラーが出ていた。そんなときの対処法は以下のとおり。バグが出たところでどの値がおかしいかを徹底的に調べる。もともとのアルゴリズム(作業の流れ)をきちんと把握すること関数や変数はもとをだとっていく必要があるが、計算された前の結果で問題があるのか、それとも計算後なのかをチェックする。計算前ならその関数に入れている引数の
なかなか正体を現さないバグ．退治しても退治しても何度でも現れるバグ．初心者しかやらないような間抜けなバグ． プログラミングシンポジウムでは，50回の記念行事として，このように厄介な，しかし愛すべきバグたちの供養，バグ祓いを執り行うことになりました． お祓いしたいバグをお持ちの方は，下記の内容でお申し込みください．シンポジウム当日にお祓いします． バグのなまえ (戒名ではありません．故バグを一発で偲ぶことのできるよい名前をつけてください．) 出現箇所 (システム名称などのことです．ついでに地理住所が入っていてもバグを偲ぶことができてリアルです．) 出現状況 (なるべく抽象化してわかりやすく記述してください．分量は多くの人が閲覧の上，供養できるようにA4半ページ，最大でもA4 1枚以内に押えてください．) 命日 (ログや日記等を調べて，なるべく正確な日付を入れてもらえるとうれしいです．まだ生き
yebo blog: クヌース先生がバグ報告に対して小切手の支払いをやめることに
2008/10/31 クヌース先生がバグ報告に対して小切手の支払いをやめることに クヌース先生はTEXのバグや自著の間違いを発見し報告した人に対して、2.56ドルを支払うとしていることはよく知られている。今回、クヌース先生から金融システムの信用崩壊のため、もはや個人の小切手は安全ではなくなったという理由で、バグ報告に対しては小切手を支払わないことに決めたそうだ (最近、クヌース先生の当座預金に対して、犯罪行為が行われたようである)。そこで、バグ報告をしてもらった人に対してはドルの小切手ではなく別の手段、ピンカス惑星上のブレフスク (Blefuscu) と エルボニア (Elbonia) に支店を持つサン・セリフ銀行 (Bank of San Serriffe)に定期預金口座を作ることにしたそうだ(0x$1 = USD2.56)。2006年以降に発行した小切手275枚のうち、実際に払い出され
ImageMagickの基本的な使い方 ここでは、衛星画像を題材にして、ImageMagickの基本的な使い方を説明しています。 Windowsで演習する場合には、前提として、Cygwin、ImageMagickの インストールが済み、PATHも設定してあるものとします。 ちなみに、LinuxではImageMagickの各コマンドがインストールさ れていることが多いので、Linux環境の人はすぐに下記の演習内容を試すことが できるはずです。 ImageMagickの中でも、 convert composite を使用します。特に、convertはよく使用しますので、使い こなせるようになってください。 この演習で処理した画像例は、 このページの末尾に掲載されていますので、 参照してください。 画像の保存 まずは、以下の演習で使用する画像（JPEG画像：バンド1〜7）を保存しよう。 [バンド
glog - Logging library for C++ Google, Software Engineering Team, Shinichiro Hamaji氏はGoogle Open Source Blogにおいてglogを発表した。glogはアプリケーションレベルで活用するロギングAPI。C++スタイルストリームのAPIを提供するほか、さまざまなヘルパーマクロを提供している。ライセンスは3条項BSDライセンス。 多くのソフトウェアは必ずといっていいほどバグを抱えており、バグを修正するためにはログデータが欠かせない。glogはそういった用途で活用するためのライブラリ。すでにGoogle社内で広く活用されているものとされている。シンブルでさまざまな機能を提供しており、コマンドラインからログの振る舞いを変更できるという特徴がある。 サポートしているシステムはFreeBSDやMac O
意外と知っているようでよく知らない自分が日々使う道具。そこで、gdbについて復習がてらいろいろ調べることにする。 gdbはemacsから使う gdbをコマンドラインから素で使うのはいかがなものかなと思う。やっぱemacsと固く結合されているわけだからemacsから使うのが正しい姿であろう。 「え〜、だってvi使いだし〜」とか「秀丸からは使えないんすかね」とか言うやつがいるが、秀丸ってなんだよ、とりあえづubuntuでも入れて、emacsいれて、gdb使いなさいとか指導したくなる。いかんいかん、説教くさくなってはいかんいかん。 先日もある会議でデバッガの話が話題になったのだが、「TCPなんちゃらのストール問題のデバッグ方法なんですけどね」、みたいな話題で、「それってカーネルの話？」とわたしが聞くと、「いや、ユーザランドっす」と若いハッカー、「じゃ、gdbでほげほげでいけそーね」、「そーっすね
最近は、今進んでいるプロジェクトがもうすぐひと段落するので、僕はデバッグをがりがりすることが多いです。バグがあるときになって帰れないので、終電を逃すことが多く、最近は日記を更新できていませんでした（＞ω＜） 前々から、僕はけっこうプロジェクト終盤でもICPCでもデバッガーとなることが多いのですが、そのときにためた、バグをとるポイントなどまとめてみることにします。 といっても、GDBを使うととれるようなバグは、GDBを使えばとれますのであんまり難易度が高いものではありません。悩んでもなかなかみつからない、なかなかとれない類のバグをとるのが僕は好きですが、そのときに何を考えてとっているのかを紹介します。といっても、僕はここらへんのことは自己流なので、当然もっといい方法があると思っています。なので、コメントなど熱烈歓迎です！！ 難しい類のバグをとる際に一番重要なのは、バグにかかわるあらゆる状況を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
