Remote Debugging: explore Ruby code easily
By Martin Krauskopf on Nov 11, 2008
In the NetBeans 7.0 (dev)
you may attach debugger to any process which have been started from the command line, with all the goodies of UI
debugger frontend. This means that if you just found some strange behaviour or bug in some CLI tool or you are
just curious how e.g.
rake -T, etc. commands work, just run then in
debug mode from a terminal and attach to them from the frontend.
There is no need to setup a NetBeans project, even not to open the file or doing whatever in NetBeans, just invoking Menu | Debug | Attach action there.
Let's say we are curious how does
gem list --local works.
- you need to have have ruby-debug-ide in version 0.4.1 (just released) or later installed
rdebug-ide -p 7000 --stop -- `which gem` list --local. On Windows just replace
`which gem`with the
--stopswitch ensures that the debugger stops on the first line. This might not be always what you want if you've set the breakpoints in advance in the NetBeans frontend (e.g. after the first run with the
--stopswitch). Then just omit the switch and debugger will run until the first breakpoint is hit)
- In NetBeans invoke Menu | Debug | Attach choose Ruby Debugger in the Debugger combobox if there is more choices (you have also e.g. Java support installed)
That's all. Debugger will stop on the first line of the debuggee. After few steps you are inside RubyGems guts peeking around for how does it actually work.
This is the first step letting you to attach NetBeans debugger to the application run from CLI and/or on another machine. Next step is to provide functionality similar to ruby-debug that you will be able to put a call like:
if something_peculiar_has_happened require 'ruby-debug-ide' debugger(7000) # 7000 being a port end
into your application and attach to it from the frontend.
Altough this is kind of "remote" debugging and you may attach to the process which was run on another machine, there are not yet sources association implemented in NetBeans. So you would have to have sources located on the same paths on the local machine as the one on the debuggee's machine. But for the case similar to the above which are probably the most frequent one this might be very usefull.
Worth to add that the support were added quite recently. I've also made the code base little bit more "aggressive" which should help to stabilize the debugger a bit more among the layers (from base backend up to the frontend) and prevent kind of random exception. So if you found any problems the feedback is more then welcomed. Either let me know here or through the mailing list or Issuezilla. Thanks