Crashing your JVM

Thorough testing can be harmful as we discovered recently. Extending our test coverage led us to a several-hours debugging session 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 flavours kept crashing, Windows box ran the test just fine, alerting us as expected via the “No such process” message.

What we learned 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.
 

Reference: Crashing your JVM from our JCG partner Nikita Salnikov Tarnovski at the Plumbr Blog blog.
Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


6 × = thirty



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close