How do you crash a JVM?

Question

Newbie here... Also not sure whether the question belongs to a site that prefers questions that can be answered and not discussed. Still...

I was reading a book on programming skills wherein the author asks the interviewee, "How do you crash a JVM?" I thought that you could do so by writing an infinite for-loop that would eventually use up all the memory. But that was just my suggestion... I am not so strong in Java, so I thought I'd post it here...

Anybody has any idea?

Answer 1

JNI. In fact, with JNI, crashing is the default mode of operation. You have to work extra hard to get it not to crash.

Answer 2

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

Answer 3

Depends on what you mean by crash.

You can do an infinite recursion to make it run out of stack space, but that'll crash "gracefully". You'll get an exception, but the JVM itself will be handling everything.

You can also use JNI to call native code. If you don't do it just right then you can make it crash hard. Debugging those crashes is "fun" (trust me, I had to write a big C++ DLL that we call from a signed java applet). :)

Answer 4

If you change that infinite for loop to a recursive call to the same function, then you would get a stack overflow exception:

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

public void causeStackOverflow() {
    causeStackOverflow();
}

Answer 5

The closest thing to a single "answer" is System.exit() which terminates the JVM immediately without proper cleanup. But apart from that, native code and resource exhaustion are the most likely answers. Alternatively you can go looking on Sun's bug tracker for bugs in your version of the JVM, some of which allow for repeatable crash scenarios. We used to get semi-regular crashes when approaching the 4 Gb memory limit under the 32-bit versions (we generally use 64-bit now).

Answer 6

A perfect JVM implementation will never crash.

To crash a JVM, aside from JNI, you need to find a bug in the VM itself. An infinite loop just consumes CPU. Infinitely allocating memory should just cause OutOfMemoryError's in a well built JVM. This would probably cause problems for other threads, but a good JVM still should not crash.

If you can find a bug in the source code of the VM, and for example cause a segmentation fault in the memory usage of the implementation of the VM, then you can actually crash it.

Answer 7

The book Java Virtual Machine by Jon Meyer has an example of a series of bytecode instructions that caused the JVM to core dump. I can't find my copy of this book. If anyone out there has one please look it up and post the answer.

Answer 8

I wouldn't call throwing an OutOfMemoryError or StackOverflowError a crash. These are just normal exceptions. To really crash a VM there are 3 ways:

1. Use JNI and crash in the native code.
2. If no security manager is installed you can use reflection to crash the VM. This is VM specific, but normally a VM stores a bunch of pointers to native resources in private fields (e.g. a pointer to the native thread object is stored in a long field in java.lang.Thread). Just change them via reflection and the VM will crash sooner or later.
3. All VMs have bugs, so you just have to trigger one.

For the last method I have a short example, which will crash a Sun Hotspot VM quiet nicely:

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

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

This leads to a stack overflow in the GC so you will get no StackOverflowError but a real crash including a hs_err* file.

Answer 9

If you define a crash as an unhandled problem (i.e. no Java Exception or Error), then this can not be done from within Java (this is the whole point of managed code). Typical crashes in native code happen by dereferencing pointers to wron memory areas (like Nullpointer) or illegal Opcodes. Another source could be failed syscalls (but this is normally related to hardware problems).

JVMs (especially JIT compiler) could have bugs. Also external libraries or divers (especially graphics drivers) can have problems leading to real crashes. Also Native code can make a JVM crash. In all cases the crash handler of the JVM kicks in and dumps the state. It could also be a native core file (Dr. Watson on Windows).

On Linux/Unix you can easyly make a JVM crash by sending it a Signal to the running process. Note: you should not use "SIGSEGV" for this, since Hotspot catches this signal and rethrows it as a NullPointerException in most places. So it is better to send a SIGBUS for example.

Answer 10

on winxpsp2 w/wmp10 jre6.0_7

Desktop.open(uriToAviOrMpgFile)

This causes a spawned thread to throw an uncaught Throwable and crashes hotspot

YMMV

Answer 11

here is a detailed explanation on what causes JVM to core dump (i.e. crash): http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_17534

Answer 12

I'm doing it now, but not entirely sure how... :-) JVM (and my app) sometimes just completely disappear. No errors thrown, nothing logged. Goes from working to not running at all instantly with no warning.

Answer 13

If you want to pretend you have run out of memory you can do

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

I know a couple of way to cause the JVM dump an error file by calling native methods (ones which are built in), but its probably best you not know how to do this. ;)

Answer 14

JNI is a large source of crashes. You can also crash using the JVMTI interface since that needs to be written in C/C++ as well.

Answer 15

Broken hardware can crash any program. I once had an app crash reproducably on a specific machine while running fine on other machines with the exact same setup. Turns out that machine had faulty RAM.

Answer 16

Use this:

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

This class must be on the boot classpath because it is using trusted code,so run like this:

java -Xbootclasspath/p:. Crash

Answer 17

This code will crash the JVM in nasty ways

import sun.dc.pr.PathDasher; 

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