Skip to content
This repository has been archived by the owner on Sep 14, 2018. It is now read-only.

Debugging

Jump to bottom
rdp edited this page Sep 13, 2010 · 9 revisions

Simple debugging techinques

  • System::Diagnostics::Debugger.break – This technique allows you to insert a Visual Studio breakpoint in the Ruby code. When the code executes, you will get a dialog box which will allow you to attach Visual Studio to the process. It is a lightweight technique to get to a Visual Studio breakpoint without having to launch the process from within Visual Studio, which is also possible but needs changing the Project Properties.
  • repl binding – You can also put calls to repl(binding) anywhere in your code to pause your code and get a REPL interactive session (lightweight version of irb), which allows you to inspect locals and run arbitrary Ruby code in the local context.
  • set_trace_func – You can also use set_trace_func for a simple tracing experience to see the control flow, value of arguments along the way, etc.

Debugging with Visual Studio

Using Visual Studio allows you to use an IDE to set breakpoints, step into code, etc. This works very well for debugging the IronRuby runtime. Debugging Ruby code works reasonably well, but is a work in progress.

Debugging C# code

In the Debug tab of the Project properties for Ruby.Console.csproj, set the fields as follows:

  • Start Action:
    For Ruby.Console.csproj, “Start project” should be enabled.

For any other project, “Start external program:” should be enabled and set to “c:\vsl\Merlin\Main\Bin\Debug\ir.exe”

  • Start Options:
    You can leave “Command line arguments” empty to get the REPL loop, or set it to the path to some .rb file to run the .rb file. Hitting F5 should now run the .rb file under VS, and allows you to set breakpoints as you would expect in IronRuby.dll and IronRuby.Libraries.dll (ie. in C# source code).

Debugging Ruby code

If you want to put breakpoints in Ruby code, make sure to remove the -X:Interpret option and instead add the -D option (which will cause IronRuby to use the debuggable System.Reflection.Emit.AssemblyBuilder instead of the non-debuggable System.Reflection.Emit.DynamicMethod).


h3. Debugging a single RubySpec example

The recommended way to run RubySpec with mspec ci spawns a new process for mspec-run to run the actual specs. This allows the mspec infrastructure to be run under a stable Ruby implementation like MRI, while the rubyspec in question is executed by the implementation under development like IronRuby.

The spawning of a separate process means that a the mspec-run command-line needs to be directly specified to lanuch the rubyspec under Visual Studio. This also requires the RUBY_EXE environment variable to be set as mspec-run needs it.

SET RUBY_EXE=c:\path\to\Merlin\Main\bin\Debug\ir.exe

If you are running ir.exe with options e.g. -X:Interpret, you also need to set another variable:

 SET RUBY_FLAGS="-options"

Test whether mspec-run is going to work directly from the command line.

 c:\path\to\Merlin\Main\bin\Debug\ir.exe c:\path\to\Merlin\External\Languages\IronRuby\mspec\mspec\bin\mspec-run -e "correctly resizes the Array" core\array\append

If all is well, you will get a usage message from mspec. If not then you will get a message saying that it could not find a suitable ruby executable. You can now start Visual Studio from the same command line so that the RUBY_EXE environment variable is available to the mspec-run process that Visual Studio will launch.

 devenv

Finally set up VS to run the mspec-run command as follows:

“Command line arguments” should be set to the following for running the “correctly resizes the Array” example of core\array\append:

-D c:\path\to\Merlin\External\Languages\IronRuby\mspec\mspec\bin\mspec-run -e “correctly resizes the Array” core\array\append

Hitting F5 should now run the single RubySpec example under VS.

Attaching to a running process

It is also possible to pause the execution a running app by modifying its code (with a call to “gets” for example, or by using ir.exe interactively) and then attaching the VS debugger to the spawned rubyspec process. This is sometimes quicker than trying to launch the app from inside Visual Studio

Pair debugging with experienced IronRuby developers

Some experienced IronRuby developers may be available to debug a problem with you. Watching over their shoulder can help a newcomer to the code base learn debugging tips and techniques. To make this a fruitful exercise, please follow the following guidelines:

  • Send email to [email protected] asking if any experienced developer is available to help you
  • Ensure that you can build and successfully run all of the RubySpec tests.
  • Restrict the problems to pure Ruby code which is known to work with MRI. Ensuring a clean working baseline functionality in MRI ensures that the problem truly in IronRuby. Without a known clean MRI baseline, the problem can be in a component other than IronRuby which you are as well-equipped to diagnose as anyone else.
  • Set up a clean repro. Spend time ensuring that it is not a configuration issue, and that the problem can be easily reproduced on other machines. Document detailed information about your platform, version of IronRuby, and the steps to repro the problem.
  • Do basic debugging by yourself beforehand. This will ensure that you get the most out of the session and can keep up with what’s going on over Live Meeting.
  • Set up Live Meeting on your machine, which will allow you to watch the debugging session.
  • The Live Meeting invite will be sent by email just before the scheduled hour.
  • The email invite will also contain a toll-free number to dial in to. If you cannot call in, add the experienced developer as a friend/buddy in some Chat program so that you can ask questions during the debugging session.
Clone this wiki locally