Wie stürzt man eine JVM ab?

Ich habe ein Buch über Programmierkenntnisse gelesen, in dem der Autor den Befragten fragt: "Wie stürzt man eine JVM ab?" Ich dachte, Sie könnten dies tun, indem Sie eine Endlos-for-Schleife schreiben, die schließlich den gesamten Speicher verbraucht.

Hat jemand eine Idee?

Das, was einer einzelnen "Antwort" am nächsten kommt, ist, System.exit()dass die JVM sofort ohne ordnungsgemäße Bereinigung beendet wird. Abgesehen davon sind nativer Code und Erschöpfung der Ressourcen die wahrscheinlichsten Antworten. Alternativ können Sie in Suns Bug-Tracker nach Fehlern in Ihrer Version der JVM suchen, von denen einige wiederholbare Absturzszenarien ermöglichen. Früher kam es bei den 32-Bit-Versionen zu halb-regulären Abstürzen, wenn wir uns dem 4-GB-Speicherlimit näherten (wir verwenden jetzt im Allgemeinen 64-Bit).

Ich würde das Auslösen eines OutOfMemoryError oder StackOverflowError nicht als Absturz bezeichnen. Dies sind nur normale Ausnahmen. Um eine VM wirklich zum Absturz zu bringen, gibt es drei Möglichkeiten:

1. Verwenden Sie JNI und stürzen Sie im nativen Code ab.
2. Wenn kein Sicherheitsmanager installiert ist, können Sie Reflection verwenden, um die VM zum Absturz zu bringen. Dies ist VM-spezifisch, aber normalerweise speichert eine VM eine Reihe von Zeigern auf native Ressourcen in privaten Feldern (z. B. wird ein Zeiger auf das native Thread-Objekt in einem langen Feld in java.lang.Thread gespeichert ). Ändern Sie sie einfach per Reflection und die VM stürzt früher oder später ab.
3. Alle VMs haben Fehler, Sie müssen also nur einen auslösen.

Für die letzte Methode habe ich ein kurzes Beispiel, das eine Sun Hotspot-VM leise zum Absturz bringt:

public class Crash {
    public static void main(String[] args) {
        Object[] o = null;

        while (true) {
            o = new Object[] {o};
        }
    }
}

Dies führt zu einem Stapelüberlauf im GC, sodass Sie keinen StackOverflowError erhalten, sondern einen echten Absturz einschließlich einer hs_err * -Datei.

JNI . Tatsächlich ist bei JNI ein Absturz die Standardbetriebsart. Sie müssen besonders hart arbeiten, damit es nicht abstürzt.

Benutze das:

import sun.misc.Unsafe;

public class Crash {
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    public static void crash() {
        unsafe.putAddress(0, 0);
    }
    public static void main(String[] args) {
        crash();
    }
}

Diese Klasse muss sich im Boot-Klassenpfad befinden, da sie vertrauenswürdigen Code verwendet. Führen Sie sie daher folgendermaßen aus:

java -Xbootclasspath / p:. Absturz

Ich bin hierher gekommen, weil ich in The Passionate Programmer auch auf diese Frage gestoßen bin von Chad Fowler . Für diejenigen, die keinen Zugriff auf eine Kopie haben, ist die Frage als eine Art Filter / Test für Kandidaten gedacht, die sich für eine Position bewerben, die "wirklich gute Java-Programmierer" erfordert.

Insbesondere fragt er:

Wie würden Sie ein Programm in reinem Java schreiben, das zum Absturz der Java Virtual Machine führen würde?

Ich habe über 15 Jahre in Java programmiert und fand diese Frage sowohl rätselhaft als auch unfair. Wie andere bereits betont haben, wurde Java als verwaltete Sprache speziell entwickelt, um nicht zum Absturz zu kommen . Natürlich gibt es immer JVM-Fehler, aber:

1. Nach mehr als 15 Jahren JREs auf Produktionsebene ist dies selten.
2. Solche Fehler werden wahrscheinlich in der nächsten Version behoben. Wie wahrscheinlich ist es also, dass Sie als Programmierer auf die Details der aktuellen JRE-Show-Stopper stoßen und diese abrufen?

Wie andere bereits erwähnt haben, ist nativer Code über JNI ein sicherer Weg, um eine JRE zum Absturz zu bringen. Aber der Autor hat speziell in reinem Java erwähnt , das ist also raus.

Eine andere Möglichkeit wäre, die JRE-Scheinbytecodes einzugeben. Es ist einfach genug, einige Müll-Binärdaten in eine .class-Datei zu kopieren und die JRE zu bitten, sie auszuführen:

$ echo 'crap crap crap' > crap.class
$ java crap
Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value 1668440432 in class file crap

Zählt das? Ich meine, die JRE selbst ist nicht abgestürzt. Der falsche Code wurde ordnungsgemäß erkannt, gemeldet und beendet.

Dies lässt uns die naheliegendsten Arten von Lösungen übrig, z. B. das Aufblasen des Stapels durch Rekursion, das Auslaufen des Heapspeichers durch Objektzuweisungen oder das einfache Werfen RuntimeException. Dies führt jedoch nur dazu, dass die JRE mit einer StackOverflowErroroder einer ähnlichen Ausnahme beendet wird, was wiederum kein wirklicher Absturz ist .

Also, was ist noch übrig? Ich würde wirklich gerne hören, was der Autor wirklich als richtige Lösung im Sinn hatte.

Update : Chad Fowler hat hier geantwortet .

PS: Es ist ein ansonsten tolles Buch. Ich nahm es zur moralischen Unterstützung auf, als ich Ruby lernte.

Dieser Code wird die JVM auf böse Weise zum Absturz bringen

import sun.dc.pr.PathDasher; 

public class Crash
{
     public static void main(String[] args)
     {    
        PathDasher dasher = new PathDasher(null) ;
     }
}

Das letzte Mal, als ich es versuchte, würde es das tun:

public class Recur {
    public static void main(String[] argv) {
        try {
            recur();
        }
        catch (Error e) {
            System.out.println(e.toString());
        }
        System.out.println("Ended normally");
    }
    static void recur() {
        Object[] o = null;
        try {
            while(true) {
                Object[] newO = new Object[1];
                newO[0] = o;
                o = newO;
            }
        }
        finally {
            recur();
        }
    }
}

Erster Teil der generierten Protokolldatei:

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x000000006dad5c3d, pid=6752, tid=1996
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x2e5c3d]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00000000014c6000):  VMThread [stack: 0x0000000049810000,0x0000000049910000] [id=1996]

siginfo: ExceptionCode=0xc00000fd, ExceptionInformation=0x0000000000000001 0x0000000049813fe8 

Registers:
EAX=0x000000006dc83090, EBX=0x000000003680f400, ECX=0x0000000005d40ce8, EDX=0x000000003680f400
ESP=0x0000000049813ff0, EBP=0x00000000013f2df0, ESI=0x00000000013f0e40, EDI=0x000000003680f400
EIP=0x000000006dad5c3d, EFLAGS=0x0000000000010206

Eine perfekte JVM-Implementierung wird niemals abstürzen.

Um eine JVM zum Absturz zu bringen, müssen Sie neben JNI einen Fehler in der VM selbst finden. Eine Endlosschleife verbraucht nur CPU. Die unendliche Zuweisung von Speicher sollte nur OutOfMemoryError in einer gut erstellten JVM verursachen. Dies würde wahrscheinlich Probleme für andere Threads verursachen, aber eine gute JVM sollte immer noch nicht abstürzen.

Wenn Sie einen Fehler im Quellcode der VM finden und beispielsweise einen Segmentierungsfehler in der Speichernutzung der Implementierung der VM verursachen, können Sie ihn tatsächlich zum Absturz bringen.

Wenn Sie JVM zum Absturz bringen möchten, verwenden Sie Folgendes in Sun JDK 1.6_23 oder niedriger:

Double.parseDouble("2.2250738585072012e-308");

Dies ist auf einen Fehler in Sun JDK zurückzuführen, der auch in OpenJDK gefunden wurde. Dies wird ab Oracle JDK 1.6_24 behoben.

Kommt darauf an, was du mit Absturz meinst.

Sie können eine unendliche Rekursion durchführen, um den Stapelspeicherplatz zu verringern, aber das wird "elegant" abstürzen. Sie erhalten eine Ausnahme, aber die JVM selbst übernimmt alles.

Sie können JNI auch verwenden, um nativen Code aufzurufen. Wenn Sie es nicht genau richtig machen, können Sie es schwer zum Absturz bringen. Das Debuggen dieser Abstürze macht "Spaß" (glauben Sie mir, ich musste eine große C ++ - DLL schreiben, die wir von einem signierten Java-Applet aus aufrufen). :) :)

Das Buch Java Virtual Machine von Jon Meyer enthält ein Beispiel für eine Reihe von Bytecode-Anweisungen, die dazu führten, dass die JVM einen Core-Dump ausführte. Ich kann mein Exemplar dieses Buches nicht finden. Wenn jemand da draußen einen hat, schauen Sie bitte nach und posten Sie die Antwort.

auf winxpsp2 w / wmp10 jre6.0_7

Desktop.open (uriToAviOrMpgFile)

Dies führt dazu, dass ein gespawnter Thread einen nicht gefangenen Throwable auslöst und der Hotspot abstürzt

YMMV

Defekte Hardware kann jedes Programm zum Absturz bringen. Ich hatte einmal einen App-Absturz, der auf einem bestimmten Computer reproduzierbar war, während er auf anderen Computern mit genau demselben Setup einwandfrei lief. Es stellte sich heraus, dass die Maschine einen fehlerhaften RAM hatte.

kürzest möglicher Weg :)

public class Crash
{
    public static void main(String[] args)
    {
        main(args);
    }
}

Kein Absturz, aber näher an einem Absturz als die akzeptierte Antwort der Verwendung System.exit

Sie können die JVM durch Aufrufen anhalten

Runtime.getRuntime().halt( status )

Laut den Dokumenten: -

"Diese Methode bewirkt nicht, dass Shutdown-Hooks gestartet werden, und führt keine nicht aufgerufenen Finalizer aus, wenn Finalization-on-Exit aktiviert wurde."

Hier finden Sie eine ausführliche Erläuterung der Ursachen für den Core-Dump von JVM (dh Absturz): http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_17534

Wenn Sie so tun möchten, als hätten Sie keinen Speicher mehr, können Sie dies tun

public static void main(String[] args) {
    throw new OutOfmemoryError();
}

Ich kenne einige Möglichkeiten, um den JVM-Speicherauszug zu einer Fehlerdatei zu führen, indem native Methoden (solche, die eingebaut sind) aufgerufen werden, aber es ist wahrscheinlich am besten, wenn Sie nicht wissen, wie dies zu tun ist. ;)

Wenn Sie einen Absturz als Prozessabbruch aufgrund einer nicht behandelten Situation definieren (dh keine Java-Ausnahme oder -Fehler), kann dies nicht in Java erfolgen (es sei denn, Sie haben die Berechtigung, die Klasse sun.misc.Unsafe zu verwenden). Dies ist der springende Punkt bei verwaltetem Code.

Typische Abstürze im nativen Code treten auf, indem Zeiger auf falsche Speicherbereiche (Nulladresse oder falsch ausgerichtet) de-referenziert werden. Eine andere Quelle könnten illegale Maschinenanweisungen (Opcodes) oder nicht behandelte Signale von Bibliotheks- oder Kernelaufrufen sein. Beide können ausgelöst werden, wenn die JVM oder die Systembibliotheken Fehler aufweisen.

Zum Beispiel können JITed (generierter) Code, native Methoden oder Systemaufrufe (Grafiktreiber) Probleme haben, die zu echten Abstürzen führen (es kam häufig vor, dass ein Absturz auftrat, wenn Sie ZIP-Funktionen verwendeten und der Speicher knapp wurde). In diesen Fällen startet der Crash-Handler der JVM und gibt den Status aus. Es könnte auch eine Betriebssystem-Kerndatei generieren (Dr. Watson unter Windows und Core Dump unter * nix).

Unter Linux / Unix können Sie leicht einen JVM-Absturz verursachen, indem Sie ein Signal an den laufenden Prozess senden. Hinweis: Sie sollten dies nicht verwenden SIGSEGV, da Hotspot dieses Signal abfängt und es an den meisten Stellen erneut als NullPointerException auslöst. Es ist also besser, SIGBUSzum Beispiel eine zu senden .

JNI ist eine große Quelle für Abstürze. Sie können auch über die JVMTI-Schnittstelle abstürzen, da dies auch in C / C ++ geschrieben werden muss.

Wenn Sie einen Thread-Prozess erstellen, der unendlich mehr Threads erzeugt (die mehr Threads erzeugen, welche ...), verursachen Sie möglicherweise einen Stapelüberlauffehler in der JVM selbst.

public class Crash {
    public static void main(String[] args) {

        Runnable[] arr = new Runnable[1];
        arr[0] = () -> {

            while (true) {
                new Thread(arr[0]).start();
            }
        };

        arr[0].run();
    }
}

Dies gab mir die Ausgabe (nach 5 Minuten beobachten Sie Ihren Widder)

An unrecoverable stack overflow has occurred.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x0000000070e53ed7, pid=12840, tid=0x0000000000101078
#
# JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# 

Wenn mit "Absturz" ein plötzlicher Abbruch der JVM gemeint ist, würde dies dazu führen, dass die JVM in ihr hs_err_pid% p.log schreibt , können Sie dies auf diese Weise tun.

Setzen Sie das--Xmx-Argument auf einen winzigen Wert und weisen Sie die JVM an, einen Absturz auf outofmemory zu erzwingen:

 -Xmx10m -XX:+CrashOnOutOfMemoryError

Um klar zu sein, ohne die zweiten arg oben, würde es führt nur in dem Jvm Abschluss mit einem OutOfMemoryError, aber es wäre nicht „Crash“ oder abrupt abbrechen die JVM.

Diese Technik erwies sich als hilfreich, als ich versuchte, das Argument JVM -XX: ErrorFile zu testen, das steuert, wo ein solches hs_err_pid-Protokoll geschrieben werden soll. Ich hatte diesen Beitrag hier gefunden, als ich versuchte, Wege zu finden, um einen solchen Absturz zu erzwingen. Als ich später feststellte, dass das oben Genannte für mein Bedürfnis am einfachsten ist, wollte ich es hier zur Liste hinzufügen.

Schließlich, FWIW, wenn jemand dies testen kann, wenn er bereits einen -Xms-Wert in Ihren Argumenten festgelegt hat (auf einen größeren Wert als oben), möchten Sie diesen ebenfalls entfernen oder ändern, oder Sie erhalten keinen Absturz, sondern einfach Ein Fehler beim Starten des JVM mit der Meldung "Die anfängliche Heap-Größe wurde auf einen größeren Wert als die maximale Heap-Größe festgelegt". (Das wäre nicht offensichtlich, wenn die JVM als Dienst ausgeführt würde, beispielsweise mit einigen App-Servern. Auch hier hat es mich gebissen, also wollte ich es teilen.)

Wenn Sie diese Endlosschleife in einen rekursiven Aufruf derselben Funktion ändern, wird eine Stapelüberlaufausnahme angezeigt:

public static void main(String[] args) {
    causeStackOverflow();
}

public void causeStackOverflow() {
    causeStackOverflow();
}

Ich mache es jetzt, bin mir aber nicht ganz sicher, wie ... :-) JVM (und meine App) verschwinden manchmal einfach komplett. Keine Fehler geworfen, nichts protokolliert. Geht ohne Vorwarnung sofort von der Arbeit zum Nicht-Laufen über.

Kürzeste? Verwenden Sie die Roboterklasse, um STRG + BREAK auszulösen. Ich habe dies festgestellt, als ich versuchte, mein Programm zu schließen, ohne die Konsole zu schließen (es gab keine Exit-Funktion).

Zählt das?

long pid = ProcessHandle.current().pid();
try { Runtime.getRuntime().exec("kill -9 "+pid); } catch (Exception e) {}

Es funktioniert nur unter Linux und unter Java 9.

Aus irgendeinem Grund bekomme ich nicht, ProcessHandle.current().destroyForcibly();töte die JVM nicht und wirft java.lang.IllegalStateExceptionmit der Meldung Zerstörung des aktuellen Prozesses nicht erlaubt .

Dieses Problem tritt auf, wenn versucht wird, den JVM-Absturz zu replizieren.

Jni funktioniert, muss aber für verschiedene Plattformen optimiert werden. Schließlich verwende ich diese Kombination, um JVM zum Absturz zu bringen

1. Starten Sie die Anwendung mit diesen JVM-Optionen -XX:+CrashOnOutOfMemoryError
2. Verwenden Sie a long[] l = new long[Integer.MAX_VALUE];, um das OOM auszulösen

Dann stürzt JVM ab und generiert das Absturzprotokoll.

Wenn ein 'Absturz' etwas ist, das das jvm / Programm von der normalen Beendigung abbricht, könnte dies eine nicht behandelte Ausnahme tun.

public static void main(String args[]){
   int i = 1/0;
   System.out.print(i); // This part will not be executed due to above  unhandled exception
  }

Es kommt also darauf an, welche Art von Absturz ?!