Как разбить JVM?

JNI. Фактически, с JNI сбой является режимом работы по умолчанию. Придется потрудиться, чтобы он не рухнул.

Зависит от того, что вы подразумеваете под крахом.

Вы можете выполнить бесконечную рекурсию, чтобы исчерпать пространство стека, но это приведет к сбою "изящно". Вы получите исключение, но все будет обрабатывать сама JVM.

Вы также можете использовать JNI для вызова машинного кода. Если вы не сделаете это правильно, вы можете сильно разбить его. Отладка этих сбоев - это «весело» (поверьте мне, мне пришлось написать большую C++ DLL, которую мы вызываем из подписанного java-апплета). :)

Если вы измените этот бесконечный цикл for на рекурсивный вызов той же функции, вы получите исключение переполнения стека:

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

public void causeStackOverflow() {
    causeStackOverflow();
}

Наиболее близким к единственному «ответу» является System.exit(), который немедленно завершает работу JVM без надлежащей очистки. Но кроме этого, наиболее вероятными ответами являются собственный код и исчерпание ресурсов. В качестве альтернативы вы можете поискать в системе отслеживания ошибок Sun ошибки в вашей версии JVM, некоторые из которых допускают повторяющиеся сценарии сбоев. Раньше мы получали полурегулярные сбои при приближении к пределу памяти в 4 ГБ в 32-битных версиях (сейчас мы обычно используем 64-битные).

Идеальная реализация JVM никогда не выйдет из строя.

Чтобы вывести из строя JVM, помимо JNI, вам нужно найти ошибку в самой виртуальной машине. Бесконечный цикл просто потребляет процессор. Бесконечное выделение памяти должно просто вызвать OutOfMemoryError в хорошо построенной JVM. Это, вероятно, вызовет проблемы для других потоков, но хорошая JVM все равно не должна давать сбой.

Если вы можете найти ошибку в исходном коде виртуальной машины и, например, вызвать ошибку сегментации при использовании памяти реализацией виртуальной машины, то вы действительно можете ее аварийно завершить.

В книге Джона Мейера Виртуальная машина Java есть пример серии инструкций байт-кода, которые вызвали дамп ядра JVM. Я не могу найти свой экземпляр этой книги. Если у кого-то есть, пожалуйста, найдите его и опубликуйте ответ.

Я бы не назвал выброс OutOfMemoryError или StackOverflowError сбоем. Это обычные исключения. Есть 3 способа действительно вывести виртуальную машину из строя:

1. Использование JNI и сбой в машинном коде.
2. Если диспетчер безопасности не установлен, вы можете использовать отражение для сбоя виртуальной машины. Это зависит от виртуальной машины, но обычно виртуальная машина хранит кучу указателей на собственные ресурсы в частных полях (например, указатель на объект собственного потока хранится в длинном поле в java.lang.Thread). Просто измените их через отражение, и виртуальная машина рано или поздно выйдет из строя.
3. На всех виртуальных машинах есть ошибки, поэтому вам просто нужно активировать их.

Для последнего метода у меня есть небольшой пример, который спокойно приведет к сбою виртуальной машины Sun Hotspot:

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

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

Это приводит к переполнению стека в GC, поэтому вы не получите StackOverflowError, а получите настоящий сбой, включая файл hs_err *.

Если вы определяете сбой как прерывание процесса из-за необработанной ситуации (т. Е. Отсутствия исключения или ошибки Java), это невозможно сделать изнутри Java (если у вас нет разрешения на использование класса sun.misc.Unsafe). В этом весь смысл управляемого кода.

Типичные сбои в машинном коде происходят из-за отмены ссылки указателей на неправильные области памяти (нулевой адрес или неправильно выровненный). Другим источником могут быть недопустимые машинные инструкции (коды операций) или необработанные сигналы из библиотек или вызовов ядра. Оба могут быть запущены, если в JVM или системных библиотеках есть ошибки.

Например, JIT-код (сгенерированный), собственные методы или системные вызовы (графический драйвер) могут иметь проблемы, приводящие к реальным сбоям (довольно часто возникал сбой, когда вы использовали функции ZIP, и им не хватало памяти). В этих случаях обработчик сбоя JVM срабатывает и сбрасывает состояние. Он также может сгенерировать файл ядра ОС («Доктор Ватсон» в Windows и дамп ядра в * nix).

В Linux / Unix вы можете легко вызвать сбой JVM, отправив сигнал запущенному процессу. Примечание: вы не должны использовать для этого SIGSEGV, поскольку Hotspot улавливает этот сигнал и в большинстве случаев повторно генерирует его как NullPointerException. Так что лучше прислать SIGBUS например.

на winxpsp2 w / wmp10 jre6.0_7

Desktop.open (uriToAviOrMpgFile)

Это приводит к тому, что порожденный поток бросает неперехваченный Throwable и приводит к сбою точки доступа.

YMMV

вот подробное объяснение того, что вызывает дамп ядра JVM (то есть сбой): http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_17534

Я делаю это сейчас, но не совсем уверен, как ... :-) JVM (и мое приложение) иногда просто полностью исчезают. Ошибок не выдается, ничего не регистрируется. Мгновенно без предупреждения переходит из режима работы в состояние отсутствия работы.

Если вы хотите притвориться, что у вас закончилась память, вы можете сделать

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

Я знаю несколько способов вызвать дамп файла ошибки JVM, вызвав собственные методы (те, которые встроены), но, вероятно, лучше всего, если вы не знаете, как это сделать. ;)

JNI - большой источник сбоев. Вы также можете выйти из строя, используя интерфейс JVMTI, поскольку он также должен быть написан на C / C++.

Неисправное оборудование может привести к сбою любой программы. Однажды у меня случился воспроизводимый сбой приложения на одном компьютере, когда он работал нормально на других машинах с той же настройкой. Оказывается, у этой машины была неисправная оперативная память.

Использовать это:

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();
    }
}

Этот класс должен находиться в пути к загрузочному классу, потому что он использует доверенный код, поэтому запустите его следующим образом:

java -Xbootclasspath/p:. Crash

РЕДАКТИРОВАТЬ: упрощенная версия с предложением напористого:

Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
Unsafe unsafe = (Unsafe) f.get(null);
unsafe.putAddress(0, 0);

Этот код приведет к сбою JVM неприятными способами

import sun.dc.pr.PathDasher; 

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

Если вы хотите вывести JVM из строя - используйте следующее в Sun JDK 1.6_23 или ниже:

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

Это связано с ошибка в Sun JDK, который также присутствует в OpenJDK. Это исправлено начиная с Oracle JDK 1.6_24.

Я пришел сюда, потому что я также столкнулся с этим вопросом в Страстный программист, написанном Чадом Фаулером. Для тех, у кого нет доступа к копии, вопрос оформлен как своего рода фильтр / тест для кандидатов, проходящих собеседование на должность, требующую «действительно хороших программистов на Java».

В частности, он спрашивает:

How would you write a program, in pure Java, that would cause the Java Virtual Machine to crash?

Я программировал на Java более 15 лет и нашел этот вопрос одновременно и озадачивающим, и несправедливым. Как отмечали другие, Java, как управляемый язык, специально разработан не разбиться. Конечно, всегда есть ошибки JVM, но:

1. После 15 с лишним лет JRE производственного уровня это редкость.
2. Любые подобные ошибки, скорее всего, будут исправлены в следующем выпуске, так какова вероятность того, что вы, как программист, столкнетесь и вспомните подробности текущего набора JRE show-stoppers?

Как отмечали другие, некоторый собственный код через JNI - верный способ вывести JRE из строя. Но автор специально упомянул на чистой Java, так что этого нет.

Другой вариант - подавать фиктивные байтовые коды JRE; Достаточно просто выгрузить некоторые двоичные данные мусора в файл .class и попросить JRE запустить его:

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

