Hallo allerseits,

ich stehe gerade vor einem äußerst seltsamen Phänomen und kann mir überhaupt keinen Reim darauf machen. Ich hege auch keine große Hoffnung, dass das jemand anderem gelingt, aber vielleicht hat ja doch jemand hier eine Idee.

Ansonsten kann man sich daran als Kuriosität erfreuen.

Also, Ausgangssituation:

• Mac Pro 2012 mit macOS 10.14.6 samt Sicherheitsupdates (was aber schon vor den Sicherheitsupdates so)
• Mein iPhone SE (1G) mit neuestem iOS 13 ruht in einem Dock, das via USB mit dem Mac Pro verbunden ist.
• Ein stets laufendes Java-8-Programm, auf das ich leider angewiesen bin
• Viele andere laufende Programme

Seit geraumer Zeit zickt nun das Java-Programm wie folgt (Wahrscheinlichkeit steigt mit zunehmender Uptime und zunehmender Zahl laufender Programme): zunächst das Programm, aber bald darauf auch alle anderen Programme, die gesamte GUI, scheinen wie eingefroren. Allerdings stimmt das nicht ganz, denn alle 30s springt die Menüleistenuhr 30s weiter, dann stockt sie wieder für 30s. Im Moment des Springens arbeitet der Mac manchmal auch noch ein bis zwei weitere Befehle ab, die ich zwischenzeitlich versucht habe zu erteilen, z.B. das Java-Programm sofort zu beenden. Mit Glück kann ich so das Java-Programm beenden, ab da ist der gesamte Spuk sofort vorbei. Geht das nicht via GUI, muss ich es halt via ssh von einem anderen Mac aus machen.

Das ist ja alles schon kurios genug.

Jetzt kommt aber der Hammer: Neulich habe ich durch Zufall entdeckt, dass der eingefrorene Zustand sofort verschwindet, wenn ich mein iPhone aus dem Dock nehme, also von meinem Mac Pro entferne.

Wie zum Teufel kann das miteinander zusammenhängen?

Irgendjemand eine Eingebung?

Schau mal in das System Log welche Meldungen sich derzeit häufen.
Interessant wären Einträge die folgendes beinhalten "AMPDeviceDiscoveryAgent"

Was macht das Java-Programm? Soll es nur rechnen, oder etwas im Netzwerk machen? Im "Java Control Panel" lassen sich verschiedene Rechte von Java-Apps begrenzen. Möglicherweise wird dadurch der problematische Zugriff unterbunden.
Ich habe fast den Verdacht, das ist tiefergehender, aber einen Versuch ist es Wert...

Ich auch würde in der "Aktivitätsanzeige" nachsehen, welcher Prozeß hohe Last erzeugt. In der Prozeßeinstellung würde ich dazu im Menü "Darstellung" "alle Prozesse" auswählen (nicht hierarchisch sortieren) und dann im Tab "CPU" absteigend nach "% CPU" sortieren. Dann siehst Du ganz oben den Übeltäter (falls die eingefrorene GUI hohe Last eines Prozesses als Ursache hat, worauf ich tippe).

AMPDeviceDiscoveryAgent gibt’s erst ab Catalina, insofern nein.
Netzwerk. Es holt Daten aus dem Internet, und der Daten-Provider sieht nur eine Java-Implementation vor.
Ich wollte gerade mal gucken, stelle aber fest, dass das Java Control Panel (zumindest bei mir) in Mojave in den Systemeinstellungen verschwunden ist.

Ich fürchte aber ohnehin, eine Einschränkung, die möglicherweise das Problem lösen würde, würde auch die gewollte Funktion unterbinden.

Aber irgendwie glaube ich auch nicht, dass es ein Netzwerkproblem ist. Dagegen spricht meiner Einschätzung nach, dass das Problem stets erst nach einiger Zeit auftritt. Irgendetwas scheint sich zu kumulieren. Sowas ähnliches wie dass das Programm zu viele Dateideskriptoren öffnet und aufgrund eines Bugs nicht wieder schließt. Aber da kenne ich mich zu wenig aus, mit Java allzumal. (Ich könnte mal lsof laufen lassen, auf die Idee komme ich jetzt erst, wo ich das schreibe.) Aber dann wäre wieder völlig unklar, warum die Blockade endet, sobald ich das iPhone abnabele.
Naja, das geht natürlich nicht, denn als GUI-Programm reagiert die ja auch nicht mehr.

Ich habe aber via ssh von einem anderen Mac aus ps und top laufen lassen. Und da ist das seltsame Ergebnis, dass das Java-Programm in dieser Situation zwar stets am meisten CPU-Last von allen Programmen verbraucht, aber absolut betrachtet auch nicht viel, so um die 30% eines einzelnen Kerns. Zu hohe Prozessorlast ist also definitiv nicht der Grund, warum die Mac-GUI blockiert. Sehr seltsam auch, dass die Menüleistenuhr alle 30 s aktualisiert wird. Das sind nicht circa 30 s, sondern wirklich exakt 30 s.

Wenn sich der Bildschirm nicht mehr aktualisiert, SSH etc. von anderen Macs aber geht, heißt das: Window Manager hängt. Mir sind zwei Wege bekannt, wie man das erreichen kann: Mittels KEXTs oder Metal. Da Metal bei Java-App ausscheidet: Installierte die Java-App eine eigene KEXT?

Ja, das ist mir von Mavericks wohlvertraut, da hatte ich laufend damit zu kämpfen.

Aber 2 Dinge passen im jetzigen Fall nicht zu dieser Annahme:

• Wenn der Window Manager in Mavericks hing, verbrauchte er immer annähernd 100% CPU-Last. Jetzt verbraucht er, wenn das Problem auftritt, < 10%.
• Wenn der Window Manager in Mavericks hing, hing er, Punkt. Man konnte ihn nur killen, was automatisch eine Abmeldung zur Folge hatte. Jetzt lässt er (falls er der Schuldige wäre) ja alle 30s kurz eine Aktion zu, und wenn das Java-Programm beendet ist, ist alles wieder OK, ohne Abmeldung.

Und dass das Abnabeln des iPhones hilft, wird dadurch auch nicht erklärt.
Nö.

Weia

M.W. hat JAVA einen garbage collector, der nicht mehr benutzten Speicher wieder frei schaufelt, wenn der für JAVA bereit gestellte Speicher knapp wird. Dies könnte erklären, warum das Programm eine Weile laufen muß, bis der Effekt eintritt. (Wenn sich der Speicher einmal gefüllt hat, läuft der g.c. in kurzen Abständen immer wieder an.) Als ich noch mit JAVA gearbeitet habe, wurde das gesamte JAVA-System angehalten, solange der g.c. lief. Für eine Erklärung der Interdependenz mit dem iPhone wäre eine kurze Schilderung der Aufgaben, die das Gerät in Deinem Versuchsaufbau erfüllt, hilfreich.

Weia
Nope. Der Window Manager kann Idle aussehen, aber trotzdem hängen. Einfach in Metal mal paar gigantische Texturen anlegen, schon hast du es.

TOTALER Wild Guess: Das iPhone stellt, wenn ich es richtig in Erinnerung hab, eine Netzwerkschnittstelle bereit, wenn es über USB angeschlossen ist. Dein Java-Programm blockiert durch einen mir nicht bekannten Mechanismus/durch eine KEXT die IO, wenn die Netzwerkschnittstelle gefunden wird – bis nach 30 Sek ein Timeout fliegt.

In einer anderen Diskussion wurde erwähnt, dass xcode ein Java-Programm zur Kommunikation mit dem Appstore installiert (oder so; stammt wohl noch aus WebObjects-Zeiten). Und zum Appstore könnte das iPhone passen ... vage Vermutung!

PS: Mendels IO-Block klingt fundierter, glaub ich.

Das könnte eine Rolle spielen, ist ja vergleichbar aufgebrauchten Dateideskriptoren. Leider habe ich davon bezüglich Java keine detaillierteren Kenntnisse.
Du meinst Aufgaben vom iPhone? Gar keine in dem Zusammenhang. Wenn ich zuhause bin, stelle ich das iPhone zum Aufladen in sein Dock, und das ist eben an den Mac angeschlossen.

Ich habe leider kein zweites Lightning-Kabel, sonst würde ich mal ausprobieren, was passiert, wenn ich das iPhone über mehrere Tage (so lange dauert es nach einem Neustart gottseidank meist bis zum ersten Auftreten des Fehlers) gar nicht mit dem Mac verbinde.
Ah, OK. War mir nicht klar, danke für die Info!
Was anderes geht bei diesem Kuriosum ja gar nicht …
Müsste die dann nicht in den Netzwerk-Systemeinstellungen auftauchen? Da ist bei mir nix zu sehen.

Die Vermutung von Mendel finde ich sehr plausibel.

Die Aktivitätsanzeige kann vielleicht trotz blockierter GUI doch noch hilfreich sein, da Du sagtest, daß der Spuk endet, sobald Du das iPhone aus dem Dock entfernst: im Tab "CPU-Zeit" siehst Du dann, welcher Prozeß lange Prozessorzeit beansprucht hat und im Tab "Netzwerk" und "Speicher" lohnt sich vielleicht auch ein Blick, da dort kumulierte Werte stehen, die sich nach dem Ende der GUI-Blockade aktualisieren sollten.

Vielleicht ist die Java-VM an sich auch die Ursache (der IO-Probleme wie sie Mendel beschrieben hat), zumal das Java Control Panel bei Dir nicht mehr in den Systemeinstellungen geladen wird. Hast Du die alte Apple Java-VM (/System/Library/Java/JavaVirtualMachines/1.6.0.jdk) oder eine aktuellere von Oracle oder beide? Vielleicht hilft es, die Java Laufzeitumgebung neu zu installieren.

Weia
Guten Morgen,

Habe Deinen Eingangspost noch mal gelesen. Dabei ist mir aufgefallen, daß die Blockade mit JAVA beginnt und dann das System erfasst.

Es muss nicht unbedingt der Speicher sein, der dem System ausgeht. Wenn der g.c. ordentlich funktioniert, wird der Speicher immer wieder rechtzeitig bereinigt. Aber was der g.c. nicht macht: Die Freigabe der übrigen System-Resourcen, insbesondere der File Handles. JAVA legt für jeden Dateizugriff ein Objekt an und belegt damit einen dieser Handles. Wenn das Objekt nicht mehr gebraucht wird, gibt der g.c. den Speicher frei nicht aber das Handle. Dieses kann nur durch die "finalize" Methode der zugehörigen Klasse verfolgen. Wenn diese fehlt (oder aus irgend einem Grund nicht aufgerufen wird), werden im Laufe der Zeit alle Handles, die das System vorhält, aufgebraucht, und das System kommt zum stehen.

Wahrscheinlich belegt Dein Handy auch ein Handle, wenn es angeschlossen ist. Kappst Du die Verbindung, dann wird das Handle wieder frei und ein Bereinigungsprogramm, oder was auch immer, kann starten und das System läuft wieder an. (Fragt sich noch: Für wie lange)

Damit haben wir eine geschlossene Theorie: Hoffentlich folgt ihr das System. Falls Du über die Bedeutung des g.c. - insbesondere für JAVA - zu wenig weist, öffne Wikipedia, es lohnt sich.

Ich wünsche Deinen System gute Besserung und Dir einen schönen Sonntag.

Weia

Ergänzung: Die o.g. Methode wird - wenn vorhanden - vom g.c. aufgerufen und wenn dieser zum Zeitpunkt der Belegung des letzten Handles noch nicht dran ist, niemals mehr. Insbesondere dann, wenn der Speicher länger vorhält als der Vorrat an Handles. Zitat aus einem Wälzer für JAVA:

Hallo Weia,
das ist definitiv mal kurios. Und eine "nette Challenge"

Vieles hast du ja bereits untersucht / eingesetzt, mit Bitte um Verständnis falls sich etwas wiederholt, aber hier mal ein paar Schuss-ins-Blaue-Kommentare:

1)
Es ist also zu 100% reproduzierbar jedesmal mit dem eingangs beschriebenen Setup (iPhone im Dock, definierte Liste an Apps am Laufen, inkl. dem Java Programm; dann mit der Zeit stockt es, und wirklich jedes Mal beim Herausnehmen des iPhones aus dem Dock - verschwindet der eingefrorene Zustand) - soweit richtig?

2)
Passiert das auch wenn du das Dock weglässt und das iPhone direkt via Lightning-2-USB Kabel anschliesst?
Wenn sich hier schon ein unterschiedliches Verhalten herauskristallisieren sollte, hilft es sicherlich die Richtung weiter einzugrenzen.

3)
Es ging nicht eindeutig hervor aus deinem initialen Bericht, daher folgendes zur Abklärung: beim Entfernen des iPhones aus dem Dock schreibst du, dass dann der eingefrorene Zustand verschwindet. Kannst du weiterhin bestätigen, dass dann das Java Programm auch auf Anhieb wieder so funktioniert wie es soll, also ordnungsgemäss funktioniert, (wieder) Daten aus dem Internet zieht, etc.?

4)
Kannst du bestätigen, dass wenn der Mac gebootet wird, alles einfach so am Start ist wie es soll, das Java Programm läuft und wenn dabei NIEMALS das iPhone angesteckt wird, das Java Programm die ganze Zeit stabil läuft und das macOS GUI flüssig läuft?

5)
top, Aktivitätsanzeige etc. hast du ja schon am Laufen. Vielleicht ergeben sich noch Erkenntnisse, wenn du parallel dazu noch folgende Tools (packen wir mal ein Arsenal aus.. ) laufen lässt:

• KextViewr (ja, du hast bereits geschrieben, dass das Java Programm ohne KEXT ist, aber halt für den Gesamtüberblick, vielleicht ist es ja doch informativ)
• TaskExplorer
• ProcessMonitor

6)
gefühlt würde ich in der Richtung von Mendel Kucharzeck Wild Guess weiterforschen. Wenn es zu 100% reproduzierbar ist mit dem Entfernen des iPhones aus dem Dock (bitte vorher Punkt 2 abklären), erscheint seine Idee durchaus denkbar, dass es zu einer Art von Timeout-/ Ressourcen-/Deadlock Situation kommt. Das diese so heftig ausfällt, dass das ganze System lahmgelegt wird ist allerdings wirklich krass.

7)
von der Java Memory/GC Theorie würde ich eher absehen. Insbesondere wenn (4) zutreffen sollte. Es ist schon so, dass generell ein Java Programm mit ungünstigen Memory Einstellungen als auch ungünstig getuntem GC in seiner Performance schwindet bis hin zum Stillstand und letztendlich OutOfMemory Exception beispielsweise, dass dann aber ein ganzes Host OS still steht.. kann mich grad nicht erinnern so etwas mal gesehen zu haben. Allerdings weiss ich jetzt auch grad nicht mehr was wäre, wenn man einem Java Programm exzessiv hohen Anteil am Gesamt-RAM zuweisen würde, inwiefern das System sich insgesamt verhalten würde, wenn das Programm diesen entsprechend alloziiert und "braucht". Aber, bzw. grosses ABER: ich nehme an, dass du nicht am Java Programm entwickelst, demzufolge auch gar nichts mit Memory und GC Tuning was machst geschweige denn am Hut hast (haben willst ), sondern du bist ein Anwender dieses Stück Software - richtig? Dann würde ich erst Recht von der Memory Theorie absehen. Bugs kann man natürlich nicht ausschliessen, die vom Hersteller evtl. mit neueren Releases unglücklicherweise mitkamen (ah, grad nächste Frage: das Java Programm wurde aktualisiert oder ist es nachwievor eine Version, die schon länger lief bei dir?) Aber um des Memory-Willens: um den Verlauf bzw. "Verbrauch" des "Java Speichers" (bleiben wir mal bei den einfachen (auch wenn nicht technisch korrekten) Ausdrücken) zu inspizieren, gibt es Profiler Tools. Abgesehen von kommerziellen Lösungen, gibt es z.B. auch ein kostenloses Tool von Oracle: VisualVM
Es ist zu lange her, dass ich es im Einsatz hatte (dann auch nur relativ kurz) und habe auch nur rudimentär an der Oberfläche in diesem Bereich gekratzt, da GC Tuning wirklich eine Expertensparte für sich ist. Wenn ich mich richtig erinnere (aber kann da falsch liegen), einfach nach dem Java Programm starten, dann irgendwann sollte VisualVM das Java Programm "entdecken" und dann kannst du dich "ranhängen" und den "Speicherverbrauchs-Verlauf" inspizieren. Für detailliertere Bedienung, als auch insbesondere Interpretation der Ergebnisse musst du dich leider mit der Doku beschäftigen oder nach Einführungsvideos umsehen. Aber evtl. geben die grafischen Anzeigen evtl. schon eine Grundidee, insbesondere wenn die sich im Grenzbereich befinden (hohe Auslastung etc.). Für die Speicherauslastung bzw. relative Zuordnung weiss ich grad nicht, ob VisualVM die Start-Parameter von deinem Java Programm automatisch ausliest, ansonsten müsstest du zusätzlich die Config zum Java Programm noch finden. Evtl. auf Shell Ebene nach Dateien im Java Programm Pfad suchen (Stichworte: "xmx", "xms" etc. ).
Es sind letztendlich Parameter, die bei Programmstart genutzt werden können (können deshalb, weil es auch Defaults gibt, aber es wäre eher ein Zufall, glaube ich, wenn die Defaults angemessen wären für ein Software Produkt, welches mehr als ein "Hello World" ist).

p.s. aus generellem Interesse: ist das Java Programm ein Produkt, welches allgemein verfügbar ist? Wenn ja, kannst du den Link dazu mitteilen?

Ja. Die Suchbegriffe "iphone usb network interface" fördern einige Suchresultate zu Tage. Hier ein Ausschnitt, nur grob gesichtet:

• das USB Interface vom iPhone deaktivieren (vielleicht hilft das ja schon):
• IP wird zugeordnet:
• jemand mit einer ganzen Menge Einträge der Art

Zwei Präzisierungen, die die gesamte Diskussion betreffen und die ich daher nicht als einzelne Antwort irgendwo anhänge.

Folgende beiden Punkte waren offenbar nicht hinreichend präzise beschrieben:

Ein Abnabeln des iPhones führt nicht etwa dazu, dass die Java-Software selbst wieder läuft. Aber die gesamte restliche GUI geht wieder, was mir erlaubt, das Java-Programm über die GUI abzuschießen, statt mich von einem anderen Mac via ssh einloggen zu müssen. Alle anderen Programme gehen dann wieder so, wie sie sollten. Und nach einem erneuten Start geht dann auch das Java-Programm wieder wie vorgesehen (bis zum nächsten Auftreten des Problems).

Bislang kann ich nicht unterscheiden, ob es das Abnabeln des zuvor verbundenen iPhones ist, das die Blockade löst, oder schlicht die (aus dem Abnabeln resultierende) fehlende USB-Verbindung zum iPhone als solche. Das liegt daran, dass ich, wie bereits geschrieben, kein zweites Lightning-Kabel habe, mit dem ich das iPhone die Zeit, bis das Problem typischerweise zum ersten Mal auftritt (mehrere Tage bis eine Woche), gar nicht mit dem Mac verbinden und stattdessen an anderer Stelle laden könnte. (Das jetzige Lightning-Kabel ist fest verlegt.) Diese Unterscheidung scheint mir aber nach unserer jetzigen Diskussion sehr sinnvoll, insofern es die einzige ist, die ich isoliert testen kann. Ich werde mir also so ein Kabel besorgen, aber es kann gut 10 Tage oder so dauern, bis ich berichten kann, denn erstmal muss ich das Kabel haben und dann muss ich bis zu einer Woche warten, ob der Effekt auch ohne iPhone auftritt.

Ich kann ja wie gesagt via top und ps mir entsprechende Werte vom Terminal eines anderen Macs aus ansehen, nur halt nicht per GUI.

Während des Blockade-Zustands hat generell das Java-Programm die höchste CPU-Last (99% – 100%).

Nach seiner Beendigung taucht das Java-Programm aber natürlich gar nicht mehr in der GUI-Aktivitätsanzeige auf. Generell sind bei der CPU-Zeit bei mir die folgenden 4 Prozesse uneinholbar weit vorne (in dieser Reihenfolge):
WindowServer
kernel_task
lsd
sysmond

Der nächstfolgenden Prozess (launchservicesd) verbraucht dann schon nur noch ⅓ so viel CPU-Zeit.
Ist das denn sonst noch so?

Ich habe gerade mal bei mir im Finder nachgesehen, da gibt es zwar eine /Library/PreferencePanes/JavaControlPanel.prefPane, aber das ist eine Alias-Datei auf sich selbst. Das völlig Kuriose ist, dass Time Machine behauptet, das sei seit mindestens 2013 so (da beginnt mein Backup), ich aber vor gefühlt ein oder zwei Jahren diese Preference Pane definitiv noch in den Systemeinstellungen sah. In /System/Library/PreferencePanes/ hingegen war laut Time Machine die Java Preference Pane noch nie.
Nur die aktuellste von Oracle. Und da das komplette Paket und nicht nur die Laufzeitumgebung. Neuinstallation kann ich mal versuchen, aber aufgrund von Zeitmangel nicht sofort.

Es gab, seit das Problem existiert, aber jedenfalls Java-Updates, und die zumindest haben nicht geholfen. Ich nutze auch ich andere Java-Programme, und die ohne Probleme, insofern scheint das schon eher wenn, dann ein Bug in diesem spezifischen Java-Programm zu sein. Könnte aber natürlich auch sein, dass es ein Bug in der Java-VM ist, die nur in diesem einen Programm zum Tragen kommt.

Ahaaa! Das schiene meiner von Fachkenntnis ungetrübten Intuition sehr einleuchtend. Es wäre dann ein Bug in diesem speziellen Java-Programm, weswegen andere Java-Programme keine Probleme machen.

Würde auch gut zu der Beobachtung passen, dass das Problem gefühlt eher auftritt, wenn ich zusätzlich andere (Mac-)Programme mit hunderten von Dokumenten geöffnet habe.

Nur warum das Abnabeln des iPhones hilft …

Yep. Wobei sich die Beendigung des eingefrorenen Zustands nur auf die übrigen Programme bezieht, nicht auf das Java-Programm selbst, das ich dann aber natürlich problemlos killen kann.
Das (Original.Apple-)Dock leitet den Lightning-Anschluss einfach nur durch, insofern sehe ich nicht, dass das was ausmachen könnte. Ich werde jetzt erstmal (wie oben geschrieben) versuchen, was passiert, wenn ich das iPhone dauerhaft abnabele. Mit dem neuen Lightning-Kabel, das ich dazu brauche, kann ich dann ggf. auch das noch testen.
Nein, das Java-Programm selbst muss in jedem Fall gekillt werden. Der Rest funktioniert aber wieder.

