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
Ctrl-C crashes guard #842
Comments
I am also experiencing this on 2.2.5. |
I am also experiencing this (effectively same stack trace), but using Ruby If I run Guard via Full Ruby and Readline versions:
After the Pry prompt errors out, I get terminal corruption similar to what is described here: If I manually install the
|
Getting exactly the same issue here... as @WilHall suggests, outside bundler is fine.
My Readline version is |
It looks like a combination of a few things. I'll likely create a "quickfix" branch and later work out how to integrate it. |
Ok, I creates a branch with some hacks: https://github.com/guard/guard/tree/experimental_fixes Here's how to use in in a gem 'guard', github: 'guard/guard', branch: 'experimental_fixes' Then bundle update and Also, you may want to try disabling notifications to see if that helps also:
Please report problems as well as fixes. Some issues this should fix:
Some regressions/issues:
Other workarounds: If you're desperate, you can try using Guard without Pry and without notifications:
Let me know if this helps or has other issues, so I can work towards officially fixing and releasing. Feel free to submit PRs that selectively use any of these fixes (though tests would be good). |
I've pushed some tweaks. You can pull those changes (or UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off It will also log the errors into |
Thanks @e2, unfortunately I haven't had much luck:
I often get one of the following exceptions now when quitting with Ctrl-D, perhaps a race condition:
And
The
|
Thanks @Odaeus for checking this out. First, I screwed up the non-pry interactor. (I just pushed a commit, to fix this). Second, you ran into this rb-inotify bug: guard/rb-inotify#59 For which I created a fix (not merged or released yet). Until then, you use this in your gem 'rb-inotify', github: 'e2/rb-inotify', branch: 'e2-fix_ioerror_when_closed' That will solve problem 2. For problem 3 - that's probably a work in progress, but make sure you have in your UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off And you can use I'm worried the whole Pry session handling would have to be redesigned to fix this properly. That'll probably take a whole Saturday to work out :( If I have anymore patches I'll let everyone here know ASAP. |
Ok, this should work (as far as I can tell): In your gem "guard", github: "guard/guard",
branch: "experimental_fixes", ref: "c6ab8a0"
gem "listen", require: false, github: "guard/listen",
branch: "advanced_thread_debugging", ref: "31053de"
gem "guard-rspec", require: false, github: "guard/guard-rspec",
branch: "ctrl_c_workaround", ref: "ee0b21d"
gem "rb-inotify", require: false, github: "e2/rb-inotify",
branch: "e2-fix_ioerror_when_closed", ref: "99d2101" It's quite a bit of patches - feel free to review, comment and send PRs to help me test and get these patches released as quickly as possible. Thanks! |
@e2 This behavior is much better, you can see where I hit ctrl-c, it drops back to the command prompt but the process is in the middle of exiting. It raises an exception at the end, and it seems to be coming out of the lumberjack, but the specs do stop running. Thank you for look at this. Hope this helps!
|
@jetheredge - thanks for testing this. I won't have time to look into this too soon :( I'm glad it's more usable though. Based on your example, RSpec should just stop and Guard should get back to the Pry prompt. I think the problem here is that Guard traps the INT signal. It shouldn't. It should be only used to kill Pry, but it shouldn't do anything if Pry isn't running (and there are no jobs). I'd accept a PR for this if someone wants to test. (Basically, the "Guard Pry job: no thread, interrupting Guard" shouldn't be happening - the interrupt should just be ignored in the PryWrapper). |
@e2 thanks! I'll take a look at creating a PR next week. |
@jetheredge - I think it's enough to replace this line: https://github.com/guard/guard/blob/c6ab8a0/lib/guard/jobs/pry_wrapper.rb#L108 with just a "return". Also, Ctrl-C shouldn't exit guard anyway. |
@e2 - Thanks for the guidance, this week has been unexpectedly busy, I'll create a PR soon. |
We all are, trust me ;) (If you don't believe me, checkout out the list of issues in Guard - On Thu, Aug 11, 2016 at 04:10:08AM -0700, Justin Etheredge wrote:
|
I apologize, I still have not forgotten about this, it is on my list I've just gotten buried lately. I'm still planning on doing this, it is just taking longer than expected. |
I'm buried too. Hopefully I'll get the patches completed and released. |
I'm not sure if related, but when I CTRL-C during RSpec I fall back into pry, but guard will never run anything again. I haven't tried debugging it very much. Behavior is the same with and without bundle exec. I tried running with the branches you specified above and it did make a difference where my guard would exit after stopping RSpec. Any idea? Is it related to this? I'm happy to dig into internals if you don't have an immediate idea about this. We have a lot of slow specs and being able to stop a spec mid-way would save a lot of time. :) |
I'm also having this issue on MacOs Sierra. When I cancel a test, next changes on file doesn't run tests. It stops watching. |
I'm having the same issue. Any updates on this? |
Same problem here. Using macOS Catalina. |
Whenever I try to cancel running tests (with guard-rspec plugin) the guard shell crashes and the tests continue. I can reproduce simply by opening guard and pressing ctrl-c. Full debug session output and diagnostic info below. It might be related to ruby version as it works fine on 2.3.0 but not 2.3.1.
As far as I can tell my Ruby 2.3.1 is compiled with Readline support:
Unfortunately I'm not sure what the next steps are to debug this.
The text was updated successfully, but these errors were encountered: