byebug: Byebug doesn't play nice with bootsnap

Problem description

Byebug works fine the first time I add a debugger statement, but then when any other code is changed, the next time the breakpoint is hit, it seems to stop in some internal rails/other gem code. The issue is only alleviated by restarting the server, which can become time consuming when trying to debug an issue.

Expected behavior

The breakpoint should be retained even after code is changed.

Actual behavior

The breakpoint works fine the first time, but as soon as code is changed and the breakpoint is hit again, it seems to stop in internal rails code.

Steps to reproduce the problem

Simple example in HomeController:

class HomeController < ApplicationController
  before_action :redirect_signed_in_user, only: :welcome

  def welcome; end

  def redirect_signed_in_user
    debugger
    redirect_to root_url if user_signed_in?
  end
end

Works as expected

[20, 29] in /Users/ashwinhegde/code/apps/o3_crm/app/controllers/home_controller.rb
   20:
   21:   private
   22:
   23:   def redirect_signed_in_user
   24:     debugger
=> 25:     redirect_to root_url if user_signed_in?
   26:   end
   27:

Change some code, any code. Next time the breakpoint is hit - some internal devise code:

[117, 126] in /Users/ashwinhegde/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/devise-4.4.3/lib/devise/controllers/helpers.rb
   117:             opts[:scope] = :#{mapping}
   118:             warden.authenticate!(opts) if !devise_controller? || opts.delete(:force)
   119:           end
   120:
   121:           def #{mapping}_signed_in?
=> 122:             !!current_#{mapping}
   123:           end
   124:
   125:           def current_#{mapping}
   126:             @current_#{mapping} ||= warden.authenticate(scope: :#{mapping})
(byebug)

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 24
  • Comments: 30 (11 by maintainers)

Most upvoted comments

I can confirm that installing ruby 2.5.3 or suggested configuration did not solve the problem for me. Only solution was to remove bootsnap

This is caused by this bug https://bugs.ruby-lang.org/issues/14702. I asked Koichi if this is a bug that can be fixed and the next 2.5 release and he said he’d work on it. I’m also investigating it myself to see if I can help him with a patch.

Guys,

This patch was resolved in Ruby 2.5.3. The solution for this issue is to upgrade the Ruby version in projects. 👍

Also for reference: https://github.com/ruby/ruby/commit/c1034574aa7e6f47843b5533411c75d8196b29d8

Issue has already been fixed in ruby-core, and it’ll be backported to ruby 2.5!

byebug was landing me inside a random method (include? from lib/ruby/2.4.0/set.rb). I’m using Ruby 2.4.3, byebug 10.0.2, bootsnap 1.3.1.

First, I tried deleting the bootsnap cache (rm -rf tmp/cache/bootsnap-*) and stopping spring, but that didn’t fix the issue. I also tried calling Bootsnap.setup with compile_cache_iseq: false, but that didn’t work either. Commenting out all the call to Bootsnap.setup fixed it. And setting all the bootsnap options to false also fixed it. So after some trial-and-error, I figured out that the problem is with the disable_trace option. This works for me:

  Bootsnap.setup(
    cache_dir:            'tmp/cache',
    development_mode:     true,
    load_path_cache:      true,
    autoload_paths_cache: true,
    disable_trace:        false,
    compile_cache_iseq:   true,
    compile_cache_yaml:   true
  )

I also found this relevant issue on the bootsnap repo.

Thanks @deivid-rodriguez. I will try this and let you know if I run into more trouble.

@hashwin Are you using bootsnap by any chance? I think byebug does not play nice with bootsnap.

tried ruby 2.5.5 and still the same issue

Thanks for the notice @pedrofurtado!