Crashing your JVM

Thorough testing can be harmful as we discovered recently. Extending our test coverage led us to a debugging session of several hours caused by just one line of code. What made the debugging particularly unpleasant was the fact that the code crashed not just the JVM it was deployed to but also the virtual and/or physical machine underneath.

So, run the following at your own risk. Note that you have to provide the tools.jar in your classpath both for compilation and run-time.

public class Crash {
  public static void main(String... args) throws Exception {
    com.sun.tools.attach.VirtualMachine.attach("-1");
  }
}

The code is really simple. We are trying to attach ourselves to an already existing Java process specifying -1 as the process id. Instead of failing nicely you get something similar to the blue screen of death.

An interesting insight into the crash – this is pretty much the only case I recall admitting Windows being superior to the Mac OS X or Linux. While the Macs and different Linux flavors kept crashing, Windows box ran the test just fine, alerting us as expected via the “No such process” message.

What did we learn from the case? First – having the JVM sandbox present protecting the OS from your crazy attempts to commit suicide is a great thing in itself. Another lesson we re-learned was that – even with all the modern runtime debugging tools there are still cases where you need to turn back to the roots and debug via the good old divide-and-conquer method.