De facto ist das erste, was ich tue, wenn die GUI wieder geht, das Java-Programm zu killen. Es könnte also durchaus sein, dass, täte ich das nicht, über kurz oder lang auch das gesamte System wieder einfrieren würde. Das Abnabeln des iPhones verschafft mir also zumindest genau jene Atempause, die ich brauche, um das Java-Programm zu killen.
Was passiert, wenn ich das iPhone gar nicht erst anstecke, muss ich wie gesagt noch ausprobieren und werde dann berichten. Nach einem Neustart geht jedenfalls alles so, wie es soll, für ein paar Tage.
Versuche ich bei nächster Gelegenheit zu machen. Die Tools habe ich alle.
Hmm, mir erschien gerade das plausibel. Aber wie gesagt, ich bin da nicht von Fachkenntnis beleckt.
Yep.
Insbesondere bei diesem Programm, das auf der sichtbaren GUI-Ebene jedenfalls vor Bugs nur so wimmelt.
Das Programm wird mit einer Art Stub jedes Mal, wenn ich es (bzw. den Stub) starte, komplett neu aus dem Internet geladen, ist also immer tagesaktuell.
Danke für den Tipp, da gucke ich mal. Allerdings kann ich leider auch nicht beliebig viel Zeit in dieses Problem stecken; ab irgendeinem Punkt ist das routinemäßige Neustarten die einfachere Lösung … 🙄
So halb. Das ist ein Programm für technische Aktienmarktanalyse mit dem schönen Namen thinkorswim. Ich weiß aber nicht, ob man ohne Account damit viel anfangen kann.

Das ist mal wirklich ein kurioses Problem.
Die thinkorswim FAQ schlägt für Linux Zulu OpenJDK (in den Screenshots Version 8 ) statt des "normalen" Javas vor. Das gibt es auch für den Mac .
Vielleicht wäre das auch einen Versuch wert.

In welchem Zeitintervall werden die Daten eigentlich aktualisiert?

Nominell realtime, also ich denke mal alle paar Millisekunden.

Oder falls mal auf Catalina aktualisiert wird: OpenWebStart

Wie sieht es denn mit dem Speicher der anderen Programme aus während die GUI hängt?
Ich kann nur mit folgender Beobachtung dienen: Ich hab ein Programm zum umkopieren von E-Mails. An manchen E-Mails beißt es sich die Zähne aus und der Speicherverbrauch wird enorm. Das mach den Rechner zwar sehr langsam und Eingaben reagieren kaum noch, es geht aber trotzdem weiter. Manchmal steigt aber nicht nur der Speicherbedarf des Programms sondern auch der aller anderen Prozesse, gefühlt im gleichen Maße. Dann friert das System ein und lässt sich nur durch sofortiges beenden des Programms wieder zum Leben erwecken.

Gute Frage. Leider habe ich bei top darauf nie geachtet und meist eh ps genutzt. Ich gucke das nächste Mal.

Meine 48 GB RAM scheinen jedenfalls regelmäßig aus allen Nähten zu platzen; nicht allzu lange nach einem Neustart habe ich meist schon um die 10 GB Swap. Da könnte also ein Problem liegen.
Das klingt in der Tat (vom iPhone abgesehen) sehr ähnlich wie mein Problem.

Das führt jedenfalls nicht weiter. KextViewr bestätigt, dass keine Kernel Extensions installiert sind, in TaskExplorer findet sich nichts Neues und ProcessMonitor läuft erst ab Catalina.

Java App
Hm, also die Java App muss in jedem Falle gekillt werden.
Zudem wird sie on-the-fly geupdated. Der zugrundeliegende Code wird also geupdated wann der Hersteller es will und liegt ausserhalb deiner Kontrolle. D.h., dass es nicht undenkbar ist, dass auch neue Bugs eingeschleppt werden. Man kann also nicht davon ausgehen, dass die ganze Zeit die gleiche Version geladen wird.

Insgesamt vielleicht ein Nebeneffekt mit dem "iPhone USB" (bleiben wir mal bei der Kurzbezeichnung), was sich vielleicht aufschaukelt. Spekulation noch.

Java Prozess bei 99-100%? Damit kann man schon eine Kiste zum Stehen bringen denke ich. Das ist nicht cool.

Damit würde ich nun einen "Speicherbug" in der Java App doch eher in den Kreis des möglichen einbeziehen.
Aber es handelt sich um eine Trading App. Man sollte davon ausgehen, dass insbesondere diese eigentlich gut getestet sein sollten, was zumindest die Zuverlässigkeit anbetrifft. Erst Recht, wenn ein Hersteller sich die on-the-fly Updates erlaubt, was man vielleicht auch als mutig bezeichnen könnte (je nachdem ob es mission critical ist). Da der Hersteller sich nicht erlauben kann seinen Kunden jedesmal eine Zeitbombe unterzuschieben bzw. eine Banane, die beim Kunden reifen soll, jedenfalls im Trading Business - in meiner naiven Vorstellung - wäre das ein No Go. Es hat zu funktionieren. Es wäre ein wirklich sehr unglücklicher Nebeneffekt, was sich hier vielleicht abspielt und womöglich nicht auf derem Radar ist (man hat ja nicht alle möglichen Kunden-Settings als Testumgebung zur Verfügung ).

Bin gespannt auf deine zukünftigen Erfahrungen aus einem potentiellen Dauerbetrieb ohne angestecktes iPhone.
Sollte es wieder auftreten und du ebenfalls die Java App killen musst, dann wird es immer wahrscheinlicher, dass es sich um einen App Bug handelt. (Kann man annehmen, dass die Kiste sonst nichts anderes macht bzw. nicht für Installations-Spielereien von anderen Apps etc. benutzt wird, sondern ich vermute, dass das eine ziemlich stabile (im Sinne von wenig bis keine Veränderungen am System Setup) Umgebung handelt?)

Logfile
Ich weiss nicht, wo und ob das Java App ein Logfile ablegt. Und ob das eine Einstellung ist, die man erst noch aktivieren müsste. Vielleicht mal beim Hersteller anfragen, was man für Möglichkeiten hat ein Logging einzuschalten der App, welches man temporär mal eine Zeitlang mitlaufen lassen könnte um weitere, hoffentlich hilfreiche Informationen sammeln zu können. Vielleicht kannst du ja ein Ticket bei denen aufmachen und erhälst "Debug Support", da sie auch interessiert sein dürften die App kontinuierlich zu verbessern (sollte es dort verankert sein).

Prefpane, Java Laufzeitumgebung (JRE) & Co
Das hat sich alles erledigt. Ich habe mir das .dmg bzw. was drin ist angesehen. Der Hersteller liefert die JRE mit, die Java Laufzeitumgebung (Java Runtime Environment) ist "mitgepackaged". Die App greift also auf keine anderweitig installierten Java Umgebungen zu. Damit ist es auch (nun) egal was das Thema Prefpane angeht oder welche Version von Java du mal irgendwann installiert hast. Daher auch kein Zulu installieren. Das ist die Vorgabe für Linux only.

JRE Versionen
Eine generelle Anmerkung zu Java Apps und Laufzeitumgebungen, weil hier abundzu Versionen, alte, neu, neuere, Neuinstallation usw. erwähnt wird: bei Java Apps ist dringend angeraten nur die Version und Herstellerversion (Oracle, OpenJDK, SAP VM, etc.) zu installieren bzw. zu nutzen, die der Hersteller für sein Produkt offiziell freigegeben hat ("zertifiziert"). Auch wenn es neuere Java Versionen geben mag, muss man wirklich zwingend notwendig, auch wenn sie massiv älter sein sollte, diese jene welche installieren, wenn man keine Probleme haben will. Es muss nicht zwangsläufig zu Problemen kommen mit neueren Versionen ("nicht zertifizierten"), aber in Produktion oder wie hier im Trading (würde ich mal mission critical einstufen für dich?), wo es um Transaktionen und Geld geht - auf keinen Fall von den Herstellervorgaben abweichen. Nicht nur wäre das ganze sonst ausserhalb jeglicher Haftung, sondern es kann instabil und unzuverlässig laufen. Da aber die App hier mit seiner zugehörigen JRE kommt, muss man sich keine Gedanken drum machen.

ThinkOrSwim
Zurück zur hiesigen JavaApp: während auf der Herstellerseite bei anderen Betriebssystemen durchaus eine vorherige JVM Installation angesagt ist , ist das bei der Mac Version nicht der Fall.
Die kommt gepackaged mittels dem "Install4J" Produkt (), welches man hier
und hier ran erkennen kann:

Kleine Nebeninfo:
das Install4J Produkt kommt von der Firma , die einen der bekanntesten, vielleicht beliebtesten kommerziellen Java Profiler Tools "JProfiler" baut

VM Settings
Dieser Beitrag ist ein paar Jahre alt und ich weiss nicht wer der Typ ist, aber dem Schreibstil nach scheint er ein Mitarbeiter (gewesen?) zu sein. Jedenfalls wird hier die Aussage getroffen, dass die JRE (Java Runtime Environment) im Mac Falle mit den Defaults kommt.

Ich habe mal grob einige Text-basierte Dateien von dem ThinkOrSwim App Contents angesehen und erstmal auf Anhieb keine (aktiven) Config Hinweise bzgl. VM Memory Settings gefunden. Passt eigentlich gut zusammen mit der Aussage aus dem obigen Stackoverflow Beitrag.
Aber a) kann sich vieles geändert haben, b) keine Ahnung ob der Typ wirklich von der Firma ist, c) ist das wenn zumindest erstmal nur der Vendor-Default, der aber jederzeit vom ThinkOrSwim Hersteller wiederum natürlich geändert werden kann.

Ich habe aber folgende interessante Datei gefunden:
mit Inhalt

Dazu noch dieser Artikel vom install4j Hersteller:

D.h. du kannst nachträglich noch die VM Settings anpassen. Vielleicht gibt es eine offizielle Doku, Forum, Tipps & Tricks beim ThinkOrSwim Hersteller. Grundsätzlich ist das Rumspielen an VMSettings - und gerade bei Apps in Produktion - nicht angesagt, wenn man nicht weiss was man da macht. Evtl. mal herausfinden was die Default Grösse ist, aber da man annehmen darf, dass diese Datei auch natürlich unter Kontrolle von ThinkOrSwim mit gepackaged wurde, könnte man davon ausgehen, dass -Xmx512m vermutlich bereits deren Empfehlung nach ein guter Startwert sein könnte, wenn man denn was ändern will. Es kann natürlich auch gut sein, dass diese Datei eine Standarddatei ist, die bereits vom install4j Hersteller kam und ThinkOrSwim dem weiter keine Beachtung geschenkt hat.

Natürlich darfst du jetzt nicht zu viele Variablen gleichzeitig ändern, aber beizeiten würde ich an deiner Stelle mal diese Option aktivieren. Also aus
machen.
VM Settings Änderungen greifen nach App Neustart.

Es wäre wirklich interessant zu wissen mit welchen Default VM Settings die App läuft. Unter der Annahme, dass man die Einstellung in der .vmoptions Datei als von ThinkOrSwim gesetzt (auskommentiert im Standard) ansehen sollte, müsste der Default folglicherweise niedriger sein.

Deine 48GB (oder zumindest Grossteile davon) kommen der Java App nicht zu gute. Nehmen wir mal an, dass die App mit den 512M gesetzt wird, dann wird beim Überschreiten ein OutOfMemory Exception geworfen und sie stürzt ab. Womit auch immer die 48GB ausgereizt werden, aber sicherlich nicht von der Java App.
Aufgrund der 48GB, würde ich nach dem 512M Experiment - auch gut und gerne mal 2GB der VM geben.

Folgende Testaufbauten könnten auch sinnvoll sein:

• Test Szenario 0: bisheriges Setup. Zeit messen, VisualVM Speicherverlauf monitoren bis es zum Problem kommt.
• Test Szenario 1: mehr "VM Speicher" + Rest alles beim alten: .vmoptions mit 512M + iPhone - wieder monitoren und Zeit messen bis es zum Problem wird.
• Test Szenario 2: noch mehr Speicher zuweisen + Rest gleich: .vmoptions mit -Xmx2G + iPhone - monitoren und messen.

Speicherbild und Zeitdauern - könnten zu weiteren Schlussfolgerungen führen.

Die Java App läuft gewöhnlicherweise die ganze Zeit und nach ca. 1 Woche zeigt sich das Problem?

War das schon immer so oder ist das irgendwie erst seit kurzem so (sorry, wenn ich eine etwaige Information dazu überlesen haben sollte)?

Ich habe das (völlig nicht fundierte ) Gefühl, dass du das Problem auch ohne angestecktes iPhone erleben wirst und das Java App Problem in sich bzw. für sich selber das Problem darstellt. Und "iPhone USB" einen zusätzlichen Effekt mit sich bringt, aber nicht den Ursprung darstellt.

Im übrigen, anstelle die Java App zu killen, ist die App jemals selber von sich aus abgestürzt (und hat sich damit beendet)? Log Files wären wirklich angesagt. OutOfMemory Exception Einträge würden eine klare Sprache sprechen.

Da ich jetzt erst wahrgenommen habe, dass die App "solange" am Stück erst laufen muss, ist eine (leider) übliche Empfehlung bei Java Apps mit Speicherproblemen (solange es halt nicht gefixt ist), die App regelmässig neu starten zu lassen.

Es ist noch zu früh für Schlussfolgerungen und das mysteriöse iPhone USB ist auch noch derzeit ziemlich unbehelligt geblieben, aber ich würde letztendlich wohl definitiv zu 2 Dingen raten:

• 1. VM Speicher anheben. Genug hast du ja. 1G vielleicht.
• 2. die App täglich automatisiert neu durchstarten lassen

Ferner wird neben -Xmx auch gerne dazu -Xms gesetzt, die initiale Speicherallokation. Sie fängt normalerweise klein an und wächst halt mit der Zeit, aber die Neuallokation "kostet" halt auch jedes Mal und wenn man abschätzen kann (hier hilft evtl auch wiederum Information aus dem Profiler) in welchem Speicherbereich sich die App bei normaler Operation befindet, dann ist es eigentlich gut mittels -Xms den Wert von Anfang gleich so zu setzen, damit die "Allokationsorgie" der App eine Zeitlang erspart wird. Ist letztendlich eine Performance Angelegenheit. Daher warum nicht grad so was ins .vmoptions setzen:

Dann würde ich erwarten, dass es besser sein wird, auch wenn die eigentliche Lösung womöglich ein Bugfixing sein sollte, was aber ausserhalb deines Wirkungsbereichs im Gegensatz zu den obigen Linderungsmassnahmen leider sein dürfte.

FYI: übrigens eine Koryphäe auf dem Gebiet des GC Tunings ist Angelika Langer
Wer mal die Gelegenheit hat in einem Vortrag von ihr zu sitzen - nicht die Chance entgehen lassen! Der eine oder andere wird vielleicht mit noch grösseren Fragezeichen herauskommen als man reingegangen ist

Weia

