Byebug.start breaks Timeout::timeout

[jordoh]

Failing test here: https://github.com/jordoh/byebug/tree/failing_timeout_test

ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.3.0]

Test:

Byebug.start do
  Timeout::timeout(60) {}
end

Output:

Error:
TestTimeout#test_0001_call to "Timeout::timeout" after "Byebug.start" does not raise:
TypeError: no implicit conversion from nil to integer
    /Users/jordan/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/timeout.rb:57:in `block in timeout'

[deivid-rodriguez]

Hi @jordoh, thanks for the report and the test. I reverted a stupid commit that was probably causing this. Can you try version 2.7.0 and let me know if it fixes it for you?

[jordoh]

Hey @deivid-rodriguez - still seeing this on the latest in master. Updated my branch with the failing test here: https://github.com/jordoh/byebug/tree/failing_timeout_test - want a pull request?

[deivid-rodriguez]

The thing is, I did try your test and it passed... Let me give it another try and I'll get back to you!

[jordoh]

Hi deivid - I'm seeing the exception on both OS X and Linux:

[~/src/byebug (failing_timeout_test)]: ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

Is there any other environment info that would be helpful?

[Goltergaul]

I am also seeing that error on 2.7.0 and on master (ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux])

[deivid-rodriguez]

I'm sorry @jordoh and @Goltergaul, I'm not having any spare time lately to work on byebug. I'll try have a look at this by the end of this week.

[deivid-rodriguez]

I stiil can't reproduce this. I don't get a failure with none of 2.0.0, 2.1.0 or 2.1.1

@jordoh or @Goltergaul, could you please checkout branch timeout_tests, run the following line and post the output here?

bundle && bundle exec rake compile && bundle exec rake TEST=test/timeout_test.rb

Thanks!

[Goltergaul]

@deivid-rodriguez sure no problem, here is the result:

Finished in 0.002566s, 389.6949 runs/s, 0.0000 assertions/s.

  1) Error:
TestTimeout#test_0001_call to "Timeout::timeout" after "Byebug.start" does not raise:
TypeError: no implicit conversion from nil to integer
/home/goltergaul/.rbenv/versions/2.1.1/lib/ruby/2.1.0/timeout.rb:82:in `block (2 levels) in timeout'

1 runs, 0 assertions, 0 failures, 1 errors, 0 skips

Which info on my environment would help you?

[Goltergaul]

i just noticed that i get many errors if i run the whole test suite:

392 runs, 443 assertions, 26 failures, 2 errors, 4 skips

Here is the full gist: https://gist.github.com/Goltergaul/9806165

[deivid-rodriguez]

I'm aware, have a look at #39 if you want to contribute.

[Goltergaul]

ah ok i thought it might be related to this issue here. What info can i give you so that you can reproduce this?

[deivid-rodriguez]

Let me try this using rbenv (I'm using rvm) and I'll get back to you. Also post the output of gem envalthough I really have no clue on where to start here... :(

Thanks!!

[deivid-rodriguez]

Actually not necessary, the failure is reproduced in travis, which uses rvm as well...

[Goltergaul]

i'm using rbenv but here is my env anyway:

RubyGems Environment:

• RUBYGEMS VERSION: 2.2.2
• RUBY VERSION: 2.1.1 (2014-02-24 patchlevel 76) [x86_64-linux]
• INSTALLATION DIRECTORY: /home/goltergaul/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0
• RUBY EXECUTABLE: /home/goltergaul/.rbenv/versions/2.1.1/bin/ruby
• EXECUTABLE DIRECTORY: /home/goltergaul/.rbenv/versions/2.1.1/bin
• SPEC CACHE DIRECTORY: /home/goltergaul/.gem/specs
• RUBYGEMS PLATFORMS:
  • ruby
  • x86_64-linux
• GEM PATHS:
  • /home/goltergaul/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0
  • /home/goltergaul/.gem/ruby/2.1.0
• GEM CONFIGURATION:
  • :update_sources => true
  • :verbose => true
  • :backtrace => false
  • :bulk_threshold => 1000
• REMOTE SOURCES:
  • https://rubygems.org/
• SHELL PATH:
  • /home/goltergaul/.rbenv/versions/2.1.1/bin
  • /home/goltergaul/.rbenv/libexec
  • /home/goltergaul/.rbenv/plugins/ruby-build/bin
  • /home/goltergaul/android_sdk/sdk/tools
  • /home/goltergaul/android_sdk/sdk/platform-tools
  • /usr/local/texlive/2013/bin/x86_64-linux
  • /home/goltergaul/.rbenv/shims
  • /home/goltergaul/.rbenv/bin
  • /usr/local/sbin
  • /usr/local/bin
  • /usr/sbin
  • /usr/bin
  • /sbin
  • /bin
  • /usr/games
  • /usr/local/games

Thanks for looking into this :)

[zmoazeni]

@deivid-rodriguez I'm on rvm with ruby 2.1.1 and can reproduce the error on master too. I've been doing some lurking/digging on my side too to see if I can help out but I'm coming up short.

Here's my env as well:

RubyGems Environment:
  - RUBYGEMS VERSION: 2.2.2
  - RUBY VERSION: 2.1.1 (2014-02-24 patchlevel 76) [x86_64-darwin12.0]
  - INSTALLATION DIRECTORY: /Users/zmoazeni/.rvm/gems/ruby-2.1.1
  - RUBY EXECUTABLE: /Users/zmoazeni/.rvm/rubies/ruby-2.1.1/bin/ruby
  - EXECUTABLE DIRECTORY: /Users/zmoazeni/.rvm/gems/ruby-2.1.1/bin
  - SPEC CACHE DIRECTORY: /Users/zmoazeni/.gem/specs
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-12
  - GEM PATHS:
     - /Users/zmoazeni/.rvm/gems/ruby-2.1.1
     - /Users/zmoazeni/.rvm/gems/ruby-2.1.1@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /Users/zmoazeni/.rvm/gems/ruby-2.1.1/bin
     - /Users/zmoazeni/.rvm/gems/ruby-2.1.1@global/bin
     - /Users/zmoazeni/.rvm/rubies/ruby-2.1.1/bin
     - /usr/local/bin
     - /bin
     - /sbin
     - /usr/bin
     - /usr/sbin
     - /usr/local/sbin
     - /Users/zmoazeni/.cabal/bin
     - /Users/zmoazeni/bin
     - /usr/texbin
     - /Users/zmoazeni/.8/bin
     - /Users/zmoazeni/.8/bin
     - /Users/zmoazeni/.rvm/bin

[zmoazeni]

This might help narrow down the problem. I did some manual digging, and the test runs fine in v2.1.0, but began breaking in v2.2.0.

So I used git bisect and it narrowed it down to this commit 73b480b as the first time the test began failing.

[zmoazeni]

Ok, I think I found a fix to that test. Just copying in a git diff instead of a PR because I don't fully understand what's going on. Maybe someone else can pick up where I'm leaving off.

diff --git a/lib/byebug/context.rb b/lib/byebug/context.rb
index 376991b..126b918 100644
--- a/lib/byebug/context.rb
+++ b/lib/byebug/context.rb
@@ -18,6 +18,8 @@ module Byebug
       def real_stack_size
         if backtrace = Thread.current.backtrace_locations(0)
           backtrace.size
+        else
+          0
         end
       end

Apparently Thread.current.backtrace_locations(0) can return nil in some scenarios (no idea how/why). When we convert the nil to an int in C bad things happen.

TypeError: no implicit conversion from nil to integer

[deivid-rodriguez]

@zamoazeni Wow, THANKS a lot for tracking this down!! I think you diff makes total sense and I'll merge it to fix the crash but I'll also research on why a thread might return a nil backtrace. Could it be a bug in ruby?

Again, thanks because I was pretty lost in this one...

[zmoazeni]

@deivid-rodriguez I really don't know. I'm out of my depth here with this C extension code. And I've never used these methods before.

Reading the Ruby docs it is documented that it could return nil. I just don't really grok the scenario when it does. And I didn't follow the code backwards to see if returning 0 from real_stack_size would do bad things inside byebug.

I'm kinda in the "naively I think this works, but I have no clue why" mode.

[deivid-rodriguez]

I don't think returning 0 will do worse things than returning nil!

Again thanks a lot for this!!

[zmoazeni]

Awesome. Thanks for your hard work @deivid-rodriguez

[deivid-rodriguez]

😉

[Goltergaul]

@jordoh yes thats exactly where i encounter those errors. thanks for making a test! :)

[deivid-rodriguez]

Yes, thanks @jordoh. Also I'm able to reproduce the failure in my environment now. With the previous test I just couldn't!

[akostadinov]

Any workarounds to execute code while on a breakpoint? I see the "No live threads left" issue with 3.1.2

[deivid-rodriguez]

Execute code on a breakpoint should work as long as the code doesn't use threads. What is it that fails for you?

[akostadinov]

A library call, not sure what it does. I'm wondering why it is a problem though. If I insert on that place Ripl.start :binding => binding then I can execute any calls. But if I insert byebug I can't.

[deivid-rodriguez]

Not sure either, I hope to be able to have a look at this at some point. In any case, it seems that you found your workaround!

[akostadinov]

workaround - not really, it doesn't support multiline nor blocks. Pry doesn't start for some reason. I did the job anyways but would be nice to have byebug for other features as well.

[deivid-rodriguez]

Of course, feel free to help.

[danlo]

I encountered this bug; I found this similar issue in a different repo: maxdemarzi/neography#165

[charlescui]

+1

[nattfodd]

If it helps: We use Capybara (1.1.2) in ours project, and byebug causes to crash entire app with this error if you call any of Capybara methods on a breakpoint (we use Capybara in the app itself in a pair with Selenium, not in tests). Even if you just put a breakpoint somewhere, if you type 'continue' after a stop, it will crash with the error 'No live threads left' as well as when it will try to execute first forward capybara method (click_on, has_content? etc.) in the code.

We were using the same gems some time ago with a ruby 1.9.2, and since original debugger does not support ruby 2.1, we moved to Byebug and this error started to appear.

Not sure if I can provide test to describe it more, project is pretty complicated to cut the case out of it.

[deivid-rodriguez]

Thanks for the feedback, @nattfodd.

We already have a test for the issue, but any feedback is always welcome.

[deivid-rodriguez]

Not really sure how (I was just researching a bit), but I just fixed this issue! 😀

[Goltergaul]

cool, is there already a new release or should we test with the mastercode?

[nattfodd]

I confirm, bug exists no more. Waiting for a new release to use it in a project.

Thanks a lot!

[deivid-rodriguez]

No, not yet, I'm fixing one last issue and then I'll release. Test master for now!

[deivid-rodriguez]

I decided to release a bug fix version now. 3.4.1 is out!