New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Byebug doesn't play nice with bootsnap #452
Comments
Thanks for the report, I've started seeing the same thing recently too... And I have no idea why. It seems like a regression to me. Can you try |
@hashwin Are you using |
@deivid-rodriguez Yes! Removing it seems to resolve the issue. Thank you so much for tracking this down! |
@hashwin The following setup in require 'bootsnap'
env = ENV['RAILS_ENV'] || 'development'
Bootsnap.setup(
cache_dir: 'tmp/cache',
development_mode: env == 'development',
load_path_cache: true,
autoload_paths_cache: true,
disable_trace: true,
compile_cache_iseq: false,
compile_cache_yaml: true
) I definitely need to at least document this, so I'll reopen this issue and use it as a reminder. |
Thanks @deivid-rodriguez. I will try this and let you know if I run into more trouble. |
Bootsnap use I guess I think this is why the example on #452 (comment) work correctly. |
I have the same issue on an older version of rails where bootsnap was integrated. It uses the same configuration as recommended above and it still breaks in a different spot than where the byebug statement is. If I strictly use If there's anything I can do to help this issue being fixed (diagnosis, etc), let me know! EDIT: from my Gemfile:
There's no other pry plugin. |
Does it get fixed if you remove |
If I remove That's my workaround for now - skip Bootsnap.setup if a environment variable is defined. Not ideal, but it works. I'm sure other folks will hit that shortly. |
I honestly have no idea why the custom bootsnap configuration is not working for you. I recommend that you put together some reproduction steps for your problems since the workaround seems to work for other people. By the way, in case someone wants to help here, it might be worth exploring what |
Oh, we're loading an old version of debase as well for interactive debugging from IDEs. I'll see if bumping its version helps. |
Actually, looking at the change in debase, it's perhaps due to the fact that ruby is used is still at 2.3? In mean, the custom bootsnap configuration might be working for 2.5 and later only? |
Maybe... The issue @tzmfreedom posted to ruby-core is 2.5 specific, not sure if that could be related. |
I'll have to put this on the backburner for now, at least I've isolated that removing Bootsnap.setup fixes it, which will do for now. Might get back to this in July. Thanks @deivid-rodriguez ! |
For me, the workaround is remove the line When the issue (cited by @tzmfreedom) in Ruby Issue Tracking System be finished, this workaround will be not necessary anymore. |
byebug was landing me inside a random method ( First, I tried deleting the bootsnap cache (
I also found this relevant issue on the bootsnap repo. |
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. |
Thanks @rafaelfranca, yeah @tzmfreedom discovered and reported this in #452 (comment). but there was no movement at all on the ticket. I should've pinged Koichi about it, but I forgot to do it, so thanks so much for helping moving this forward ❤️. |
Issue has already been fixed in ruby-core, and it'll be backported to ruby 2.5! |
Also experiencing this same issue. Glad to see there is some movement on it. |
I am also facing same issue. Really happy to see work around for this. |
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: ruby/ruby@c103457 |
Thanks for the notice @pedrofurtado! |
I'm using my whole gemfile
my current workaround is removing bootsnap from
similar issue ruby-debug/debase#66 |
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 |
same with Ruby 2.5.3 |
I think this is not fixed until 2.5.4 gets released? This seems to be the actual backport that fixed the issue https://bugs.ruby-lang.org/projects/ruby-trunk/repository/ruby_2_5/revisions/66225. Ruby 2.5.3 was released at r65273. Or am I reading this wrong? |
Yup, it sounds like we have to wait until 2.5.4. Just to confirm, ruby 2.6.1 is not affected by this, right? |
tried ruby 2.5.5 and still the same issue |
Following bootsnap readme and specifying cache folder worked for me. Byebug / Pry like most debuggers will want you to set to single thread |
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:
Works as expected
Change some code, any code.
Next time the breakpoint is hit - some internal devise code:
The text was updated successfully, but these errors were encountered: