Skip to content
R. Bernstein edited this page Mar 7, 2015 · 10 revisions

Things are simpler in trepan. To debug a loaded function inside irb:

Trepan.debug{ Columnize.columnize(%w(1 2 2)) }

Compare this with ruby-debug, to debug a loaded you might use:

Trepan.start{  debugger; Columnize.columnize(%w(1 2 2)) }

The start method causes extra overhead in stack tracking to start inside the block and this is turned off when the block finishes. In trepan there is no start or stop. To cause a block to be debugged use the Debugger::debug singleton method. An initial call to debugger is not needed, so the above becomes:

An entire session:

  $ irb
  >> require 'trepanning'
  => true
  >> Trepan.debug{Columnize.columnize(%w(1 2 3))}
  -> (/usr/local/lib/ruby/gems/1.9.1/gems/columnize-0.3.1/lib/columnize.rb:56)
  def columnize(list, displaywidth=80, colsep = '  ', 
  (trepan): finish
  <- (/usr/local/lib/ruby/gems/1.9.1/gems/columnize-0.3.1/lib/columnize.rb:213)
  end
  (trepan): info return
  Return value: "1  2  3\n"
  (trepan): c
  => "1  2  3\n"

To issue a debugger command, inside irb nested inside a debugger use ‘dbgr’. For example:

  dbgr %w(info program)
  dbgr('info', 'program') # Same as above
  dbgr 'info program'     # Single quoted string also works
But arguments have to be quoted because irb will evaluate them:
  dbgr info program     # wrong!
  dbgr info, program    # wrong!
  dbgr(info, program)   # What I say 3 times is wrong!

Here is an entire session:

  $ trepan /tmp/foo.rb
  -- (/tmp/foo.rb:1)
  x = 1
  (trepan): irb
  You are in a trepan session. You should have access to program scope.
  'dbgr', 'step', 'n', 'q', 'cont' commands have been added.
  You should have access to debugger state via global variable $trepan
  trepan >> dbgr 'info program'
  Program stop event: line; PC offset 2 of instruction sequence: <top /tmp/foo.rb>
  => false
  trepan >>