Aptana Studio
  1. Aptana Studio
  2. APSTUD-3209

Ruby debugger stops in the wrong context when debugging Cucumber Ruby step definitions

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Medium Medium
    • Resolution: Unresolved
    • Affects Version/s: Aptana Studio 3.0.3
    • Fix Version/s: Backlog
    • Component/s: debugging, ruby
    • Labels:
    • Environment:

      Tried in 2 environments:
      1. Aptana Studio 3.0.3 plug-ins running in Eclipse platform 3.6.2, Mac OS X 10.6.8
      2. Aptana Studion 3.0.3 standalone, Windows 7 32-bit

      Description

      Steps:
      0. Setup
      a. Ruby 1.9
      b. Cucumber 1.0.2
      c. Create a Ruby project and add features/support/env.rb
      1. Create new Ruby Application debug configuration
      a. Program = /usr/local/bin/cucumber (Mac) or c:\Ruby\bin\cucumber (Windows)
      2. Set breakpoint somewhere on top of env.rb

      For example, env.rb:
      ----------------
      require 'logger'
      require 'tmpdir'
      require 'rspec/expectations'

      log = Logger.new(STDOUT)
      ----------------
      The breakpoint is set on line #5.

      3. Launch debug configuration

      Expected: Debugger stops at line env.rb:5
      Actual: Debugger stops at rb_language.rb:5

      rb_language.rb:
      -----------------
      require 'cucumber/core_ext/instance_exec'
      require 'cucumber/rb_support/rb_dsl'
      require 'cucumber/rb_support/rb_world'
      require 'cucumber/rb_support/rb_step_definition'
      require 'cucumber/rb_support/rb_hook'
      -----------------

      The thread is showing (Breakpoint at .../env.rb) correctly, but the stack below does not include env.rb as it usually does. Subsequent breakpoints, for example in a step definition also cause debugger to stop at a wrong context, for example, debugger stops at:

      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/core_ext/instance_exec.rb:15

      Interestingly, it seems to get line numbers correctly, that is it hits correct line number, but in a wring file .
      Here is the example of a stack trace in the Debug window:

      Ruby Thread - 1 (Breakpoint at /Users/DK/Projects/RAP/WorkingCopy/features/step_definitions/RAP_steps.rb:15)
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/core_ext/instance_exec.rb:15
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/core_ext/instance_exec.rb:48
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/core_ext/instance_exec.rb:36
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/rb_support/rb_step_definition.rb:62
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/step_match.rb:26
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/step_invocation.rb:59
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/step_invocation.rb:38
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:99
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:98
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/step_collection.rb:15
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:93
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:92
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/scenario.rb:41
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/background.rb:51
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/background.rb:38
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:57
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:56
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/feature.rb:41
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:20
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:19
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/features.rb:29
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/features.rb:17
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/features.rb:28
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:14
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/ast/tree_walker.rb:13
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/runtime.rb:45
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/cli/main.rb:43
      /usr/local/lib/ruby/gems/1.9.1/gems/cucumber-1.0.2/lib/cucumber/cli/main.rb:20
      /usr/local/bin/cucumber:14
      /usr/local/bin/cucumber:19

      I'm marking this as regression, because Cucumber debugging in examples above works just fine for me in my old installation of Eclipse 3.6.2, Aptana RDT 1.4.0, Ruby 1.8. Here is how stack trace looks there when it stops in the correct context:

      Ruby Thread - 1 (Breakpoint at RAP_steps.rb:15)
      /Users/DK/Projects/RAP/WorkingCopy/features/step_definitions/RAP_steps.rb:15
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/core_ext/instance_exec.rb:48
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/core_ext/instance_exec.rb:36
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/rb_support/rb_step_definition.rb:62
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/step_match.rb:26
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/step_invocation.rb:63
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/step_invocation.rb:42
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:99
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:98
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/step_collection.rb:15
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/step_collection.rb:14
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:93
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:92
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/background.rb:41
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/background.rb:51
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/background.rb:38
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:57
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:56
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/feature.rb:41
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:20
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:19
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/features.rb:29
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/features.rb:17
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/features.rb:28
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:14
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/ast/tree_walker.rb:13
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/runtime.rb:45
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/cli/main.rb:43
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/lib/cucumber/cli/main.rb:20
      /Library/Ruby/Gems/1.8/gems/cucumber-1.0.0/bin/cucumber:14
      /usr/local/bin/cucumber:19

      In RDT I was able to switch Ruby interpreters, and when I switch to Ruby 1.9 there I'm having the same problem. However, in Aptana Studio I can't, and it is a real mystery what Ruby and what Fast Debugger Aptana Studio is using. For example, I could not find this version of Fast Debugger that I see in the Eclipse console even after scanning entire hard drive:

      Fast Debugger (ruby-debug-ide 0.4.9) listens on :53168

        Activity

        Hide
        Brian Levine added a comment -

        FWIW, I believe I'm seeing a similar problem attempting to debug an RSpec example. In the Launch Config I set the program to (path_to_rspec)rspec. I can launch the RSpace example fine. However, though I've set breakpoints in my example code, the debugger actually stops in completely unrelated code in other files.

        Show
        Brian Levine added a comment - FWIW, I believe I'm seeing a similar problem attempting to debug an RSpec example. In the Launch Config I set the program to (path_to_rspec)rspec. I can launch the RSpace example fine. However, though I've set breakpoints in my example code, the debugger actually stops in completely unrelated code in other files.
        Hide
        tribalvibes added a comment -

        This is probably a more general and higher priority problem than only with Cucumber. What I see is that with ruby 1.9.2, if I set a breakpoint in any type of callback code block (as typically found in Rails) the stack and context are wrong when it hits the breakpoint. A typical simple example is responds_to in a controller:

        respond_to do |when_its|
        when_its.html

        { # set a breakpoint here }

        end

        Interestingly the line number is correct, but the stack and var context show the caller's context rather than the app code where the breakpoint is. This makes it impossible to step or inspect and makes the debugger essentially useless for this very common situation. That is why it is a higher priority. In fact I have never seen this work correctly with ruby 1.9.2 and Studio 3.

        Gems are:
        ruby-debug-base19 (0.11.25)
        ruby-debug-ide (0.4.16)

        This could well be a ruby debug issue but if there is a workaround or fix, or if in fact it is a Studio 3 issue, a fix would be appreciated.

        Show
        tribalvibes added a comment - This is probably a more general and higher priority problem than only with Cucumber. What I see is that with ruby 1.9.2, if I set a breakpoint in any type of callback code block (as typically found in Rails) the stack and context are wrong when it hits the breakpoint. A typical simple example is responds_to in a controller: respond_to do |when_its| when_its.html { # set a breakpoint here } end Interestingly the line number is correct, but the stack and var context show the caller's context rather than the app code where the breakpoint is. This makes it impossible to step or inspect and makes the debugger essentially useless for this very common situation. That is why it is a higher priority. In fact I have never seen this work correctly with ruby 1.9.2 and Studio 3. Gems are: ruby-debug-base19 (0.11.25) ruby-debug-ide (0.4.16) This could well be a ruby debug issue but if there is a workaround or fix, or if in fact it is a Studio 3 issue, a fix would be appreciated.

          People

          • Assignee:
            Chris Williams
            Reporter:
            Dmitriy Korobskiy
          • Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development