Der JAVA-Compiler übersetzt den JAVA-Sourcecode in einen Byte-Code, welcher wiederum von der virtuellen (JAVA-)Machine interpretiert wird, so daß er auf der realen (Intel-)Maschine ablaufen kann. Der Speicher für die virtuelle Maschine (VM) dient also nur der Interpretation kann also relativ klein sein. Allerdings ist in den Interpreter ein Just-in-tTime-Compiler (JIT)
eingebaut, der den Byte-Code beim ersten Durchlauf in Intel-Code übersetzt und in einem Cache-Speicher aufbewahrt, so daß er bei den nachfolgenden Durchläufen direkt ausgeführt werden kann. Der Cache-Speicher wird m.W. der VM zugeordnet. Trotz alledem wird der Speicher für die VM Deine 48 GB nicht wesentlich ankratzen.

Ganz anders sieht es aus für das reale Programm, das unter macOS abläuft und von diesem heftig Speicher abfordert. Eine JAVA-App legt bis auf eine paar simple Variablen alle Daten auf der Halde (engl.: heap) ab. Jeder Datenstrom, den die App anzapft, bevölkert die Halde und bleibt dort liegen bis der g.c. eingreift. Selbst dann, wenn die App die Verbindung zum Strom schon lange gekappt hat. Und wenn die Verbindung erneut hergestellt wird, wird auch ein neuer Datensatz auf der Halde angelegt. Tausend Ströme je hundert mal angezapft ergeben 100.000 Datensätze mit Pufferspeicher und allem Zubehör.

Je nachdem wie die App angelegt ist, gibt es zwei Möglichkeiten:

- Entweder die App fordert gleich zu Beginn eine riesige Sandbox für eine große Halde an, so daß der g.c. -- wenn überhaupt -- sehr lange nicht eingreifen muß.

- Oder die App begnügt sich mit weniger und der g.c. wird dem entsprechend sehr viel früher eingreifen.

Da aber alle Betriebsmittel (nicht nur der Speicher) erst freigegeben werden, wenn der g.c. eingreift, kann im ersten Fall durchaus ein anderes Betriebsmittel zu Ende gehen. Wenn zuerst der Speicher ausgeht, setzt JAVA eine Fehlermeldung ab, weil es sicher ist, dass es nun nicht mehr weiter geht. Andenfalls wartet es, bis das Betriebsmittel wieder verfügbar ist. (Die Betriebsmittel teilt JAVA mit den anderen Apps, die Sandbox nicht.) Wenn es blöd programmiert ist, geht das JAVA-Programm dazu in eine Warteschleife und blockiert den Prozessor mit nahezu 100% Rechenzeit für alle anderen Apps mit niedrigerer Priorität.

Welcher der beiden o.g. Fälle vorliegt, kannst Du an Hand Deiner Beobachtungen selbst ermitteln.

Vielen Dank für Eure interessanten and ausführlichen Überlegungen! Ich werde, um mich nicht völlig in dieser Geschichte zu verlieren, jetzt erstmal den Test mit dem abgenabelten iPhone durchführen; alles andere dann anschließend. Leider ist die Lightning-Kabel-Quelle, auf die ich gehofft hatte, versiegt, es wird also etwas dauern. Ich melde mich dann hier wieder.
Sollte man. Leider ist das Gegenteil der Fall. Und wenn man Glück hat, wird ein kritischer Bug, den man detailliert beschrieben meldet und der auch als solcher anerkannt wird, nach 3 Jahren gefixt …

Ich würde dieses Programm niemals fürs Traden benutzen, aber ein Programm, das ich dereinst für bestimmte Analysetechniken benutzt hatte, ist über mehrere Firmenaufkäufe hinweg am Ende in dieses Programm integriert worden, und ich hatte einfach noch keine Zeit, mir eine andere Plattform zu suchen.

Ich wüsste noch nicht mal, ob ich eine bessere fände; das ist auf dem Mac leider ein absolutes Trauerspiel und eine echte Marktlücke. Ursprünglich wollte ich kurzerhand selbst ein Programm schreiben, aber dann bräuchte mein Tag 30 Stunden.
Davon gehe ich eigentlich aus, zumal nach Wiesis Erläuterungen. Was ich nur überhaupt nicht auf die Reihe bekomme ist eben die Interdependenz mit dem iPhone. Unter pragmatischen Gesichtspunkten ist vermutlich das einzig Vernünftige, das Programm, wie Du an andere Stelle vorgeschlagen hast, täglich neu zu starten. Aber diese iPhone-Geschichte hat dann einfach meine fundamentale Neugierde geweckt.
Kann man nicht. Der Mac tut noch eine Myriade anderer Dinge und ist bis in tiefe Tiefen hinein von mir speziell konfiguriert. Aber nicht in Bereichen, die hier eine Rolle spielen könnten.
Ah, OK. Heißt dann umgekehrt aber natürlich auch, dass mangelnder Speicherplatz für den restlichen Mac dann nicht das Problem sein kann.
Das Problem kann sich schon nach einem Tag zeigen. Wenn es das tut, wissen wir schnell bescheid. Aber manchmal dauert es eben auch bis zu einer Woche; sprich, wenn das Problem nicht auftaucht, kann man frühestens nach einer Woche vermuten, dass die iPhone-Abnablung es behebt.
Seit dem Update von Mavericks → Mojave. Das war gleichzeitig der Wechsel von Java 6 zu Java 8, aber das spielt ja keine Rolle, wenn das Programm seine eigene Java-VM benutzt.
Ich würde das nicht energisch bestreiten wollen.
Nö. Sie hängt einfach bis ultimo.
Tja, wenn ich rausfinde ob und wo … Ticket kannst Du vergessen.

Schon gefunden. Reicht allerdings nur 24 Stunden zurück, und da war alles OK. Aber ich weiß jetzt, wo ich schaue, wenn es das nächste Mal hängt.

Was ich allerdings bei der Suche nach geöffneten Dateien auch gefunden habe, ist, dass dieses dämliche Programm sich allen Ernstes für ein DTP-Programm hält und alle auf meinem Mac installierten Font-Dateien öffnet. Dummerweise sind das um die 25.000 …

Leider immer schwierig, wenn sich etwas nicht schön reproduzieren lässt.
Würde dann die Behauptung in den Raum stellen, dass es zu keiner OutOfMemoryException kommt/kam, da die App eigentlich dabei crashen müsste. Ein Hängen (und ohne Crash der App zu einem Zeitpunkt t) klingt dann wiederum nach den bereits verschiedentlich beschriebenen "Resourcen Locking"-Situationen. Also dann doch eher etwas im Zusammenspiel mit "externem Einfluss".
Super! Sofern keine sensitiven Daten drin sind, länge es drin, dass du es "paste-binnen" könntest um mal einen Blick drauf zu werfen? Eine Historie an Logs und/oder verschiedene Logs nehme ich an sind in dem Verzeichnis oder seinem "Verzeichnisumfeld" nicht vorhanden?
Strange. Kannte ich auch noch nicht. Habe ein (nicht gelöstes) Ticket dazu gefunden, welches sich mit deiner Beobachtung deckt:
Schätze daran kann man nichts machen. Andererseits ist unklar, ob das überhaupt einen Einfluss in der Sache hier hat.

Wenn es "ohne iPhone dran" nicht zu der Problemsituation kommen sollte, und danach wieder "mit iPhone" auftritt, könntest du bei der nächsten Testrunde mal das iPhone USB Netzwerk Interface deaktivieren (Beispielanleitung: ) um damit wieder ein "mit iPhone dran" Szenario zu exerzieren?

Naja, dass die Zeitspanne variiert bei Problemen wie diesem, ist ja normal.
Für Pastebin ist die Datei zu groß (1 MB unkomprimiert), aber hier ist ein Download-Link für ein Zip-Archiv:
Doch, die letzten drei. Und natürlich könnte ich Time Machine bemühen. Aber ich denke, das ist relativ sinnlos, da sich die Dateien nicht wesentlich unterscheiden werden, solange sie kein Hängen einschließen, und da weiß ich leider einfach nicht, wann das letzte war. Ich lade eine zweite Logdatei hoch, sobald der erneut Fehler auftrat.

