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

Disable tracepoints after continue #160

Merged
merged 3 commits into from Oct 31, 2015

Conversation

Projects
None yet
3 participants
@k0kubun
Contributor

k0kubun commented Aug 8, 2015

Fixes #144.

I couldn't find out how to avoid SEGV in tests and what a correct fix would be. I'm just sharing my idea.
Byebug.start enables tracepoints and they are left enabled after continue. If tracepoints are enabled, it gets slow. In fact, this branch does not change things slow after continue. I want to disable them while I'm not debugging.

I think we can disable tracepoints after continue or ^D and enable them again when byebug or debugger is called. Is there any reason to keep tracepoints enabled all the time?

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Aug 8, 2015

Owner

@k0kubun Thanks! This is the same idea I shared in #144. I agree with you, there's no reason to leave them enabled.

There's two problems with the patch:

  • The obvious one: it breaks the tests.
  • We cannot disable tracepoints if there are any enabled breakpoints or catchpoints, so an extra check is needed somewhere.

Feel free to further research on those issues. Otherwise, I'll pick it up where you left it when I get to this.

Thanks again!

Owner

deivid-rodriguez commented Aug 8, 2015

@k0kubun Thanks! This is the same idea I shared in #144. I agree with you, there's no reason to leave them enabled.

There's two problems with the patch:

  • The obvious one: it breaks the tests.
  • We cannot disable tracepoints if there are any enabled breakpoints or catchpoints, so an extra check is needed somewhere.

Feel free to further research on those issues. Otherwise, I'll pick it up where you left it when I get to this.

Thanks again!

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Aug 8, 2015

Contributor

Thank you for your quick response!

there's no reason to leave them enabled.
We cannot disable tracepoints if there are any enabled breakpoints or catchpoints, so an extra check is needed somewhere.

I created this pull request to hear these points. I'll research further. Thanks.

Contributor

k0kubun commented Aug 8, 2015

Thank you for your quick response!

there's no reason to leave them enabled.
We cannot disable tracepoints if there are any enabled breakpoints or catchpoints, so an extra check is needed somewhere.

I created this pull request to hear these points. I'll research further. Thanks.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Aug 8, 2015

Owner

👍 This will be a killer speed improvement if we get it working! 😃

Owner

deivid-rodriguez commented Aug 8, 2015

👍 This will be a killer speed improvement if we get it working! 😃

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Aug 28, 2015

Owner

@k0kubun Did you have the chance to investigate further?

Owner

deivid-rodriguez commented Aug 28, 2015

@k0kubun Did you have the chance to investigate further?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Aug 28, 2015

Contributor

I strongly want this change but currently I still coudn't make time to work on this. I have will to investigate this further.

Contributor

k0kubun commented Aug 28, 2015

I strongly want this change but currently I still coudn't make time to work on this. I have will to investigate this further.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Aug 28, 2015

Owner

Thanks! We are in the same situation. :)

Owner

deivid-rodriguez commented Aug 28, 2015

Thanks! We are in the same situation. :)

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 10, 2015

Contributor

We cannot disable tracepoints if there are any enabled breakpoints or catchpoints, so an extra check is needed somewhere.

  • I understood it and fixed so in fc1eb51.

The obvious one: it breaks the tests.

  • I recognized sometimes functions registered to tracepoints were called even if
    they are disabled.
    • So I guarded the calling for disabled tracepoints in 72fff22. It protects us from SEGV.
  • It was hard to remove test failure for stopping Byebug in the case that interface input is nil.
    • But I want to continue by C-d and stopping Byebug. I fixed LocalInterface to use continue when C-d (EOF) is input. It is just a workaround but works fine. faa5894
  • If Byebug is stopped, you can't get Byebug.current_context.
    • I stubbed Byebug.stop if there are no tracepoints or catchpoints. fc1eb51
      • I added an extra test to ensure continue works without stub and it stops Byebug.

@deivid-rodriguez I managed to create working patch and make all tests passing. Are you OK to merge and release this?

Contributor

k0kubun commented Oct 10, 2015

We cannot disable tracepoints if there are any enabled breakpoints or catchpoints, so an extra check is needed somewhere.

  • I understood it and fixed so in fc1eb51.

The obvious one: it breaks the tests.

  • I recognized sometimes functions registered to tracepoints were called even if
    they are disabled.
    • So I guarded the calling for disabled tracepoints in 72fff22. It protects us from SEGV.
  • It was hard to remove test failure for stopping Byebug in the case that interface input is nil.
    • But I want to continue by C-d and stopping Byebug. I fixed LocalInterface to use continue when C-d (EOF) is input. It is just a workaround but works fine. faa5894
  • If Byebug is stopped, you can't get Byebug.current_context.
    • I stubbed Byebug.stop if there are no tracepoints or catchpoints. fc1eb51
      • I added an extra test to ensure continue works without stub and it stops Byebug.

@deivid-rodriguez I managed to create working patch and make all tests passing. Are you OK to merge and release this?

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 12, 2015

Owner

Thanks! I'll review this very soon!!

Owner

deivid-rodriguez commented Oct 12, 2015

Thanks! I'll review this very soon!!

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 13, 2015

Contributor

I confirmed that the first implementation worked well, but it seems that current implementation locks threads except current threads. With commit 72fff22, I prevented to release thread locks. Adding 6f96e54 didn't work well too.

I tried delayed stopping in 2a77361 (another branch) and released locks in cleanup(). But it looked like some threads were still locked in WEBrick.

@deivid-rodriguez Do you have any idea to release locks of all threads?

Contributor

k0kubun commented Oct 13, 2015

I confirmed that the first implementation worked well, but it seems that current implementation locks threads except current threads. With commit 72fff22, I prevented to release thread locks. Adding 6f96e54 didn't work well too.

I tried delayed stopping in 2a77361 (another branch) and released locks in cleanup(). But it looked like some threads were still locked in WEBrick.

@deivid-rodriguez Do you have any idea to release locks of all threads?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 13, 2015

Contributor

I noticed that some threads are waiting before acquire_lock() and lock after scheduled stop in 2a77361.
I'll fix this patch to avoid unexpected thread locking.

Contributor

k0kubun commented Oct 13, 2015

I noticed that some threads are waiting before acquire_lock() and lock after scheduled stop in 2a77361.
I'll fix this patch to avoid unexpected thread locking.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 13, 2015

Owner

Thanks for your hard work!

Owner

deivid-rodriguez commented Oct 13, 2015

Thanks for your hard work!

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 14, 2015

Contributor

I found a safe way to unlock all threads after Byebug.stop. k0kubun@0696f94
I confirmed that this patch works with my rails app and it didn't cause SEGV or deadlock.

@deivid-rodriguez Could you review this again?

Contributor

k0kubun commented Oct 14, 2015

I found a safe way to unlock all threads after Byebug.stop. k0kubun@0696f94
I confirmed that this patch works with my rails app and it didn't cause SEGV or deadlock.

@deivid-rodriguez Could you review this again?

@k0kubun k0kubun referenced this pull request Oct 14, 2015

Merged

Stop Byebug after continue #80

Show outdated Hide outdated ext/byebug/byebug.c Outdated
@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 17, 2015

Owner

@k0kubun I've started reviewing this.

I actually like the approach @os97673 took for debase in denofevil/debase@2864440, but since we already have something working here, let's get it in for now.

Owner

deivid-rodriguez commented Oct 17, 2015

@k0kubun I've started reviewing this.

I actually like the approach @os97673 took for debase in denofevil/debase@2864440, but since we already have something working here, let's get it in for now.

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 17, 2015

Contributor

I actually like the approach os97673 took for debase in denofevil/debase@2864440,

I agree with you. It looks better to me.

but since we already have something working here, let's get it in for now.

Thank you :)

For k0kubun@f2a97e8#commitcomment-13831189, I dropped stub of Byebug.stop and commited k0kubun@f843827. After researching failing tests with the situation, I've noticed that following two checks are necessary too. Thank you for your review.

  • post_mortem mode
    • And I removed ensure
  • current_context's steps
    • for interrupt

So I created Byebug.stoppable? in k0kubun@51c4239.
While travis CI for OSX seems stopping now, this patch passes AppVayor CI and I confirmed that tests were passing on my OSX and Linux machines.

