You want to finish 2 frames, but stack size is only -3

[nritholtz]

I'm currently pointing to master, specifically commit '7c8c0db25f3efe5878477449c5b9e070b41beabe'

Randomly when starting or in the middle of using byebug inside my cucumber/capybara steps, I get the error

You want to finish 2 frames, but stack size is only -3

The stack trace isn't really showing anything useful, except at some points along the way the negative number at the end of the error message, keeps increasing until the thread (test) is finished.

Unfortunately I don't have a sample app to provide, since this proprietary project. However, if necessary and I can find some time to see if I can scrape one together.

Any ideas?

[nritholtz]

Note: This occurs usually after I enter c for the first breakpoint, and the error is raised for every subsequent byebug call.

[deivid-rodriguez]

This is really weird @nritholtz . I do need a sample app, otherwise I'm totally lost here... :(

[jbrodie]

You want to finish 2 frames, but stack size is only -373
I have seen many different levels, and can probably reproduce them more then not through out a night of doing development work.

What I can tell you is Rails 4.1.6, Ruby 2.1.2-p95, let me know what sort of details will help and I will copy and paste them all in next time I get this hit.

[deivid-rodriguez]

Ok, this is definitely a regression, sorry about that. I'll fix it soon.

[jbrodie]

Let me know if you need anymore details, I am more then happy to produce when I hit the error.

Normally a restart of the server resolves it as well.

[sofibraun]

+1 same error

[deivid-rodriguez]

Guys, I'm pretty sure the offending commit is this one, but I'd like to reproduce this myself cause I think that commit is the way to go and I wouldn't like it reverted. So I'd like to properly fix this.

Does anyone have a sample app that exhibits this behavior? If not, specifying set verbose in your .byebugrc file and copying the output when you hit the error in a gist can be useful too.

[jbrodie]

I will be working on my project throughout the weekend and will more then likely hit it so I will add and post back.

[deivid-rodriguez]

👍 If you can copy paste some code context around your byebug call, that'd be great too.

[jbrodie]

Is there anyway to have the debug information sent to a separate log file? Just tested it with a debugger point and have been waiting 5 minutes for the code to continue!

[deivid-rodriguez]

No... can you use shell redirections?

[ketuls]

+1. Error stacktrace pasted here. http://pastebin.com/94kngDxc

[deivid-rodriguez]

Can someone hitting the issue try against the issue_127 branch and tell me if the bug is fixed there?

[jbrodie]

I will update to that branch when working tonight and let you know if I encounter it again.

[deivid-rodriguez]

👍

[epergo]

Hi all, I have tried your fix and I think it works, I have been suffering that bug in a concrete place inside my app and now it works like a charm. Lets see what others say about their tests.

[ketuls]

I am new to Ruby and ROR. Below are my steps,

1. I have download the code with git clone.

2. Build the gem and installed it.
   dev@ketuls ~/byebug> gem build byebug.gemspec
   Successfully built RubyGem
   Name: byebug
   Version: 4.0.3
   File: byebug-4.0.3.gem
   dev@ketuls ~/byebug> gem install byebug-4.0.3.gem
   Building native extensions. This could take a while...
   Successfully installed byebug-4.0.3
   1 gem installed

3. Added this line to gemfile of rails.
   gem 'byebug', '4.0.3', group: [:development, :test]

4. bundle install | grep 'bye'
   Using byebug 4.0.3

Hope the above is the correct way to do...When i run the application, I am still getting a bug

"/home/dev/.gem/ruby/2.1.0/gems/byebug-4.0.3/lib/byebug/attacher.rb:15:in step_out'......./home/dev/.gem/ruby/2.1.0/gems/byebug-4.0.3/lib/byebug/attacher.rb:15:inattach'......./home/dev/.gem/ruby/2.1.0/gems/byebug-4.0.3/lib/byebug/attacher.rb:26:in byebug'......./home/dev/dwb/housing.images/app/workers/similar_flats_worker.rb:13:inperform'

[epergo]

You can do the following, I guess:
gem 'byebug', :git => 'https://github.com/deivid-rodriguez/byebug.git', branch: 'issue_127'

Easier.

[deivid-rodriguez]

To try the fix, add this to your gemfile

gem 'byebug', github: 'deivid-rodriguez/byebug', branch: 'issue_127'

[ketuls]

Thanks for the cool way. Ignore my comments because i forgot to switch branch and was using code from master.

[deivid-rodriguez]

@ketuls No problem, let me know if it works for you.

[ketuls]

Yuppy . I tried around 5 times & it works fine for me.

[deivid-rodriguez]

@nritholtz @jbrodie @sofibraun Have you tried the patch? Did you find any problems?

[kamal-github]

I am using byebug 5.0.0 but still facing this issue.

[kyprifog]

I am also getting this issue. It seems to be related to the way that you exit the pry debugger, but I cannot get it to consistently reproduce. This brings down my debugging session 3 or 4 times within a single bug and is seriously slowing me down so any advice would be appreciated.

byebug (4.0.3)

[deivid-rodriguez]

@kyprifog @kamal-github If you still experience this using latest byebug master with ruby 2.2.1 or greater, I'll reopen.

[derekcannon]

RuntimeError: You want to finish 3 frames, but stack size is only 1 from /Users/derekcannon/.rvm/gems/ruby-2.2.2/gems/pry-byebug-3.1.0/lib/byebug/processors/pry_processor.rb:24:instep_out'`

I am getting this error with ruby 2.2.2p95 and bye bug 4.0.5 in a single-file Ruby project. I can reproduce this issue consistently by calling a method that hits a pry while already prying. After including pry_bugbuy and getting this error, removing the require from the .rb file is not enough. I have to uninstall the gem to get pry working normally again.

[deivid-rodriguez]

More than happy to reopen if you provide a reproduction using latest master with ruby 2.2.1.

[derekcannon]

Do you want Ruby 2.2.1 specifically? Bugbye master looks like it's at 5.0.0. But 'pry-bugbye' wants 4.0.3. Do I have this information correct?

[deivid-rodriguez]

Sorry, I meant 2.2.2. Do you actually need pry-byebug to reproduce this?

[derekcannon]

I double-checked for you. Yes, without it, the same steps I'm using to pry work fine.

[deivid-rodriguez]

Thanks. So... the repro?

[DelawareConsulting]

Any progress on this?

[deivid-rodriguez]

@YOUConsulting The issue is waiting for a reproduction. Your question make me think that you are experiencing the issue too, so it looks like the ball is in your court.

[DelawareConsulting]

@deivid-rodriguez what logs do you want? How can I help :)

[deivid-rodriguez]

I need a way to reproduce the issue myself using recent rubies. As you can imagine, I can't fix it if I can't see it happening...

[DelawareConsulting]

@deivid-rodriguez what solved the issue for me specifically is going from the following gems:
gem 'pry'
gem 'pry-byebug'
gem 'pry-stack_explorer'
gem 'pry-rails'
gem 'pry-remote'
gem 'byebug'

pry (0.10.2)
coderay (> 1.1.0)
method_source (> 0.8.1)
slop (> 3.4)
pry-byebug (3.2.0)
byebug (> 5.0)
pry (> 0.10)
pry-rails (0.3.4)
pry (>= 0.9.10)
pry-remote (0.1.8)
pry (> 0.9)
slop (~> 3.0)
pry-stack_explorer (0.4.9.2)
binding_of_caller (>= 0.7)
pry (>= 0.9.11)

Too currently the following setup:

gem 'pry-byebug', '=1.3.3'
gem 'pry-stack_explorer'
gem 'pry-rails'
gem 'pry-remote'

pry (0.10.2)
coderay (> 1.1.0)
method_source (> 0.8.1)
slop (> 3.4)
pry-byebug (1.3.3)
byebug (> 2.7)
pry (> 0.10)
pry-rails (0.3.4)
pry (>= 0.9.10)
pry-remote (0.1.8)
pry (> 0.9)
slop (~> 3.0)
pry-stack_explorer (0.4.9.2)
binding_of_caller (>= 0.7)
pry (>= 0.9.11)

Only problem is that next and step is not working yet, you can follow the progress here: http://stackoverflow.com/questions/32780971/pry-remote-not-triggered-rails-4/32818381#32818381

[deivid-rodriguez]

I'm totally lost regarding why downgrading the libraries would fix this issue. Are you sure you are posting to the right issue? I think you are refering to deivid-rodriguez/pry-byebug#33

[DelawareConsulting]

Well using the my gems described above also fixed the issue with "You want to finish 2 frames..."

[kamal-github]

Finally, had to switch to binding.pry

[luisalima]

I also had the same problem, and using the configuration proposed by @YOUConsulting in this comment also solved my issue.

[zenkalia]

i'm seeing this issue in both byebug and binding.pry using ruby 2.3.0

[deivid-rodriguez]

I'd like to help you people with this issue, but as you can imagine, if I can't see it happening, I can't fix it.

[derekcannon]

What do you mean "you people"?

[deivid-rodriguez]

Sorry about my terrible English. I mean "people still facing this issue". What do you think I meant?

[deivid-rodriguez]

@derekcannon So are you still getting the issue? I asked you for a reproduction 10 months ago and you didn't reply.

[zenkalia]

i just tried to reproduce this with a simple example and couldn't. i've
even been throwing in a bunch of classes and Tempfiles and haven't been
able to see the crash. i'd send you the original script i'm working on but
you'd need redshift and redis and a dump of cloudfront logs...

On Wed, May 25, 2016 at 1:11 AM, David Rodríguez notifications@github.com
wrote:

@derekcannon https://github.com/derekcannon So are you still getting
the issue? I asked you for a reproduction 10 months ago and you didn't
reply.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#127 (comment)

[deivid-rodriguez]

@zenkalia what ruby version are you using? Is it one of the versions recommended in the README?

[zenkalia]

@deivid-rodriguez i was seeing the issue in 2.3.0 but just upgraded to 2.3.1 and haven't seen the issue again.

[deivid-rodriguez]

@zenkalia That's weird. I'm not aware of any changes in 2.3.1 that could improve (or worsen) byebug's behaviour...

[ccutrer]

I just got it with ruby 2.3.1. Unfortunately, I'm running a huge app, so can't easily distill down to a simple test case. It seems to only happen when I'm running a Rails app under pow.cx (i.e. no pty), but works fine when I use rails server

[mahemoff]

FWIW I just saw it for the first time. It was on the console (Ruby 2.3.1, Byebug 9.0.6, using pry)
(I think it was after I removed the byebug line, then reload!, then ran it again ... though I might be dreaming about that.)

Relevant trace:

/opt/ruby/gems/2.3.0/gems/byebug-9.0.6/lib/byebug/attacher.rb:19:in 'step_out'
/opt/ruby/gems/2.3.0/gems/byebug-9.0.6/lib/byebug/attacher.rb:19:in 'attach'
/home/proj/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/byebug-9.0.6/lib/byebug/attacher.rb:30:in 'byebug'

[hovissimo]

I can reliably reproduce this issue in my regretfully large, regretfully private repo.

ruby 2.3.8p459 (2018-10-18 revision 65136) [x86_64-linux]
Rails 5.0.7.2

Reproduction is as follows,

1. Insert a byebug in some app code that will be exercised multiple times by some tests, and run said tests.
2. When byebug breaks, issue skip
3. Watch the errors roll in.

Interestingly, the stack size keeps "shrinking" to lower and lower negative numbers. It seems like some stack size counter is not being properly reset, or perhaps frames are not being accounted for as they are pushed.

Here's a redacted sample:

I can probably provide more details if you can ask for specifics. A unredacted stack trace won't be available, sorry. :(