Это считается? Я имею в виду, что сама JRE не разбилась; он правильно обнаружил поддельный код, сообщил о нем и завершил работу.

Это оставляет нам самые очевидные виды решений, такие как продувка стека через рекурсию, исчерпание памяти кучи через выделение объектов или просто выброс RuntimeException. Но это просто приводит к завершению JRE с StackOverflowError или аналогичным исключением, которое, опять же, на самом деле не авария.

Так что же осталось? Я действительно хотел бы услышать, что автор действительно имел в виду как правильное решение.

Обновлять: Чад Фаулер ответил здесь.

PS: в остальном это отличная книга. Я поднял его для моральной поддержки во время изучения Ruby.

кратчайший путь :)

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

В прошлый раз, когда я пробовал это сделать:

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();
        }
    }
}

Первая часть сгенерированного файла журнала:

#
# 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

Если «Сбой» - это что-то, что прерывает нормальное завершение jvm / программы, то это может сделать необработанное исключение.

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
  }

Итак, это смотря какой тип АВАРИИ ?!

Не сбой, но ближе к сбою, чем принятый ответ об использовании System.exit

Вы можете остановить JVM, позвонив

Runtime.getRuntime().halt( status )

Согласно документам: -

"this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled".

Самый короткий? Используйте класс Robot, чтобы вызвать CTRL + BREAK. Я заметил это, когда пытался закрыть свою программу, не закрывая консоль (у нее не было функции выхода).

Если вы создаете процесс потока, который бесконечно порождает больше потоков (которые порождают больше потоков, которые ...), вы в конечном итоге вызовете ошибку переполнения стека в самой JVM.

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();
    }
}

Это дало мне результат (через 5 минут следите за своим бараном)

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:
# 

Это считается?

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

Работает только для Linux и с Java 9.

По какой-то причине я не понимаю, ProcessHandle.current().destroyForcibly(); не убивает JVM и выдает java.lang.IllegalStateException с сообщением уничтожение текущего процесса не допускается.

Если под «крахом» вы подразумеваете резкое прерывание работы JVM, например, заставило бы JVM записывать в свой hs_err_pid% p.log, вы можете сделать это таким образом.

Установите для-Xmx arg крошечное значение и скажите JVM, что нужно вызвать сбой в outofmemory:

 -Xmx10m -XX:+CrashOnOutOfMemoryError

Чтобы было ясно, без второго аргумента выше это просто приведет к jvm прекращение с OutOfMemoryError, но это не приведет к "сбою" или внезапному прерыванию jvm.

Этот метод оказался полезным, когда я пытался протестировать аргумент JVM -XX: ErrorFile, который определяет, где должен быть записан такой журнал hs_err_pid. Я нашел этот пост здесь, пытаясь найти способы вызвать такой сбой. Когда позже я обнаружил, что вышеперечисленное работает как самый простой для меня, я хотел добавить его в список здесь.

Наконец, FWIW, если кто-то может проверить это, когда у них уже есть значение -Xms, установленное в ваших аргументах (на какое-то большее значение, чем указано выше), вы захотите удалить или изменить это также, иначе вы получите не сбой, а просто сбой запуска jvm с сообщением «Начальный размер кучи установлен на большее значение, чем максимальный размер кучи». (Это было бы не очевидно, если бы JVM запускалась как служба, например, с некоторыми серверами приложений. Опять же, это укусило меня, поэтому я хотел поделиться им.)

Возникла эта проблема при попытке реплицировать сбой JVM.

Jni работает, но его нужно настроить для разных платформ. В конце концов, я использую эту комбинацию для сбоя JVM

1. Запустите приложение с этими параметрами JVM -XX:+CrashOnOutOfMemoryError
2. Используйте long[] l = new long[Integer.MAX_VALUE]; для запуска OOM

Тогда JVM выйдет из строя и создаст журнал сбоев.