Die jetzige Logdatei umfasst den Zeitraum von heute früh um 5:24 Uhr bis 17:20 Uhr. Von 5:44 Uhr bis 13.49 Uhr schlief der Computer, um 15:46 Uhr habe ich „freiwillig“ einen Neustart gemacht; das Programm hing nicht, aber die Kurse wurden nicht aktualisiert (das kann aber gut eine Server-Störung gewesen sein).

Ressourcenverbrauch des Programms um 17:20 Uhr: 120% CPU-Last, 4 GB physikalisches RAM. Das dürfte Durchschnitt sein.
Naja, immerhin sind schon mal 25.000 Dateideskriptoren futsch …
OK.

Das sieht doch ganz interessant aus. Ich würde mal in der .vmoptions folgende Werte einsetzen:


Weiter oben sieht man in den Logs, dass der Heap auf 2 GB konfiguriert zu sein scheint. Deine Kiste hat ja genug RAM, viel hilft viel.

Ein paar Auffälligkeiten im Log auf die Schnelle:

2x JVM Freezes:
8 Stunden lang

24min lang


5x unknown host Meldungen:


diverse Netzwerk(dienste) bezogene Fehler:




(sofern du nicht bereits selber bereits eine Möglichkeit hast ein Log "einzufärben", hier eine Software mit der man mal "schnell" die Bereiche nach Log Level Typen "erscrollen" kann: )

Das waren die Zeiten, in denen der Mac geschlafen hat.
Auch da würde ich mir keine großen Gedanken machen – ab und an klappt halt für kurze Zeit die Verbindung nicht. Ist bei praktisch allen Kursdatenanbietern normal. (Naja, bei Bloomberg für 1000€/Monat vielleicht nicht …  )

… und schon 🙄 habe ich ein zusätzliches Lightning-Kabel und kann den Testlauf ohne verbundenes iPhone starten. Rechner neu gestartet, iPhone nicht mehr verbunden, und jetzt warte ich mal die nächste Woche ab, wann was passiert.

Tja, und immer, wenn man denkt, jetzt wird klüger, wird man es doch nicht …

Die ganze Woche ist nichts passiert und wäre auch heute nichts mehr passiert, wäre die Uptime definitiv länger gewesen als jemals mit verbundenem iPhone.

Aber heute, sozusagen im allerletzten Moment, hing die App dann doch wieder. Nur: sie tat das jetzt, ohne den restlichen Rechner mit stillzulegen, sozusagen ein ganz „übliches“ Hängen einer App. Dementsprechend konnte ich sie auch problemlos killen – es ergab sich also sofort der Zustand, der sich sonst erst nach Abnabeln des verbundenen iPhones ergab. Insofern wäre das stimmig damit, dass ich den bei verbundenem iPhone misslicheren Zustand (der ganze Rechner hängt bis auf die Menüleisten-Uhr, die alle 30s weiterspringt) ja eben auch in ein „normales Hängen einer App“ dadurch überführen kann, dass ich das iPhone abnable.

Sicher kann man das nach einmaligem Auftreten natürlich noch nicht sagen, aber es scheint so zu sein, dass das Problem in zwei relativ unabhängige Teile zerfällt:

• Java-App hängt – misslich, aber shit happens
• Verbundenes iPhone sorgt dafür, dass im Falle des Hängens der Java-App der ganze Mac fast komplett blockiert ist (bis auf extrem kurze Intervalle alle 30s) – seeeehhhr seltsam

Falls noch jemand gucken will, hier ist die aktuelle Logdatei, die den Status im Augenblick des Hängens erfasst: . Voller low memory-Warnungen, aber das scheint ja sozusagen der Normalzustand zu sein …

Vor einem Neustart wollte ich nun in einem nächsten Testschritt die Speicherbelegung in .vmoptions wie vorgeschlagen erhöhen und da gab es nun die nächsten beiden Überraschungen:

• Ich kann die Parameter gar nicht verändern, denn die .vmoptions-Datei wird zusammen mit der App bei jedem Startvorgang erneut heruntergeladen und überschreibt, was auch immer ich eingebe.
• Selbst wenn ich es könnte, würde es nichts nützen, denn die verwendete .vmoptions-Datei reserviert sich bereits sage und schreibe 6 GB Speicher ; mehr könnte bzw. würde ich ihr sicher auch nicht zugestehen.

Ich werde jetzt die nächste Woche nochmals mit abgenabeltem iPhone weiterarbeiten, um zu sehen, ob sich das leicht veränderte Verhalten wiederholt, aber insgesamt vermute ich, das bleibt einer der Fälle, wo ich nie wirklich rausbekommen werde, was zwischen Hammel und Herde passiert …

Falls von Interesse, hier ist die komplette .vmoptions-Datei (die ich wie gesagt nicht ändern kann):

Am Wochenende ist es jetzt prompt doch passiert: Java-App hängt und Mac hängt auch, ohne verbundenes iPhone.

Da das iPhone ja nun abgenabelt war, habe ich es testweise diesmal wieder mit dem Mac verbunden, und siehe da: Das führte ebenfalls dazu, dass der Mac wieder ging und nur noch die App hing.

Die Situation ist also wohl die, dass ein warum auch immer auftretender Hang der Java-App auch den Mac lahmlegen kann, aber eine Veränderung an einem USB-Port den Mac daraus befreit.

Ich hatte das, als das iPhone noch verbunden war, mit ein paar anderen USB-Geräten ohne Erfolg schon probiert, es kommt also offenbar auf das bestimmte Gerät an oder einen bestimmten Hub oder eine bestimmte USB-Buchse am Mac Pro oder was auch immer; ich werde das jetzt nicht mehr weiter untersuchen, sondern mit diesem seltsamen Phänomen wohl leben müssen.

Ach, ich liebe Java!


Danke nochmals an alle, die hier so rege mitgerätselt haben!

hui, das ist ja mal ein interessanter Thread!

Zum einen: ein grundlegendes Ärgernis zieht sich bei Java durch, dass man sich aufregen könnte: misserable GarbageCollection, das hat hat uns schon damals beim IBM WebSphere fast in den Wahnsinn getrieben, von daher denke ich, dass das erste Posting von Wiesi ziemlich den Punkt trifft.
Gerade, wenn bei Weia, dir, wenn da diverse Applikationen (wenn ich das aus deinen Posting richtig in Erinnerung habe) laufen, können die Seiteneffekte nur mit bergeweise Protokollen zur Lösung führen.
[Monster-Aufwand]

Eine Sache, die dir evtl helfen könnte, ist der Tastatur-Puffer:
Falls du (empirisch eruiert) weißt, an der wie vielten Position von oben im "Sofort beenden" Fenster die Java-Software steht, könntest du den Tastatur-Puffer für die kurze Zeit, in der der Rechner reagiert vor-füllen.
Also: wenn der Rechner "steht" und nur kurzfristig kurz reagiert, Alt-Cmd-Esc drücken, dann so oft die "Pfeil nach unten" Taste drücken, bis das Java-Applet ausgewählt ist und dann Enter drücken, das ganze in einem Rutsch ohne Pause.
Als "Voodoo"-Funktion, um quer hängende Prozesse zu beenden, hat das bei Mac OS X (bei Java-Entwicklern) bisher öfter funktioniert.
U.Ust ist das ja eine Hilfe um zumindest bei einer Reihe von Fällen wieder die Kontrolle über das System zu erhalten.

Falls Du, Weia, in diesem Gesamtzusammenhang weiter Erkenntnisse erfährst, fände ich Informationen darüber sehr interessant

Das ist gar nicht nötig; wenn Alt-Cmd-Esc überhaupt „durchkommt“, ist die Java-App immer schon vorausgewählt (weil sie ja die vorderste App ist). Zweimal Return reicht dann und wenn der Mac gar nichts durchlassen will, dann weiß ich ja jetzt, dass ich nur das iPhone an- oder abstecken muss, und dann geht es. Das ist einigermaßen praktikabel.
Wenn sich innerhalb der nächsten 3 Monate, die dieser Thread noch offen ist, noch was ergibt, werde ich das hier sicher posten, aber für den Augenblick habe ich die Nase von diesem Problem erstmal gestrichen voll. (Es warten noch x andere Mojave-Probleme auf mich, die ich seit der Installation letzten Herbst noch gar keine Zeit hatte anzugehen … )

Danke!

Kommt mir grad so: blöde Frage: wie verhält sich das System, wenn du das iPhone nicht per Dock verbunden hast?
(per WLAN sync-en geht ja technisch gesehen auch)
Das würde dann ja implizieren, dass ein Teil der Dock-Software in Java geschrieben ist - und dazwischenfingert ....

Naja, das war doch gerade mein Experiment der letzten beiden Wochen, dass ich das iPhone nicht mehr ins Dock gesteckt (sondern anderweitig geladen) hatte.

Und das Resultat schien zunächst zu sein, dass das ganze Problem dann verschwindet, ganz am Ende des ersten von mir veranschlagten Testzeitraums tauchte es dann doch wieder auf, aber nur in abgemildeter Form (Java-App hängt, macht aber nicht den gesamten Mac unresponsive), und schließlich gab es dann doch wieder einen kompletten Hang (Java-App + Mac), wobei in diesem Fall der Mac-Hang in dem Moment aufhörte, wo ich das unverbundene iPhone ins Dock einsteckte (sprich, es ist sowas wie „USB-Interrupt“ beim Abstecken oder Anstecken des iPhones, der den Mac-Hang beendet).

Währenddessen ist ja weitere Zeit vergangen und „gefühlt“ (ich kann nicht weitere Zeit für exakte Beobachtung aufwenden) lässt sich sagen, dass das Phänomen, dass das Hängen der Java-App auch den Mac blockiert, grundsätzlich mit oder ohne verbundenes iPhone auftritt, aber mit höherer Wahrscheinlichkeit, wenn das iPhone verbunden ist. In jedem Fall aber löst eine Änderung des „iPhone-Status“ (nicht verbunden → verbunden oder verbunden → nicht verbunden) die Blockade des Mac auf und es hängt dann nur noch die Java-App.
Würde es das zwingend implizieren? Ich bin alles andere als ein Java-Experte – laufen alle Java-Programme quasi in einem gemeinsamen „Pool“, in dem sie sich gegenseitig beeinflussen können?

Es ist mir jedenfalls jüngst gelungen, bei einem erneuten Hängen von Java-App und Mac in einem der kurzen Momente alle 30s, in denen macOS nicht blockt, in der Aktivitätsanzeige zu sehen, dass ein Prozess, der in diesem Falle wilddreht (> 100% CPU-Last), ein Prozess mit dem wunderschönen Namen lsd ist.

Die Manpage sagt dazu geheimnisvoll:Das ist alles, keinerlei weitere Info. (Wenn man will, könnte man diese Manpage ja als total abgefahrene Drogenmetapher lesen. )

Ich habe dann bei nächster Gelegenheit (während lsd noch über 100% verbrauchte) eine Analyse des Prozesses laufen lassen, und siehe da, er war praktisch ausschließlich mit endlos vielen GarbageCollection-Threads samt malloc/dealloc ausgelastet.

Das ist ja aber Garbage Collection im CoreServices-Umfeld, das kann doch eigentlich nichts mit Java-Garbage-Collection zu tun haben – oder doch?!?

Das sieht alles nach einer Überlastung durch das Java System aus. Und ja, es ist möglich, das dieses System sich bei den CoreServices bedient. Die Garbage-Collection muß um so öfter ansprechen je voller der Speicher (für die Java-Maschine) ist.

Da sehr vieles im MAC OS über Events gesteuert ist, kann das System hängen, wenn ein Event (z.B. eine Fertigmeldung) verloren geht. Und Events gehen verloren, besonders wenn das System überlastet ist:

Vor vielen Jahren betreute ich ein DV-System in einen Hüttenwerk. Durch einen Konstruktionsfehler in der Hardware des Datenerfassungssystems für die Terminals gingen immer wieder Interrupts verloren. Aber die findigen Franzosen, welche die Anlage geliefert hatten, haben durch eine "recuperation" das entsprechende Interrupt alle Sekunde erneut getriggert. Als der HW-Fehler beseitigt war, habe ich die recuperation ausgebaut und nach gut einer Stunde hing das System, und das immer und immer wieder. Ich baute die recuperation also wieder ein. Wir haben nie erfahren, woran es lag.

Das Umstöpseln Deines iPhones erzeugt offensichtlich ein Ereignis, welches die Verklemmung aufbricht. Das 30-Sekunden-Event auch. Vielleicht hast Du noch was anderes zum Umstöpseln mit dem gleichen Effekt.

Zu olim's Zeiten im Hüttenwerk hatte der Computer nur einen Prozessor und es war vieles einfacher gestrickt als heute. Dadurch waren die Kausalketten viel kürzer. Du bist weit gekommen. Aber an Deiner Stelle würde ich jetzt aufgeben, wie wir damals auch. Ich kann verstehen, daß Dich das als Wissenschafter ziemlich wurmt.

Yep.Ah, OK.Die USB-Geräte, die ich sonst noch leicht an- oder abstöpseln könnte, hatten jedenfalls allesamt keinen Effekt.
Ja, mir reicht’s jetzt erst mal.Der Pragmatiker hat den Wissenschaftler zumindest vorläufig in die Schranken gewiesen.

Ich hatte weder Zeit noch Nerv, das systematisch weiterzuverfolgen, habe aber die Vorfälle während meiner normalen Arbeit aufmerksam beobachtet.

Danach kann ich ziemlich sicher sagen, dass eine eigentümlich asymmetrische Abhängigkeit besteht:

Die Wahrscheinlichkeit, dass das Java-Programm den Rechner (bzw. die GUI) blockiert, steigt ganz klar mit bestimmten Umgebungsbedingungen an, insbesondere sehr vielen offenen Finder-Fenstern und sehr vielen offenen Webbrowser-Fenstern. Sind sehr viele Fenster von z.B. Finder und Safari gleichzeitig offen, ist es meist nur noch eine Frage von ein paar Stunden, bis das Java-Programm den Rechner (bzw. die GUI) aufhängt.

Die erstaunliche Asymmetrie besteht darin, dass Finder und Webbrowser ohne jeden Zweifel massiv dazu beitragen, dass es zum Hängen kommt, es aber, wenn der Rechner (bzw. die GUI) erst einmal hängt, überhaupt nichts nützt, eines dieser Programme (über einen ssh-Login) zu killen. Der Rechner (bzw. die GUI) hängt dann unvermindert weiter.

Aber sobald ich das Java-Programm kille (und nur dann), ist der Spuk vorbei.

Whatever this means …

Ich meine it means: Wenn der Speicher an der Belastungsgrenze ist, gibt es eine Verklemmung im Java-System, die eine wichtige System-Resource blockiert (nicht mehr freigeben kann, weil in einem deadlock). Wenn Du Java gewaltsam beendest, wird die Resource freigegeben.

Offensichtlich ist die o.g. System-Resource oberhalb des Kernels angesiedelt, sonst würde der ssh-Login nicht funktionieren und man könnte Java auch nicht killen.