何らかの理由でcoreが行方不明になることがありますが、
以下のような指定を行うと、指定した場所にcoreを吐かせることができます。

pre>>

sysctl -w kernel.core_pattern="/tmp/%h.%e.core"

<<--

最初から(core dumped) だけじゃなくて、dumpされた場所も表示してくれるといいんですけどね。

You can check the dependencies of *.so file by executing
ldd command like this

pre>>
% ldd foo.so
linux-gate.so.1 => (0xb7efe000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d7e000)
/lib/ld-linux.so.2 (0xb7eff000)
<<--

It's useful to attack problems regarding dlopen

merbでruby-debugを使ったデバッグをする方法を紹介します。

とは言ってもRailsの時と同様に非常に簡単で、ブレークポイントを仕込みたい場所に

ruby>>
debugger
<<--

と書いて、--debuggerオプションを指定してmerbコマンドを実行するだけです。

pre>>
% merb --debugger
<<--

Railsアプリを書いてる場合はあまり関係ないですが、
セグメンテーションエラー(SEGV)などに遭遇した場合に、
原因を調査する方法を紹介します。

まずは、coreを吐かせるためにulimitの設定をします。

sh>>
% ulimit -c
0
% ulimit -c unlimited
% ulimit -c
unlimited
<<--

ulimit -cが0になっている場合は、coreを吐かないので、
適当な値を設定するか、unlimitedにします。

あとは、プログラムを実行してランタイムエラーを引き起こし、
coreファイルを出力させます。

sh>>
% ./command
zsh: segmentation fault (core dumped) ./command
<<--

さて、今度はgdbの出番です。
gdbは対話型のデバッガです。
以下のように、gdbにオプションを指定して起動します。

pre>>
% gdb ./command --core=./core

.. snip ..

Core was generated by `./command'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048a43 in vec_sub (a=0x804e248, b=0xbfa9e720) at vec.c:124
124 const __m128 t_vec5 = (*a) ;
(gdb)
<<--

すると、上記のように対話セッションが開始されます。
あとは、表示された内容や、gdbのコマンドを使って原因を解析すればOKです。
例えば上記の出力の例では、aのアドレスが16バイト境界に乗っていないのが
原因であることが推察できます。

ソースコードが手元にある場合は、gccに-gオプションをつけてコンパイル
することで、lコマンドによって以下のようにエラーが発生した場所の周辺の
ソースコードを見たりすることができるようになります。

pre>>
(gdb) l
119 return t_vec3 ;
120 }
121
122 __m128 vec_sub (const __m128 * a, const __m128 * b)
123 {
124 const __m128 t_vec5 = (*a) ;
125 const __m128 t_vec4 = (*b) ;
126 const __m128 t_vec6 = _mm_sub_ps( t_vec5 , t_vec4 ) ;
127 return t_vec6 ;
128 }
<<--

gdbを終了する場合は、qコマンドを実行します。

以前は、Railsのhelperメソッドのオプションや細かい挙動を調べるために、
secondlifeさんの
http://api.rails2u.com/
や、
:::ruby.search:::
のお世話になることが多かったのですが、
近頃ではRailsのドキュメントを参照する機会が減ってきました。

細かい理由はいろいろあるのですが、一番大きいのは、
以前紹介したRak
を使って直接Railsのソースを確認するのが便利な事です。

使い方はこんな感じです。

• vendor/rails以下にRailsをfreezeさせます。
• GNU screenでcd vendor/railsしたスクリーンを用意しておきます。
• 何か調べたいときは、rak def\ method_nameを実行して、出てきたファイルをvimで読む。
• Rtags（rails.vimの機能）でジャンプもできる。

さらに、細かい挙動やメソッドに渡ってきた値を調べたい時などは、
vendor/railsのソースにdebuggerと書き込んで、
script/server -uでデバッグモードを起動します
（「Rails 2.0でデバッグをする新しいやり方」参照）

比嘉さんからciteされたみたいなので、取り急ぎ新しい情報を吐き出しておこうと思います。

そろろろRailsについて本音を書いてみるか

後、デバッグの環境は、Javaに比べて貧弱だと思う。Railsでデバッグをする７つの方法を見てほしい。IDEでソースにブレークポイントを設定(ソースコードを書き換えるのではなく)して、ステップイン、ステップオーバー、メモリの状態を見たりなんてのに慣れているJavaから比べると、すっごく大変に見える。

喜ばしいことに、Rails 2.0ではruby-debugを使ったdebuggerが正式に採用されました。
これの使い方は非常に簡単です。

まずは、以下のようにブレークポイントをコード中に書き込みます。

rails>>
def some_method
debugger # breakpoint
end
<<--

続いて、Webサーバをデバッグモードで実行します。

shell>>
% ./script/server -u
<<--

これだけです。あとは、実際にブレークポイントを仕掛けた
場所が実行されるようにすれば、gdbライクなruby-debugの
セッションが開始されます。
ruby-debugは、gdbと同じように、ステップ実行、ステップオーバー等の逐次実行を行うインターフェイスがあるので、
コードの動作を確認しながらデバッグを行うことができます。

gdbになれていない人には、irbコマンドを実行することで、
その場でirbを立ち上げることができます。これは非常に便利ですね。

参考までに、debuggerから実行できるコマンドのリストを
載せておきます。

pre>>
backtrace break catch cont delete display down eval exit finish frame help irb list method next p pp quit reload restart save script set step thread trace undisplay up var where
<<--

Have a good debugging life!

See Also

• MOONGIFT: ? Railsのデバッグのお供に「ruby-debug」:オープンソースを毎日紹介

更新履歴

• 2008/01/21 See Alsoに1点追加

You can see also http://blog.s21g.com/articles/212, the article written about the same theme for
comparison, if you are familiar to Japanese.

1. p/pp

This is a very popular method used not only in Rails but also in other
debugging. In Rails this method should be used on web server which is in the states of foreground process.

shell>>
$ ./script/server
<<--

If you are familiar with p/pp, it should be simple and easy.

2. logger.debug

For logger.debug, the following example will explain fully.

rails>>
logger.debug "something interesting information"
<<--

Calling logger.debug, you can create a log file of
log/$RAILS_ENV.log such as log/development.log.

By configuring the output file to:

shell>>
$ tail -f log/development.log
<<--

you can check the debug output log in the same manner as in p/pp debugging.
Furthermore, as the result is output in a log-file format, you can
refer it later on.

3. script/console

script/console comes in handy when you check the DB contents during
the operation. Executing "script/console" command, irb
launches after confirming Rails environment.
You can change DB as you like by using ActiveRecord, such as find,
create and destroy_all.This is very tactful feature.

4. script/breakpointer

As previously described, although script/console
comes in very handy and tactful, it can not check session status
during the action.
In that case, you can use "script/breakpointer" for it.

shell>>
$ ./script/breakpointer
<<--

Please make sure to launch a breakpointer initially.
Then locate a "breakpoint" to the position where you want to check
the status.

rails>>
class FooController < ApplicationController
def bar
# something
breakpoint
# something
end
<<--

Then you execute bar action through brower access and check and
manupulate the necessary information
after the launch of irb at the set breakpointer.

5. better rails debugger

script/breakpointer is very useful but it has a weak point
as it cannot operate step execution.
We understand you rarely experience the need for step execution,
however, it's better to have a method than nothing. The ruby-debug
Gem, informed by yugui in the last Rails meeting, will meet the need.
First of all, make sure to install ruby-debug in advance.

shell>>

gem install ruby-debug

<<--

Then, add a breakpoint.

rails>>
class FooController < ApplicationController
def bar
# something
debugger
# something
end
<<--

After launching Web server such as Webrick or Mongrel on foreground,
which is used in p/pp debugging,
you make an access to execute targeted code through the browser. Then
something similer to debug.rb launches in Web server process.
Now you can start debuggin in the same manner as you do with
general ruby script.

6. test/autotest

In Ruby on Rails, test framework is ready to use by default.
Generally, specification is designed after writing a test code in test
operation development.
However, you can write a test code for
verification of desired behavior and also utilize it for debugging.
It takes time to operate every test by using "rake" command, I
recommend to use autotest in ZenTest.This autotest operates only
related tests for modified files, and can provide quicker response
than using "rake" command.
If you use a redgreen as a combination, the smooth operation will
please you while debuggin.

7. tail -f log/development.log&; autotest

Lastly, let me intriduce my current method.I launch a separate
terminal other than for development, and operate following command in
RAILS_ROOT.

shell>>
$ tail -f log/development.log&; autotest
<<--

This arrangement enables to display the autotest output in editing
program and test code
and the logger output when there is an access from the browser.
Basically, those two runs asynchronously, you can fully use one
terminal.

xxxx_controller.rbはXxxxControllerが定義されているべき、
というようなエラーメッセージが出た場合、
XxxxControllerのクラス定義のなかでエラーが発生している
事が原因だったりするみたいですね。

お手製の acts_as_xxxxx を使ってたりする場合、
その辺でエラーを出してないかチェックすると良いようです。

記事の引越しから漏れていたのでサルベージ。 [secondlifeさんの記事](http://d.hatena.ne.jp/secondlife/20061010/1160453355) に反応して後で書こうかなあと思っていたら、大分時間がたってしまいましたが、めげずに書いてみます。

1. p/pp

こちらはRailsに限らず良く使われている方法ですが、RailsではWebサーバをフォアグラウンドプロセスとして立ち上げた状態で使う感じになります。 pre>> $ ./script/server <

2. logger.debug

さて、続いてlogger.debugを使う方法です。
pre>>
logger.debug "something interesting information"
<
>
$ tail -f log/development.log
<
3. script/console

script/consoleは、実行時にデータベースの中身がどうなっているかを知りたい時に非常に便利です。script/consoleコマンドを実行すると、Railsの環境を読み込んだ状態でirbが立ち上がるので、ActiveRecordを使ってfindしたりcreateしたりdestroy_allしたり、好きなようにDBをいじる事ができます。本当に素晴らしい機能ですね。


4. script/breakpointer

script/consoleはとても素晴らしいのですが、アクション実行中のsessionの状態を調べたりするのには使えません。そんな時は、script/breakpointerを使う事ができます。
pre>>
$ ./script/breakpointer
<
>
class FooController < ApplicationController
  def bar
    # something
    breakpoint
    # something
  end
<
5. better rails debugger

script/breakpointerはとても便利ですが、ステップ実行が出来ないという問題があります。
実際にステップ実行がどうしても必要という場面はあまり無いのですが、あればあったほうが便利ですね。そんな時は、ruby-debugというGemを使います。
これは前回のRails勉強会のときにyuguiさんから教えていただいた方法なのですが、まずはruby-debugをインストールします。

pre>>
# gem install ruby-debug
<
>
class FooController < ApplicationController
  def bar
    # something
    debugger
    # something
  end
<
6. test/autotest

Ruby on Railsでは、テスト用のフレームワークがはじめから使える状態になっています。
テスト駆動開発では、テストを書いてから実装を書きますが、適当な動作検証用のコードをテストとして書くことで、デバッグに使う事もできます。この際、毎回テストをrakeコマンドから実行するのは時間が掛かるので、ZenTestのautotestを使うのがお勧めです。
autotestを使うと、編集されたファイルに関連するテストだけを実行してくれるので、rakeコマンドを実行するよりも軽快なレスポンスが得られます。さらにredgreenを併用すると気分良くデバッグを行う事ができるのでお勧め。

7. tail -f log/development.log&; autotest


最後に、僕が今使っている方法を紹介します。
開発用とは別に一つターミナルを立ち上げて、RAILS_ROOTで以下のコマンドを実行。
pre>>
$ tail -f log/development.log&; autotest
<

というわけで、Railsでデバッグを行う方法の紹介でした。

Core Services社が提供している
DebugBarと
Companion.JS
を使って、IE6のデバッグ環境を改善してみた。

DebugBarは、ツールバー（DeskBand）とサイドバー（InfoBand）を使ったIE拡張で、DOM Inspector的な機能がある。Companion.JSは、CommBandを使ったIE拡張で、Script Console機能を持っている。

IEのJavaScriptデバッグには、本当に難儀していたので有難い。