Pry: Pry crashes when calling a method that doesn't exist

Created on 15 Dec 2018  路  6Comments  路  Source: pry/pry

I updated a few gems (carrierwave, fog, sdoc in particular). I'm now experiencing a weird issue if I try to execute a method that doesn't exist. Pry completely crashes every time. Here is an example:

Loading development environment (Rails 4.2.11)
[1] pry(main)> d
Traceback (most recent call last):
bin/rails: undefined method `[]' for nil:NilClass (NoMethodError)

I have never seen this issue before so I don't know where to start. I use pry-rails if that helps.

When I load the rails console using spring, I get this:

Loading development environment (Rails 4.2.11)
[1] [time_capsule][development] pry(main)> d
Traceback (most recent call last):
/Users/brandoncc/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/spring-2.0.2/lib/spring/application.rb:171:in `fork': undefined method `reject!' for nil:NilClass (NoMethodError)

Most helpful comment

Thanks for that @JoshCheek. I went back and applied my updates one at a time and it turned out to be the Ruby 2.5 upgrade that caused the problem. I don't know why I didn't find it before, but this was the exact issue and the offered solution fixed my problem. bundle update binding_of_caller fixed it perfectly.

Thanks again and happy new year!

All 6 comments

What is your pryrc? Pry and pry-rails versions?

I commented it out and still got the same error, but this is my .pryrc:

  require 'hirb'
rescue LoadError
  # Missing goodies, bummer
end

if defined? Hirb
  # Slightly dirty hack to fully support in-session Hirb.disable/enable toggling
  Hirb::View.instance_eval do
    def enable_output_method
      @output_method = true
      @old_print = Pry.config.print
      Pry.config.print = proc do |*args|
        Hirb::View.view_or_page_output(args[1]) || @old_print.call(*args)
      end
    end

    def disable_output_method
      Pry.config.print = @old_print
      @output_method = nil
    end
  end

  Hirb.enable
end

if Pry::Prompt[:rails]
  Pry.config.prompt = Pry::Prompt[:rails][:value]
end

pry 0.12.2 and pry-rails 0.3.8.

Looks like the Spring one comes from here:

https://github.com/rails/spring/blob/1f44a267a2476658af86b0bc1afb94588a36ed04/lib/spring/application.rb#L290-L307

Probably caused by some other issue, but IIRC, they shouldn't depend on having a backtrace like that. Don't remember offhand how to get an exception without a backtrace, but still, they should probably change it to if $!&.backtrace (or give the backtrace a default value of empty array, and then call set_backtrace on it).

Anyway, here's how I'd figure it out:

  • git bisect to find the commit where it breaks
  • Assuming it's not obvious from the above commit (eg b/c multiple dependencies updated at once), apply the changes one at a time from the commit that breaks it, until you figure out which change is causing the problem.
  • From there, investigate why that change causes the issue (if it's a dependency, I'd read the commits between the old and new versions, check their issues to see if anyone else reported something like that, etc)
  • If that doesn't get you anywhere, looking in the pry code, can you figure out where it explodes? (eg after it prompts you and reads in results, where is it going awry between that and the next iteration?) If you can figure that out, you can get right on top of the error and see what's going in and why that's causing an issue, which could give you a sense of where to go looking.

Oh, one other approach that could work: since you know it blows up there in the spring code, you can probably look at that exception. I'm guessing it's the other exception you see in the first code snippet, but note that you can call Exception#cause to find out if it got raised while trying to deal with some other exception:

def m
  raise 'a'
rescue
  raise 'b'
end

m rescue $!      # => #<RuntimeError: b>
          .cause # => #<RuntimeError: a>

Thanks for that @JoshCheek. I went back and applied my updates one at a time and it turned out to be the Ruby 2.5 upgrade that caused the problem. I don't know why I didn't find it before, but this was the exact issue and the offered solution fixed my problem. bundle update binding_of_caller fixed it perfectly.

Thanks again and happy new year!

Thank you @brandoncc, you saved my day! I had the exact same issue

Same here @brandoncc, thanks a lot!

Was this page helpful?
0 / 5 - 0 ratings