ruby-debug / debase

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Issue with stepping in VSCode with debase versions 0.2.4 and 0.2.3

mskogen opened this issue · comments

Cannot Step Through Ruby Scripts in VS Code

I've had a very strange issue occurring in VS Code the last week or so. The stepping functions in the VS Code debugger have not been working for me. I have tested this issue with several different versions of Ruby, VS Code, and the 'ruby-debug-ide' gem and it appears the issue is only fixed when I revert my debase version back to '0.2.3.beta5'.

Issues with Debase Ver. 0.2.4

When I have debase version 0.2.4 installed (latest), my VS Code debugger does not let me step through ruby scripts at all. The debugger only works up to the first breakpoint where it does pause the code run. However, when I hit 'step over' or 'step into' it skips over any other breakpoints and lines of code and completes the code run without stopping at any other lines of code.

Issues with Debase Ver. 0.2.3

When I have debase version 0.2.3 installed, my VS Code debugger stops just as 0.2.4 does, however it will only let me step through lines of code with 'puts'. As soon as it gets to a line of code which sets a variable, the rest of the code completes without stopping at any other breakpoints or lines of code. Again this happens when trying to step over code using 'step over' and 'step into' which should let you step through lines of code line-by-line.

My Workaround

It was only until I reverted back even further to the '0.2.3.beta5' version that my VS Code debugger was functioning as it should be and stepping through each line of code, line-by-line. Not sure why this has been happening or what has changed in the versions since '0.2.3.beta5' but it was an issue that has been keeping me from debugging code efficiently in VS Code.

@mskogen Could you please attach an example code snippet, so I can reproduce the problem with stepping

It isn't anything crazy, this is just a test script I was using to try and step line-by-line. This is how I was troubleshooting the debugging:

puts 4
puts 7
puts 9
puts 3
puts 9
l = 7
puts "hello"
h = 9
puts h + l

@mskogen Thats strange, in RubyMine 2019.2 with 0.2.4 everything works fine

@mskogen breakpoint on the first line and step over all lines

@ViugiNick I think the issue is with VS Code and the gem. Have you tried reproducing the issue in VS Code?

@mskogen not yet

@mskogen With ruby 2.6.3 everything works fine at least on this sample

@ViugiNick is this your ruby version?

ruby -v
ruby 2.6.3p62 (2019-04-16 revision 67580) [x64-mingw32]

Also are you running Windows 10?

@mskogen ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
running on ubuntu

@ViugiNick I wonder if this issue is only apparent on the Windows 10 ruby/VS Code configuration? Do you have an easy way to test that? If not I can try to to test on a linux VM as well and see if I can reproduce the same issue.

@mskogen Ok, I'll try to check it on Windows, but could you also test in Linux?

@ViugiNick ill try to check it out on Linux as well

I can repro the step behavior issue under VS Code 1.36.1 on OSX 10.14.5 using @mskogen 's sample program.

ruby 2.4.5p335 (2018-10-18 revision 65137) [x86_64-darwin18]
ruby-debug-ide 0.6.1
debase 0.2.4

Step behavior works properly when using debase 0.2.2 and 0.2.3.

Not only does stepping fail in 0.2.4, but if I set two breakpoints, hit the first, and hit Continue, the program skips the second breakpoint and then exits.

@ViugiNick any luck reproducing? This is a recurring problem for folks with @erichmusick-stripe's setup.

@mskogen With Ruby 2.6.4 and Debase 0.2.4, this problem is gone.

There was a bug in Ruby 2.6 where Ruby was not emitting a trace point for some return statements.

See deivid-rodriguez/byebug#550 (comment) for further context.

@jvilk-stripe thanks for pointing this out! @erichmusick-stripe @mskogen Could you check if upgrading ruby resolves the issue?

commented

I've replicated it with @mskogen's sample script above.
Arch Linux, kernel 5.2.11

$ code --version
1.37.1
$ ruby -v
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
$ gem list | grep -E '(debase|ruby-debug-ide)'
debase (0.2.3)
debase-ruby_core_source (0.10.5)
ruby-debug-ide (0.7.0)

Breakpoints work on the puts, but when trying to step over/into the assignments, the script runs until the end. debase 0.2.4 allows me to hit the first breakpoint, but subsequent breakpoints fail.

With ruby 2.6.4 and debase 0.2.4, the same issue occurs -- I can hit the first breakpoint, but that is all.

EDIT: downgrading to debase 0.2.3beta5 also resolves the issue for me.

@ViugiNick upgrading Ruby does not fix the issue

@mskogen @m-dwyer @jvilk-stripe I still can't reproduce it, but I added some more logging there: could you please uninstall 0.2.4 debase and install the version from this branch https://github.com/ViugiNick/debase/tree/logging

And attach lines with something like context->... here

When you try to replicate the issue what version of VisualStudio, Ruby, and debase are you using? Also are you trying to replicate the issue on Windows? @ViugiNick

@mskogen @m-dwyer @jvilk-stripe @erichmusick-stripe Finally reproduced and fixes. Will release a new version ASAP

You did it! Fixed on my machine now too @ViugiNick

@mskogen @m-dwyer @jvilk-stripe @erichmusick-stripe used to remove 0.2.5 and publich 0.2.4.1 instead (fix included)

Hi everybody... 0.2.5 was removed, but bundler keeps trying to fetch that version instead of 0.2.4.1 is there anything else to do other than manually restricting debase to use a gem lower than 0.2.5?

Even after removing it from the Gemfile, bundling and adding it back bundler keeps looking for 0.2.5

@amilano Maybe that's because of the Gemfile.lock?

Well, I actually removed the gem from Gemfile and bundled in order to delete it from Gemfile.lock... added it again (gem 'debase', '~> 0.2.2') and bundled. Bundler got again 0.2.5 into Gemfile.lock.

For now I restricted the gem to use versions lower to 0.2.5 like this: gem 'debase', '~> 0.2.2', '< 0.2.5'. But I was wondering if there's something else to do, or if it's only me having this issue.