call_stack 0.1.0: making ruby-breakpoint/Rails' breakpointer work with Ruby 1.8.5

You don't want this, you want ruby-debug

Ruby 1.8.5 has been out for a couple weeks and broke Binding.of_caller and Rail's breakpointer. I'd promised I'd provide a workaround, and I finally wrapped it up.

I've just released call_stack: backtrace data and 1.8.5-safe breakpoint/Binding.of_caller, which provides an alternative Binding.of_caller implementation and some additional functionality to obtain backtrace information (the "call stack"). You can override a pre-existent binding_of_caller.rb by loading breakpoint185.rb:

 ruby -rbreakpoint185 myapp.rb

Here's how you'd use it with Rails' breakpointer:

1. put the breakpoint calls in the code you're inspecting, as usual
2. start the "breakpointer" as usual with script/breakpointer
3. run the application with ruby -rbreakpoint185 script/server

RubyGems caveats

If you've installed call_stack with RubyGems, -rbreakpoint185 will not work (RubyGems cannot handle -rlib options passed to ruby yet), and you'll have to do something like:

 ruby -e "require 'breakpoint185'; load 'script/server'"

(assuming you've set RUBYOPT=-rubygems, otherwise prepend it to the above line or add require 'rubygems')

Word of caution

Loading breakpoint185 will slow down your application a bit, since it uses a C event hook to record the binding and additional information on each method call, so it should only be used when debugging/inspecting some code.

call_stack was built with bits of code from an abandonned rcov: code coverage for Ruby branch, but in the future it might rely on Kent Sibilev's ruby-debug for the low-level work.

Still not working with rails - Michael Johnston (2006-11-27 (Mon) 22:31:38)

Hi,

I have installed call_stack, and I am sure that it's implementation of Binding.of_caller is being called because I patched breakpoint.rb in edge rails to explicitly load it. However, when I hit a breakpoint I still do not have the full context of the object the breakpoint is in. I only have local variables. selfKernel, and instance_variables["@__bp_line", "@__bp_file"]

Any ideas what's going on? I'm on an Intel mac, running edge (5642) rails with the macports build of ruby 1.8.5

Anonymous 2006-11-27 (Mon) 22:33:47

oops, unintended markup. I mean self is equal to Kernel, and instance_variables is equal to ["@__bp_line", "@__bp_file"]

mfp 2006-12-02 (Sat) 04:11:37

hmm, the new Binding.of_caller differs from flgr's if you call it inside a block, because its definition of the "caller" is different; it matches the call stack, unlike Ruby's #caller, which includes "virtual stack frames" corresponding to execution inside blocks.

Maybe that explains it?

cf 2007-01-01 (Mon) 23:48:14

I'm on wintel rails 1.6 and I also don't get the full context in the breakpoint session

vc 2007-01-05 (Fri) 11:29:05

I have same problem on MacOS X, edge 5849. After removing changes made in changeset 5424 ( http://dev.rubyonrails.org/changeset/5424 ) to get this workaround to load, I only have access to locals within actions.

Could mfp be correct? Did this ever fully work before?

mfp 2007-01-15 (Mon) 11:13:34

Well, it used to work :) Some quick tests seem to indicate that the call_stack method still works, but there's some problem in the interface to breakpoint.

Look at ruby-debug for another solution that AFAIK works OK right now: datanoise.com