How do you crash a JVM?

Question

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

Answer 1

If by "crash" you mean an abrupt abort of the JVM, such as would cause the JVM to write out to its hs_err_pid%p.log, you can do it this way.

Set the-Xmx arg to a tiny value and tell the JVM to force a crash on outofmemory:

 -Xmx10m -XX:+CrashOnOutOfMemoryError

To be clear, without the second arg above, it would just result in the jvm terminating with an OutOfMemoryError, but it would not "crash" or abruptly abort the jvm.

This technique proved helpful when I was trying to test the JVM -XX:ErrorFile arg, which controls where such an hs_err_pid log should be written. I had found this post here, while trying to find ways to force such a crash. When I later found the above worked as the easiest for my need, I wanted to add it to the list here.

Finally, FWIW, if anyone may test this when they already have an -Xms value set in your args (to some larger value than above), you'll want to remove or change that also, or you will get not a crash but simply a failure of the jvm to start, reporting "Initial heap size set to a larger value than the maximum heap size". (That wouldn't be obvious if running the JVM as service, such as with some app servers. Again, it bit me, so I wanted to share it.)

Answer 2

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 3

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

EDIT: Simplified version with pushy's suggestion:

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

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

If a 'Crash' is anything that interrupts the jvm/program from normal termination, then an Un-handled exception could do this.

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
  }

So, it depends on what type of CRASH ?!

Answer 6

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). :)