Contributor

k0kubun commented Oct 17, 2015

I actually like the approach os97673 took for debase in denofevil/debase@2864440,

I agree with you. It looks better to me.

but since we already have something working here, let's get it in for now.

Thank you :)

For k0kubun@f2a97e8#commitcomment-13831189, I dropped stub of Byebug.stop and commited k0kubun@f843827. After researching failing tests with the situation, I've noticed that following two checks are necessary too. Thank you for your review.

  • post_mortem mode
    • And I removed ensure
  • current_context's steps
    • for interrupt

So I created Byebug.stoppable? in k0kubun@51c4239.
While travis CI for OSX seems stopping now, this patch passes AppVayor CI and I confirmed that tests were passing on my OSX and Linux machines.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 17, 2015

Owner

@k0kubun Bad news. I downloaded the patch and run the rake task loop_tests (which just run the tests in a loop against the different rubies supported). I found out that the tests get aborted sometimes, every 4 or 5 runs in my case. :( Can you reproduce this?

Owner

deivid-rodriguez commented Oct 17, 2015

@k0kubun Bad news. I downloaded the patch and run the rake task loop_tests (which just run the tests in a loop against the different rubies supported). I found out that the tests get aborted sometimes, every 4 or 5 runs in my case. :( Can you reproduce this?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 17, 2015

Contributor

They never fail in my Linux environment but I could reproduce random failure in my OSX environment.

It seems that https://github.com/k0kubun/byebug/blob/51c4239/test/commands/break_test.rb#L200-L205 is unstable. I'm researching the reason.

Contributor

k0kubun commented Oct 17, 2015

They never fail in my Linux environment but I could reproduce random failure in my OSX environment.

It seems that https://github.com/k0kubun/byebug/blob/51c4239/test/commands/break_test.rb#L200-L205 is unstable. I'm researching the reason.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 17, 2015

Owner

Great, thanks!

Owner

deivid-rodriguez commented Oct 17, 2015

Great, thanks!

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 19, 2015

Owner

@k0kubun While we sort out the latest problems in this PR, I've cherry-picked into master a couple of commits that are actually independent. So you can remove them from the PR.

Owner

deivid-rodriguez commented Oct 19, 2015

@k0kubun While we sort out the latest problems in this PR, I've cherry-picked into master a couple of commits that are actually independent. So you can remove them from the PR.

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 19, 2015

Contributor

While we sort out the latest problems in this PR, I've cherry-picked into master a couple of commits that are actually independent. So you can remove them from the PR.

Thank you for cherry-picking :)
I've just rebased this branch against master and force-pushed.

I continue to investigate the problem.

Contributor

k0kubun commented Oct 19, 2015

While we sort out the latest problems in this PR, I've cherry-picked into master a couple of commits that are actually independent. So you can remove them from the PR.

Thank you for cherry-picking :)
I've just rebased this branch against master and force-pushed.

I continue to investigate the problem.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 19, 2015

Owner

@k0kubun Just so you know, the current test failure in Travis is unrelated to this PR, since I've seen it happening without it. However, the other problem you are investigating does seem related.

Owner

deivid-rodriguez commented Oct 19, 2015

@k0kubun Just so you know, the current test failure in Travis is unrelated to this PR, since I've seen it happening without it. However, the other problem you are investigating does seem related.

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 19, 2015

Contributor

Yes, I'm investigating a random SEGV, which didn't happen on the last CI result.

Contributor

k0kubun commented Oct 19, 2015

Yes, I'm investigating a random SEGV, which didn't happen on the last CI result.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 19, 2015

Owner

@k0kubun If you want to make sure you get attention from ruby-core, you might want to open an issue at https://bugs.ruby-lang.org and attach you patch there (see https://bugs.ruby-lang.org/projects/ruby/wiki/HowToContribute).

Owner

deivid-rodriguez commented Oct 19, 2015

@k0kubun If you want to make sure you get attention from ruby-core, you might want to open an issue at https://bugs.ruby-lang.org and attach you patch there (see https://bugs.ruby-lang.org/projects/ruby/wiki/HowToContribute).

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 19, 2015

Contributor

Thank you. I opened an issue and attached a patch in https://bugs.ruby-lang.org/issues/11603.

Contributor

k0kubun commented Oct 19, 2015

Thank you. I opened an issue and attached a patch in https://bugs.ruby-lang.org/issues/11603.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 26, 2015

Owner

@k0kubun Just to keep the loop opened here. Does your patch to ruby-core fix the issue with the tests being aborted or does it fix a different issue?

Owner

deivid-rodriguez commented Oct 26, 2015

@k0kubun Just to keep the loop opened here. Does your patch to ruby-core fix the issue with the tests being aborted or does it fix a different issue?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 26, 2015

Contributor

My patch to ruby-core does fix the issue with the tests being aborted. I've never seen SEGV with the ruby compiled from the patch.

Contributor

k0kubun commented Oct 26, 2015

My patch to ruby-core does fix the issue with the tests being aborted. I've never seen SEGV with the ruby compiled from the patch.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 26, 2015

Owner

Yes, it does seem to fix it! I just run the tests 50 times in a row using your patch and they never segfaulted, Thanks a lot for this!

Now I'm not sure what's the best path to follow. If I merge we get the speed up in the master branch but we get an unstable build. If I wait, the build doesn't get polluted but we have to run byebug against your branch to get the speed up but

Do you mind waiting for this to be merged?

Owner

deivid-rodriguez commented Oct 26, 2015

Yes, it does seem to fix it! I just run the tests 50 times in a row using your patch and they never segfaulted, Thanks a lot for this!

Now I'm not sure what's the best path to follow. If I merge we get the speed up in the master branch but we get an unstable build. If I wait, the build doesn't get polluted but we have to run byebug against your branch to get the speed up but

Do you mind waiting for this to be merged?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

Do you mind waiting for this to be merged?

We are alreadly using this patch in our project with my fork and have nothing to be worried about.

Feel free to leave this open to keep build stable. :)

Contributor

k0kubun commented Oct 27, 2015

Do you mind waiting for this to be merged?

We are alreadly using this patch in our project with my fork and have nothing to be worried about.

Feel free to leave this open to keep build stable. :)

@brian-vogogo

This comment has been minimized.

Show comment
Hide comment
@brian-vogogo

brian-vogogo Oct 27, 2015

Still no luck. I tried a fresh rails app: https://github.com/brian-vogogo/blog. What version of ruby/rails are you using? Feel free to ignore if you think this might be quirk of my environment. Thanks!

brian-vogogo commented Oct 27, 2015

Still no luck. I tried a fresh rails app: https://github.com/brian-vogogo/blog. What version of ruby/rails are you using? Feel free to ignore if you think this might be quirk of my environment. Thanks!

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

I tried your app and it worked fine. Did you try spring stop if you are using spring?

It'd be nice to check the return value of Byebug.started? after binding.pry. If it does not return false, it will be slow (Byebug.stop is necessary).

Contributor

k0kubun commented Oct 27, 2015

I tried your app and it worked fine. Did you try spring stop if you are using spring?

It'd be nice to check the return value of Byebug.started? after binding.pry. If it does not return false, it will be slow (Byebug.stop is necessary).

@brian-vogogo

This comment has been minimized.

Show comment
Hide comment
@brian-vogogo

brian-vogogo Oct 27, 2015

No spring (commented out gem, checked with `ps aux). Updated sample app with latest ruby (2.2.3) and latest rails (4.2.4). No improvement (25ms vs 400ms).

Completed 200 OK in 23ms (Views: 22.9ms | ActiveRecord: 0.0ms)
Completed 200 OK in 27ms (Views: 26.6ms | ActiveRecord: 0.0ms)

# added binding.pry

From: /Users/brian/projects/faster-pry/blog/app/controllers/welcome_controller.rb @ line 4 WelcomeController#index:

    2: def index
    3:  binding.pry
 => 4:  puts 'hello'
    5: end

[1] pry(#<WelcomeController>)> exit
hello
  Rendered welcome/index.html.erb within layouts/application (0.9ms)
Completed 200 OK in 3312ms (Views: 414.4ms | ActiveRecord: 0.0ms)

# commented out binding.pry

Completed 200 OK in 402ms (Views: 395.1ms | ActiveRecord: 0.0ms)
Completed 200 OK in 488ms (Views: 478.7ms | ActiveRecord: 0.0ms)
Completed 200 OK in 386ms (Views: 381.4ms | ActiveRecord: 0.0ms)

brian-vogogo commented Oct 27, 2015

No spring (commented out gem, checked with `ps aux). Updated sample app with latest ruby (2.2.3) and latest rails (4.2.4). No improvement (25ms vs 400ms).

