Splunk Completes Acquisition of Plumbr Learn more

To blog |

Crashing your JVM

November 26, 2013 by Vladimir Šor Filed under: Java

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 {

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.



Disappointingly, my Linux (debian-based, kernel 3.7-686, NX enabled)) did not crash. Using Oracle JDK 1.7.0(21&&45), it gave civilized response instead:

Exception in thread “main” com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded “at sun.tools.attach.LinuxVirtualMachine.(LinuxVirtualMachine.java:106)”


Why attach() ends up sending SIGQUIT?

Vladimir Šor

Because you terminate all processes in your environment. And if you have enough rights your system seems to be crashed. In reality some processes are still alive (for example, init) but you can’t do anything. It was tested on 2.6 kernel.


What I’m wondering about is why trying to attach to a process must start with sending SIGQUIT signal? This is not so obvious.

Vladimir Šor

I’m not sure what the exact answer is, but SIGQUIT is used for java to dump debugging information (stacktraces mainly, but also some memory details, lock details, etc). You can see this by doing kill -3 and watching the console of your java application,


How can you attach to a running process to communicate with it from another process? Only if this process you want to connect to has some interface for communication. You can initialize this interface during process startup or on demand. The second option is possible via signal sending. With signal mechanism you can notify external process (in this case jvm) about your intention to attach to it. It’s my assumption only. I’m not jvm developer.


You can attach via some standard protocol. E.g. RMI, JMX. The question is, how this particular protocol is implemented. So far I have see no reason, why attach mechanism in JVMTI should be implemented by sending signals.


>You can attach via some standard protocol. E.g. RMI, JMX.

Yes, technically it’s possible (and hide under the hood of jvm implementation and also OS specific). When these components must be loaded? If you never need to use Attach API why to load these components at startup? It makes more sense to initialize attach framework on demand. For this purpose you need to send signal to jvm you want attach to – to notify it about your intention. After that jvm initializes the attach framework to which you connect after. I can say in jdk 1.7 jvm doesn’t use any of these technologies (nor RMI, nor JMX). It’s all implemented in native code (libattach.so in linux).


When you call VirtualMachine.attach(“-1”) then you are essentially send syscall kill with signal SIGQUIT for pid equal to -1. From man: “If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init)”. What user you have used for testing? Try the same for user with more restrictive rights.


com.sun.* are propietary extensions from Sun/Oracle, they are not Java Standard. You can crash anything with faulted native system calls in any language/api.


Yeah. And also these proprietary sun extensions are present in all hotspot and openjdk installations, which represent a vast majority of JDK’s around the world.

Vladimir Šor

Have you tried it with different JVMs or only with HotSpot?

Nir Alfasi

HotSpot 6 and 7 across different patch versions.

Vladimir Šor

Test.java:3: error: package com.sun.tools.attach does not exist
With which version of Java ? “com.sun” seems to be old…


do you have tools.jar on your compile and run class path?