rocky edited this page Apr 14, 2013 · 5 revisions

The trepanning debugger gdb-like debugger. As such, it is both a high-level and low-level debugger. It is a also a rewrite of ruby-debug. But to provide all of the functionality that it has, it requires a patched version of MRI Ruby 1.9.3 or 1.9.2 found the rb-threadframe project. The additional run-time support in the MRI is what gives this some debugger power that you won't find in other MRI 1.9 debuggers.

See the installation instructions.

There is a [google group mailing list]( for Ruby debuggers.)

If trepanning is installed, here is how to run:

   $ trepan ruby-program [program]

If your program needs options of its own:

   $ trepan -- ruby-program [program args...]

If you want to run from the source tree you can do that too:

  cd place-where-trepan-is-installed
 ./bin/trepan -- ruby-program [program args...]

Running from inside irb:

 require 'trepanning' 
 Trepan.debug { your code }

The return value from Trepan is the return value of the block, i.e. the final value in the block.

You can run the same thing inside your Ruby program, but probably you don't want to give a block. Instead, you may want to have debugging start on the next statement in the code:

 require 'trepan' 
 Trepan.debug # Don't stop here...
 work # but stop here.

The above is really shorthand for something like:

  $trepan =

The global variable $trepan set holds debugger settings, such as autolist" orautoeval` settings and breakpoint information.

Due to the line-event orientation in ruby-debug, it occasionally was convenient to add a synchronous stop in your program. I don't think that will be necessary here, but if you do call to the debugger at the point of the call rather than the subsequent stopping point, set opts[:immediate] to true. Example:

 # ... work, work, work 
 mydbg.debugger(:immediate=>true) # enter debugger here 
 # ... work, work, work

There is extensive on-line help. Run help inside the debugger.