Completed 200 OK in 23ms (Views: 22.9ms | ActiveRecord: 0.0ms)
Completed 200 OK in 27ms (Views: 26.6ms | ActiveRecord: 0.0ms)

# added binding.pry

From: /Users/brian/projects/faster-pry/blog/app/controllers/welcome_controller.rb @ line 4 WelcomeController#index:

    2: def index
    3:  binding.pry
 => 4:  puts 'hello'
    5: end

[1] pry(#<WelcomeController>)> exit
hello
  Rendered welcome/index.html.erb within layouts/application (0.9ms)
Completed 200 OK in 3312ms (Views: 414.4ms | ActiveRecord: 0.0ms)

# commented out binding.pry

Completed 200 OK in 402ms (Views: 395.1ms | ActiveRecord: 0.0ms)
Completed 200 OK in 488ms (Views: 478.7ms | ActiveRecord: 0.0ms)
Completed 200 OK in 386ms (Views: 381.4ms | ActiveRecord: 0.0ms)
@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

No spring (commented out gem, checked with `ps aux). Updated sample app with latest ruby (2.2.3) and latest rails (4.2.4). No improvement (25ms vs 400ms).

Hmm.. I can't think of any possibility to reproduce the situation (except you enable some breakpoints via break command). But I'm interested in the problem because my colleague also said the same thing.

Again, could you check the return value of Byebug.started?? You can check it by

  def index
    binding.pry
    puts "hello: #{Byebug.started?}"
  end

or something. And there are two ways to exit the REPL of pry-byebug. Which way do you use, Control-D or continue? (Though I supported both situations in deivid-rodriguez/pry-byebug#80.)

Contributor

k0kubun commented Oct 27, 2015

No spring (commented out gem, checked with `ps aux). Updated sample app with latest ruby (2.2.3) and latest rails (4.2.4). No improvement (25ms vs 400ms).

Hmm.. I can't think of any possibility to reproduce the situation (except you enable some breakpoints via break command). But I'm interested in the problem because my colleague also said the same thing.

Again, could you check the return value of Byebug.started?? You can check it by

  def index
    binding.pry
    puts "hello: #{Byebug.started?}"
  end

or something. And there are two ways to exit the REPL of pry-byebug. Which way do you use, Control-D or continue? (Though I supported both situations in deivid-rodriguez/pry-byebug#80.)

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

I got it. Your log tells that you exit REPL with exit. I'll fix the patch for pry-byebug to support exit... thanks.

Contributor

k0kubun commented Oct 27, 2015

I got it. Your log tells that you exit REPL with exit. I'll fix the patch for pry-byebug to support exit... thanks.

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

@brian-vogogo I optimized pry-byebug for exit or quit too in deivid-rodriguez/pry-byebug@de89e05. Could you try the new revision of byebug-stop branch?

Contributor

k0kubun commented Oct 27, 2015

@brian-vogogo I optimized pry-byebug for exit or quit too in deivid-rodriguez/pry-byebug@de89e05. Could you try the new revision of byebug-stop branch?

@brian-vogogo

This comment has been minimized.

Show comment
Hide comment
@brian-vogogo

brian-vogogo Oct 27, 2015

Thanks!
exit is fast
quit is fast
Ctrl-D is fast
continue is slow

brian-vogogo commented Oct 27, 2015

Thanks!
exit is fast
quit is fast
Ctrl-D is fast
continue is slow

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

I'm glad to hear that. :)

continue is slow

Indeed, it was. I overlooked :breakout_nav is thrown before Byebug.stop and it isn't executed...
I fixed it. I think all of them are fast now.

Contributor

k0kubun commented Oct 27, 2015

I'm glad to hear that. :)

continue is slow

Indeed, it was. I overlooked :breakout_nav is thrown before Byebug.stop and it isn't executed...
I fixed it. I think all of them are fast now.

@brian-vogogo

This comment has been minimized.

Show comment
Hide comment
@brian-vogogo

brian-vogogo Oct 27, 2015

All are fast. Thanks so much for working on these PRs!

brian-vogogo commented Oct 27, 2015

All are fast. Thanks so much for working on these PRs!

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 27, 2015

Owner

All are fast. Thanks so much for working on these PRs!

Yes, thanks! 💚

Owner

deivid-rodriguez commented Oct 27, 2015

All are fast. Thanks so much for working on these PRs!

Yes, thanks! 💚

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 27, 2015

Owner

@k0kubun Would you mind rebasing this on top of current master so we can use the latest fixes I've added to master as well?

Owner

deivid-rodriguez commented Oct 27, 2015

@k0kubun Would you mind rebasing this on top of current master so we can use the latest fixes I've added to master as well?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 27, 2015

Contributor

Done.

Contributor

k0kubun commented Oct 27, 2015

Done.

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez
Owner

deivid-rodriguez commented Oct 28, 2015

Thanks!

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 30, 2015

Owner

@k0kubun I've changed the travis build to use your patch to Ruby so this should be ok to merge. I'm not sure whether the segfault could affect normal usage but since you've been using this with success for a while, I'm going to merge it.

Can you rebase one last time and add a CHANGELOG entry?

Owner

deivid-rodriguez commented Oct 30, 2015

@k0kubun I've changed the travis build to use your patch to Ruby so this should be ok to merge. I'm not sure whether the segfault could affect normal usage but since you've been using this with success for a while, I'm going to merge it.

Can you rebase one last time and add a CHANGELOG entry?

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 30, 2015

Contributor

I've changed the travis build to use your patch to Ruby so this should be ok to merge. I'm not sure whether the segfault could affect normal usage but since you've been using this with success for a while, I'm going to merge it.

Thanks! It's very helpful for us. We didn't see SEGV on our normal usage.

Rebased and added a CHANGELOG entry.

Contributor

k0kubun commented Oct 30, 2015

I've changed the travis build to use your patch to Ruby so this should be ok to merge. I'm not sure whether the segfault could affect normal usage but since you've been using this with success for a while, I'm going to merge it.

Thanks! It's very helpful for us. We didn't see SEGV on our normal usage.

Rebased and added a CHANGELOG entry.

deivid-rodriguez added a commit that referenced this pull request Oct 31, 2015

Merge pull request #160 from k0kubun/enable-disable-tracepoints
Disable tracepoints after continue

@deivid-rodriguez deivid-rodriguez merged commit 1749e21 into deivid-rodriguez:master Oct 31, 2015

2 checks passed

continuous-integration/appveyor AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@k0kubun k0kubun deleted the k0kubun:enable-disable-tracepoints branch Oct 31, 2015

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 31, 2015

Owner

Finally merged this, the appveyor build now segfaults sometimes but I'm happy to have both an stable travis build and a fast debugging feature on master!

I really appreciate the work you did here. Thanks a lot @k0kubun !! ❤️ 💚 💛

Owner

deivid-rodriguez commented Oct 31, 2015

Finally merged this, the appveyor build now segfaults sometimes but I'm happy to have both an stable travis build and a fast debugging feature on master!

I really appreciate the work you did here. Thanks a lot @k0kubun !! ❤️ 💚 💛

@k0kubun

This comment has been minimized.

Show comment
Hide comment
@k0kubun

k0kubun Oct 31, 2015

Contributor

It was interesting to investigate this problem for me and I'm very happy to contribute to this awesome project!
Thank you for your helpful comments too. :)

Contributor

k0kubun commented Oct 31, 2015

It was interesting to investigate this problem for me and I'm very happy to contribute to this awesome project!
Thank you for your helpful comments too. :)

@deivid-rodriguez

This comment has been minimized.

Show comment
Hide comment
@deivid-rodriguez

deivid-rodriguez Oct 31, 2015

Owner

👏 👏 👏

Owner

deivid-rodriguez commented Oct 31, 2015

👏 👏 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment