Cider: Verbleibende JVM nach dem Beenden

Erstellt am 20. Okt. 2013  ·  26Kommentare  ·  Quelle: clojure-emacs/cider

Immer wenn ich Emacs beende oder nrepl-quit ausführe, bleibt ein verwaister JVM-Prozess übrig.

Im Anhang sollte ein Bild angezeigt werden, das den Emacs-Prozessbaum nach dem Ausführen von nrepl-jack-in zeigt.

Ich habe auch mit CIDER 20131018.1553 von einer frischen .emacs.d mit nur Cider / Clojure-Modus getestet und hatte das gleiche Problem.

nrepl-jvm-bug

bug help wanted

Hilfreichster Kommentar

Ich verstehe nicht wirklich, warum dieses Problem geschlossen wurde. Es ist ein großes Problem, und es wird in Emacs 24.5 für Windows nicht gelöst.

Ich verwende diese Problemumgehung derzeit in .emacs

(defun my-kill-java ()
  (interactive)
  (cider-interactive-eval "(System/exit 0)")
  )

(defun turn-on-my-clojure-commands ()
   :
    (define-key clojure-mode-map (kbd "C-c q") 'my-kill-java)

  )

(add-hook 'clojure-mode-hook 'turn-on-my-clojure-commands)

Alle 26 Kommentare

Ich werde das Problem untersuchen. Könnte jedoch etwas mit Windows zu tun haben - da ich nicht glaube, dass ich verwaiste Prozesse unter OSX und Linux gesehen habe.

Dies muss etwas Windows-spezifisches sein, da ich es unter OSX nicht reproduzieren kann.

Gerne helfe ich Ihnen beim Debuggen des Problems, wenn Sie keine Windows-Installation zur Hand haben.

Es ist wahrscheinlich erwähnenswert, dass ich dieses Problem mit keinem anderen Programm bekomme, das eine Kopie der JVM erzeugt. Zum Beispiel erzeugt Leiningen dieselbe Prozessstruktur, aber beide java.exe-Prozesse werden beim Beenden beendet.

Sie sollten debuggen, was in cider--close-buffer passiert, wenn der Verbindungspuffer übergeben wird. Sie können diese Funktion mit C-u C-M-x instrumentieren und einfach cider-quit aufrufen. delete-process sollte normalerweise den zugrunde liegenden Java-Prozess beenden, aber aus irgendeinem Grund scheint dies unter Windows nicht der Fall zu sein.

Ich bin mit nrepl.el / CIDER oder elisp nicht vertraut genug, um zu wissen, wonach ich suchen sollte.

Es scheint, dass der übergeordnete java.exe-Prozess getötet wird, nur nicht das Kind aus irgendeinem Grund.

@drguildo Könnte dann ein Emacs-Fehler sein, da delete-process eine Kernfunktion von Emacs ist. Weitere Informationen hierzu erhalten Sie möglicherweise, wenn Sie eine Frage in die emacs-devel-Mailingliste aufnehmen.

Ich habe einen Emacs-Fehler gemeldet und dies war, was einer der Entwickler zu sagen hatte:

Emacs unter Windows kann nur seine unmittelbaren Unterprozesse überwachen und beenden, es kann keinen ihrer Nachkommenprozesse überwachen, geschweige denn töten, weil es keine Ahnung von ihnen hat. Und das Betriebssystem beendet nicht automatisch alle Prozesse im Subprozessbaum, und es gibt keine Möglichkeit, ein Signal an alle zu senden, wie auf Posix-Plattformen. Wenn das Beenden des unmittelbaren Kinderprozesses nicht dazu führt, dass einige seiner Kinder aussteigen oder abbrechen, bleiben diese Enkelkinder verwaist.

Warum wird die untergeordnete Datei java.exe nicht beendet, wenn die übergeordnete Datei dies tut? Können Sie dafür sorgen, dass das passiert? Andernfalls glaube ich nicht, dass es eine Lösung für dieses Problem gibt, sorry.

Ich lag also richtig, als ich annahm, dass es sich um einen Windows-bezogenen "Fehler" handelt. Da ich kein Windows verwende, weiß ich derzeit nicht, was wir tun können. Ich denke, wir brauchen eine explizite Verfolgung der Prozesse dort, aber jemand anderes muss sie implementieren.

Wenn ich in der REPL (System / exit 0) ausführe, werden alle Java-Prozesse beendet. Wäre es möglich, dies oder etwas Ähnliches in Cider--close-buffer zu tun?

Ich denke wir können. Ich frage mich, ob es noch einfachere Lösungen für dieses Problem gibt.

IMHO unter der Annahme, dass das Betriebssystem einen untergeordneten Prozess beendet, wenn wir beenden, ist nicht einfach, es ist schlampig. Ich stimme dafür, eine eigene VM beim Herunterfahren des Hosts explizit herunterzufahren und alles, was über Jack-In erstellt wurde, als Eigentum zu betrachten.

@noisesmith Vielleicht hast du recht. Auf der anderen Seite kann ich mich nicht erinnern, jemals jemanden gesehen zu haben, der explizit untergeordnete Elemente verfolgt, die in Emacs Lisp-Code verarbeitet wurden. Ich werde das prüfen.

@drguildo Ein Freund von mir (der ein verrückter Windows-Hacker ist) hat diese Behauptung auf emacs-devel überprüft und einen Patch erstellt, der sie entlarvt - siehe den Patch, den er hier bereitgestellt

Ich habe hier eigentlich kein Fachwissen, aber ich möchte Links zu einigen Problemen hinzufügen, die ich gesehen habe und die möglicherweise relevant sind. Es gibt ein ähnliches Problem mit verwaisten JVMs in Gorilla REPL unter Windows:

https://github.com/JonyEpsilon/lein-gorilla/issues/4

@jtcb hat ein bisschen Annahme , dass es sich um ein Leiningen-Problem handelt:

https://github.com/technomancy/leiningen/issues/1614

Wir schließen dies, da wir nicht viel dagegen tun können.

Ich verstehe nicht wirklich, warum dieses Problem geschlossen wurde. Es ist ein großes Problem, und es wird in Emacs 24.5 für Windows nicht gelöst.

Ich verwende diese Problemumgehung derzeit in .emacs

(defun my-kill-java ()
  (interactive)
  (cider-interactive-eval "(System/exit 0)")
  )

(defun turn-on-my-clojure-commands ()
   :
    (define-key clojure-mode-map (kbd "C-c q") 'my-kill-java)

  )

(add-hook 'clojure-mode-hook 'turn-on-my-clojure-commands)

Es ist geschlossen, weil es kein Cidre-Problem ist, sondern ein Emacs-Problem (oder Lein-Problem).

Ok, aber vielleicht sollten wir den Benutzern zumindest eine Problemumgehung mitteilen? Die hängenden Java-Prozesse töten die Maschine, und ein generischer Befehl wie "pskill java" tötet auch Datenbanken wie datomic und cassandra.

Wie setze ich den Befehl auch für die Repl, dh wie heißt die Clojure-Repl-Mode-Map?

Ok, aber vielleicht sollten wir den Benutzern zumindest eine Problemumgehung mitteilen? Die hängenden Java-Prozesse töten die Maschine, und ein generischer Befehl wie "pskill java" tötet auch Datenbanken wie datomic und cassandra.

Normalerweise würde ich einfach alle Java-Prozesse untersuchen und die relevanten beenden. Da Repl-Neustarts ungewöhnlich sind, denke ich nicht, dass dies sowieso ein großes Problem ist.

Wie setze ich den Befehl auch für die Repl, dh wie heißt die Clojure-Repl-Mode-Map?

cider-repl-mode-map .

Ich denke, dass (Shutdown-Agents) das JVM unter Windows von selbst beenden lässt. Ich denke, es ist die Windows-JVM, die einen Nicht-Server-Thread startet, der dann den normalen Exit blockiert. Ich wünschte, ich könnte mich daran erinnern, in welchem ​​Projekt ich diese Informationen gelesen habe (vielleicht Nightcode, vielleicht Ring-Steg, nicht sicher).

Ich habe es gelöst, indem ich (System / exit 0) aus der Antwort heraus aufgerufen habe.

Ich habe .emacs einen Befehl hinzugefügt

(defun my-kill-java ()
  (interactive)
  (cider-interactive-eval "(System/exit 0)")
  )
 (define-key cider-repl-mode-map (kbd "C-c C-q") 'my-kill-java)

Wenn ich nur (shutdown-agents) aufrufe, findet pskill immer noch zwei zu tötende Java-Prozesse. Dies passiert nicht, wenn ich benutze (System / Exit 0)

Ich habe ein bisschen mit dem Code rumgespielt. Die oben genannten Lösungen verwenden Cider-Interactive-Eval-Block und hinterlassen manchmal verwaiste Cidre-Interaktionspuffer. Der folgende Code hat mein Repl-Shutdown sehr zuverlässig gemacht:

(defun my-kill-java ()
  (interactive)
  (cider-nrepl-send-unhandled-request
   (list "op" "eval"
         "code" "(do 
                   (.start 
                     (Thread. 
                       (fn [] 
                         (Thread/sleep 5000)
                         (shutdown-agents)
                         (System/exit 0)))) 
                  nil)"))
  (cider-quit 'QUIT-ALL))

Angeblich hat @benedekfazekas dies kürzlich mit https://github.com/benedekfazekas/cider/commit/7cd9c7032f6c65869d5a1ba1e4292f4375585cf2 behoben

Ich habe das gesehen, aber nicht daran gedacht, es zu testen. Ich werde testen und bestätigen. Vielen Dank!

Der Fix sieht für mich gut aus. Alle Fälle, in denen früher ein VM ausgeführt wurde, sind jetzt nicht mehr vorhanden.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen