Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

ruby-debug in 30 seconds (we don't need no stinkin' GUI!)

Chad Woolley
Tuesday, January 8, 2008


Alfonso Bedoya, Treasure of the Sierra Madre

Many people (including me) have complained about the lack of a good GUI debugger for Ruby. Now that some are finally getting usable, I’ve found I actually prefer IRB-style ruby-debug to a GUI.

There’s good tutorial links on the ruby-debug homepage, and a very good Cheat sheet, but I wanted to give a bare-bones HOWTO to help you get immediately productive with ruby-debug.

Install the latest gem

$ gem install ruby-debug

Install the cheatsheet

$ gem install cheat
$ cheat rdebug

Set autolist, autoeval, and autoreload as defaults

$ vi ~/.rdebugrc
set autolist
set autoeval
set autoreload

Run Rails (or other app) via rdebug

$ rdebug script/server

Breakpoint from rdebug

(rdb:1) b app/controllers/my_controller.rb:10

Breakpoint in source

require 'ruby-debug'
debugger
my_buggy_method('foo')

Catchpoint

(rdb:1) cat RuntimeError

Continue to breakpoint

(rdb:1) c

Next Line (Step Over)

(rdb:1) n

Step Into

(rdb:1) s

Continue

(rdb:1) c

Where (Display Frame / Call Stack)

(rdb:1) where

List current line

(rdb:1) l=

Evaluate any var or expression

(rdb:1) myvar.class

Modify a var

(rdb:1) @myvar = 'foo'

Help

(rdb:1) h

There are many other commands, but these are the basics you need to poke around. Check the Cheat sheet for details.

This can also be used directly from any IDE that supports input into a running console (such as Intellij Idea).

That should get you started. So, before you stick in another ‘p’ to debug, try out ruby-debug instead!

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

15 Comments

  1. Brian Takita says:

    rdebug also pairs very nicely with editors that have an interactive console with links, because the links will take you to where the debug cursor is.

    This includes IntelliJ Idea and I believe Eclipse and Netbeans.

    January 9, 2008 at 3:09 am

  2. Brian Takita says:

    Also, a great code snippit for you editor is:

    require ‘ruby-debug’; debugger;

    I bind it to debug

    January 9, 2008 at 3:11 am

  3. Anil Wadghule says:

    Chad,

    I still not get it why do u choose rdebug script/server way, if you choose Brian’s snippet, it will just work. Is there any difference in using rdebug and Brian’s snippet?

    – Anil

    January 15, 2008 at 8:58 am

  4. Vasudev Ram says:

    Looks useful – thanks!

    - Vasudev
    ———–
    Dancing Bison Enterprises
    Software consulting and training
    Biz site: http://www.dancingbison.com
    Blog (on software innovation): http://jugad.livejournal.com
    Quick and easy PDF creation toolkit: http://www.dancingbison.com/products.html

    January 15, 2008 at 4:14 pm

  5. Tom says:

    I am really starting to like using ruby-debug. I find that I use it most often when running my unit and functional tests. The only problem I have is that it doesnt appear to read my defaults from the .rdebugrc file in this scenario. Anyone else seen this behavior?

    January 15, 2008 at 11:13 pm

  6. Chad Woolley says:

    @Anil,

    I think the primary difference is that when you invoke via rdebug, you don’t have to modify your code to set a breakpoint. It will stop on the first line of the script you pass to rdebug, and allow you to set a breakpoint or catchpoint. Sometimes this is more convenient.

    Also, I _think_ I’ve encountered situations where using the gem didn’t work as well as rdebug, but I think this was while debugging rubygems itself.

    – Chad

    January 16, 2008 at 4:12 am

  7. Chad Woolley says:

    @Tom,

    Yes, I’ve seen this problem where .rdebugrc is not read. There is a bug on the rdebug tracker. I think it may have been fixed in a recent version, and on previous versions only occurred sometimes (perhaps when using rdebug vs. debugger call in the code).

    If it isn’t working for me, I just manually issue ‘set autoeval’ and ‘set autolist’.

    – Chad

    January 16, 2008 at 4:15 am

  8. Chad Woolley says:

    Interesting Anecdote: Today, I was with a customer trying to debug cruisecontrol.rb. He uses NetBeans (which was the GUI debugger I referred to above that was pretty nice). However, we couldn’t get the debugger to breakpoint after a couple of minutes trying, so we used ruby-debug, which worked fine.

    In my totally biased and unscientific experience, ruby GUI debuggers seem to have problems with code that issues system calls (backticks, system(), IO.popen, etc). ruby-debug seems to handle this stuff better.

    – Chad

    January 16, 2008 at 4:23 am

  9. Jacqui says:

    @Tom – and anyone else who experienced ruby-debugger not reading your .rdebugrc file in Rails:

    The same thing happened to me. I found that in order to get my default settings applied for ruby-debugger, I had to include the following in my environment file – I only include it locally, for development, in a file that is included, fwiw:

    
    require 'rubygems'
    require 'ruby-debug'
    Debugger.start
    
    Debugger.settings[:autoeval] = true
    Debugger.settings[:autolist] = true
    Debugger.settings[:autoreload] = true
    

    hth,
    jacqui

    January 17, 2008 at 3:38 pm

  10. Ed Ruder says:

    I got an error on the `Debugger.settings[:autoreload] = true` line, using ruby-debug-0.9.3. Changing this line to:

    Debugger.settings[:reload_source_on_change] = true

    Got it to work! (Gleaned from the bottom of the ruby-debug-0.9.3/cli/ruby-debug/command.rb file.)

    Ed

    January 25, 2008 at 11:43 pm

  11. Ed Ruder says:

    Sorry about the formatting in the post above. To clarify, I changed this:

    Debugger.settings[:autoreload] = true

    To this:

    Debugger.settings[:reload_source_on_change] = true

    Ed

    January 25, 2008 at 11:45 pm

  12. Jacqui says:

    Ed, just saw your comments. Weird, I wonder why that works for me but not for you. This is in a Rails 1.2.5 app using rdebug v0.10.0.

    Perhaps we’re just on different versions of something. Glad you got it working, though.

    March 1, 2008 at 8:02 pm

  13. asd says:

    Debugger.settings[:autolist] = true

    doesn’t work, has to be:

    Debugger.settings[:autolist] = 1

    March 7, 2008 at 12:48 am

  14. Konstantin S. says:

    Hi Chad,
    Link to ‘cheat sheet’ seems to not work any more.

    March 24, 2013 at 11:55 am

    • Chad Woolley
      Chad Woolley says:

      Thanks, Konstantin – I’ve opened an issue with defunkt: https://github.com/defunkt/cheat/issues/15

      April 1, 2013 at 5:58 pm

Add New Comment Cancel reply

Your email address will not be published.

Chad Woolley

Chad Woolley
Denver

Recent Posts

  • Automating Bundler In Your Deploy
  • [ANN] GemInstaller 0.5.3 Released
  • The Great Ruby IDE Smackdown of '09
Subscribe to Chad's Feed

Author Topics

bundler (1)
geminstaller (2)
open source (5)
rubygems (4)
ide (1)
ruby on rails (5)
gogaruco (19)
government (1)
agile (18)
pivotaltracker (1)
testing (2)
mac (2)
remote (1)
rant (1)
mtnwestrubyconf (1)
dependency injection (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >