Guard: Strg-C Crash Guard

Ich erlebe das auch am 2.2.5.

Ich erlebe dies auch (effektiv der gleiche Stack-Trace), aber mit Ruby v2.3.0 , Guard v2.13.0 .

Wenn ich Guard über bundle exec guard ausführe und dann Ctrl-C drücke, sehe ich das Problem. Wenn ich jedoch guard nicht über das Bundle ausführe, verursacht das Drücken von Ctrl-C das Problem nicht.

Vollständige Ruby- und Readline-Versionen:

$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15.5.0]

$ ruby -rreadline -e 'puts Readline::VERSION'
6.3

Nachdem die Pry-Eingabeaufforderungsfehler ausgegeben wurden, erhalte ich eine Terminalbeschädigung ähnlich der hier beschriebenen:
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

Wenn ich das Gem rb-readline manuell installiere, behebt dies das danach auftretende Korruptionsproblem, aber Ctrl-C liefert den gleichen Stacktrace. Wenn dieses Gem installiert ist, meldet Guard meine Readline-Version wie folgt:

[1] guard(main)> Readline::VERSION
=> "5.2"

Genau das gleiche Problem hier zu bekommen ... wie @WilHall vorschlägt, ist der externe Bundler in Ordnung.

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin14]
$ guard -v
Guard version 2.14.0

Meine Readline-Version ist 6.3 sowohl innerhalb der Wache als auch außerhalb.

Es sieht aus wie eine Kombination aus ein paar Dingen.

Ich werde wahrscheinlich einen "Quickfix" -Zweig erstellen und später herausfinden, wie man ihn integriert.

Ok, ich erstelle einen Branch mit einigen Hacks: https://github.com/guard/guard/tree/experimental_fixes

So verwenden Sie in einem Gemfile :

gem 'guard', github: 'guard/guard', branch: 'experimental_fixes'

Dann Bundle Update und bundle exec guard wie gewohnt.

Sie können auch versuchen, Benachrichtigungen zu deaktivieren, um zu sehen, ob dies auch hilft:

bundle exec guard -n f

Bitte melden Sie sowohl Probleme als auch Fixes.

Einige Probleme, die dies beheben sollte:

1. Pry sollte nicht mehr abstürzen, wenn man die Wache mit Strg-C . verlässt
2. Die Ausgabe nach den letzten Zeilen sollte den Shell-Prompt darunter nicht verbergen
3. Sowohl TMux- als auch TerminalTitle-Notifier scheinen Probleme mit der Ausgabe zu verursachen
4. Ich habe es nicht überprüft, aber es ist möglich, dass die LumberJack-Protokollierung die Zeitspülung verwendet, wenn dies nicht der Fall sein sollte.
5. STDERR-Stream ist nicht mehr geschlossen
6. Pry wird nicht mehr getötet und beigetreten - es wird stattdessen aufgeweckt (so sollte es angesichts der anderen Optimierungen nicht "hängen")

Einige Rückschritte/Probleme:

1. Wenn ein Wächter/eine Aufgabe die farbige Ausgabe vermasselt, wird dies nicht behoben (das Zurücksetzen der Konsole wurde deaktiviert).
2. Keine Tests dafür (ich versuche zuerst zu sehen, ob ich Probleme beheben kann)
3. Nicht auf anderen Rubinen getestet als MRT 2.3.1

Andere Problemumgehungen:

Wenn Sie verzweifelt sind, können Sie versuchen, Guard ohne Pry und ohne Benachrichtigungen zu verwenden:

bundle exec guard -n f -i

Lassen Sie mich wissen, ob dies hilft oder andere Probleme hat, damit ich auf eine offizielle Behebung und Veröffentlichung hinarbeiten kann.

Fühlen Sie sich frei, PRs einzureichen, die selektiv einen dieser Fixes verwenden (obwohl Tests gut wären).

Ich habe einige Optimierungen vorgenommen.

Sie können diese Änderungen ziehen (oder bundle update wenn Sie die obige Zeile Gemfile verwenden) und dann dies zu Ihrem Guardfile hinzufügen, um zu sehen, ob es hilft:

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

Es wird auch die Fehler in guard.log protokollieren. (Obwohl dies dazu führen kann, dass das gesamte Verzeichnis unter OSX gescannt wird).

Danke @e2 , leider hatte ich nicht viel Glück:

• Das Absturzverhalten bei Strg-C bleibt beim "experimental_features"-Zweig gleich, wenn es ohne zusätzliche Flags ausgeführt wird.
• Die Bereitstellung von -n f macht keinen Unterschied.
• Die Verwendung des Parameters -i verhindert einen Absturz beim Strg-C'ing in Tests (obwohl es schwer ist zu beenden!).

Ich bekomme jetzt oft eine der folgenden Ausnahmen beim Beenden mit Strg-D, vielleicht eine Race Condition:

19:56:17 - INFO - Bundle already up-to-date
19:56:17 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^Clog writing failed. can't modify frozen IOError
➜  joinly-app git:(master) ✗
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:69:in `stop': undefined method `destroy' for #<Guard::Jobs::Sleep:0x0056104497dd80> (NoMethodError)
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:53:in `start'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli/environments/valid.rb:16:in `start_guard'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli.rb:122:in `start'
[...]

Und

19:56:29 - INFO - Bundle already up-to-date
19:56:30 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^CE, [2016-08-01T19:56:38.584021 #10597] ERROR -- : run() in thread failed: stream closed:\n /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:271:in `read_events'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:238:in `process'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:221:in `run'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39:in `_run'
[...]

Die Zeilen Guardfile mit bundle exec guard -n f scheinen den Fehler zu verzögern. Das Drücken von Strg-C während eines Testlaufs führt immer noch dazu, dass Pry sich trennt, während der Test weiterhin in STDOUT schreibt, gemischt mit einer aktiven Eingabeaufforderung. Aber es endet genauso:

[1] guard(main)> Error: Input/output error - read
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `block in input_readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/input_lock.rb:115:in `interruptible_region'

Danke @Odaeus für das Auschecken.

Zuerst habe ich den Nicht-Hebel-Interaktor vermasselt. (Ich habe gerade einen Commit gedrückt, um dies zu beheben).

Zweitens sind Sie auf diesen rb-inotify-Fehler gestoßen: https://github.com/nex3/rb-inotify/pull/59

Für die ich einen Fix erstellt habe (noch nicht zusammengeführt oder veröffentlicht).

Bis dahin verwenden Sie dies in Ihrem Gemfile :

gem 'rb-inotify', github: 'e2/rb-inotify', branch: 'e2-fix_ioerror_when_closed'

Das löst Problem 2.

Für Problem 3 - das ist wahrscheinlich noch in Arbeit, aber stellen Sie sicher, dass Sie in Ihrem Guardfile :

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

Und Sie können tail -f guard.log für die Ausgabe in einem anderen Fenster verwenden.

Ich mache mir Sorgen, dass die gesamte Handhabung der Pry-Sitzung neu gestaltet werden müsste, um dies richtig zu beheben. Das dauert wahrscheinlich einen ganzen Samstag, um zu trainieren :(

Wenn ich weitere Patches habe, werde ich alle hier so schnell wie möglich informieren.

Ok, das sollte funktionieren (soweit ich das beurteilen kann):

In Ihrem Gemfile :

 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"

Es sind ziemlich viele Patches - zögern Sie nicht, sie zu überprüfen, zu kommentieren und PRs zu senden, damit ich diese Patches testen und so schnell wie möglich veröffentlichen kann.

Vielen Dank!

@e2 Dieses Verhalten ist viel besser, Sie können sehen, wo ich Strg-C drücke, es fällt zurück zur Eingabeaufforderung, aber der Prozess befindet sich mitten im Beenden. Es wirft am Ende eine Ausnahme auf und es scheint aus dem Holzfäller zu kommen, aber die Spezifikationen laufen nicht mehr. Danke, dass du dir das ansiehst. Hoffe das hilft!

^CGuard: INT signal, handling inside trap...                                                                                                             |  ETA: 00:02:03
Guard Pry job: handling interrupt
Guard Pry job: no thread, interrupting Guard

RSpec is shutting down and will print the summary report... Interrupt again to force quit.
Guard::RSpec: Interrupted by user. Waiting for RSpec to die...
➜  source_code git:(development) ✗  3/17 |========== 17 ==========>                                                                                                                         |  ETA: 00:02:28
Pending: (Failures listed here are expected and do not affect your suite's status)

  1) items can export items pdf export
     # Temporarily skipped with xit
     # ./spec/features/items_spec.rb:38


Top 3 slowest examples (25.2 seconds, 83.1% of total time):
  items can click export button and walk through modals
    14.92 seconds ./spec/features/items_spec.rb:26
  items appear in proper time periods
    10.28 seconds ./spec/features/items_spec.rb:51
  items can export pdf export
    0.00005 seconds ./spec/features/items_spec.rb:38

Finished in 30.33 seconds (files took 1.14 seconds to load)
3 examples, 0 failures, 1 pending

Randomized with seed 54136

Coverage report generated for RSpec to /Users/justin/dev/source_code/coverage. 1759 / 3324 LOC (52.92%) covered.

➜  source_code git:(development) ✗
10:18:10 - INFO - Inspecting Ruby code style: spec/features/items_spec.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

10:18:11 - INFO - Bye bye...
/Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close': closed stream (IOError)
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close'
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/logger.rb:140:in `close'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:51:in `execute'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:20:in `execute!'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/bin/_guard-core:11:in `<main>'

@jetheredge - danke fürs testen.

Ich werde nicht so schnell Zeit haben, mich damit zu befassen :(

Ich bin froh, dass es brauchbarer ist.

Basierend auf Ihrem Beispiel sollte RSpec einfach stoppen und Guard sollte zur Pry-Eingabeaufforderung zurückkehren.

Ich denke, das Problem hier ist, dass Guard das INT-Signal abfängt. Es sollte nicht. Es sollte nur verwendet werden, um Pry zu töten, aber es sollte nichts tun, wenn Pry nicht läuft (und es keine Jobs gibt).

Ich würde eine PR dafür akzeptieren, wenn jemand testen möchte. (Grundsätzlich sollte der "Guard Pry Job: kein Thread, unterbrechender Guard" nicht passieren - der Interrupt sollte im PryWrapper einfach ignoriert werden).

@e2 danke! Ich werde nächste Woche mal eine PR erstellen.

@jetheredge - Ich denke, es reicht aus, diese Zeile zu ersetzen:

https://github.com/guard/guard/blob/c6ab8a0/lib/guard/jobs/pry_wrapper.rb#L108

nur mit "Rückgabe".

Außerdem sollte Strg-C sowieso nicht Guard verlassen.

@e2 - Danke für die Anleitung, diese Woche war unerwartet viel los, ich werde bald eine PR erstellen.

Das sind wir alle, glaub mir ;)

(Wenn Sie mir nicht glauben, sehen Sie sich die Liste der Probleme in Guard an -
fast alle sind Funktionen).

Am Do, 11. August 2016 um 04:10:08 -0700 schrieb Justin Etheredge:

@e2 - Danke für die Anleitung, diese Woche war unerwartet viel los, ich werde bald eine PR erstellen.

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/guard/guard/issues/842#issuecomment -239132345

Ich entschuldige mich, ich habe das immer noch nicht vergessen, es steht auf meiner Liste, die ich in letzter Zeit gerade begraben habe. Ich habe noch vor, dies zu tun, es dauert nur länger als erwartet.

Ich bin auch begraben. Hoffentlich bekomme ich die Patches fertig und veröffentlicht.

Ich bin mir nicht sicher, ob das verwandt ist, aber wenn ich während RSpec STRG-C drücke, falle ich zurück, aber Wache wird nie wieder etwas ausführen. Ich habe nicht viel versucht, es zu debuggen. Das Verhalten ist mit und ohne Bundle-Exec gleich. Ich habe versucht, mit den oben angegebenen Zweigen zu laufen, und es machte einen Unterschied, wo meine Wache nach dem Stoppen von RSpec ausstieg.

Irgendeine Idee? Hängt es damit zusammen? Ich greife gerne in die Interna ein, wenn Sie nicht sofort eine Ahnung davon haben. Wir haben viele langsame Spezifikationen und die Möglichkeit, eine Spezifikation auf halbem Weg zu stoppen, würde viel Zeit sparen. :)

Ich habe dieses Problem auch auf MacOs Sierra.

Wenn ich einen Test abbreche, werden bei den nächsten Änderungen an der Datei keine Tests ausgeführt. Es hört auf zu gucken.

Ich habe das gleiche Problem. Irgendwelche Updates dazu?

Selbes Problem hier. Verwenden von macOS Catalina.