Crashing your JVM

November 26, 2013 by Vladimir Šor

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.

Can't figure out what causes your OutOfMemoryError? Read more

ADD COMMENT

COMMENTS

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)”

unserializable

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.

Roman

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,

cdman83

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.

Roman

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.

iNikem

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

Roman

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.

Roman

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.

paul

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…

Guest

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

iNikem

Can't figure out what causes your OutOfMemoryError? Read more

Latest
Recommended
You cannot predict the way you die
When debugging a situation where systems are failing due to the lack of resources, you can no longer count on anything. Seemingly unrelated changes can trigger completely different messages and control flows within the JVM. Read more
Tuning GC - it does not have to be that hard
Solving GC pauses is a complex task. If you do not believe our words, check out the recent LinkedIn experience in garbage collection optimization. It is a complex and tedious task, so we are glad to report we have a whole lot simpler solution in mind Read more
Building a nirvana
We have invested a lot into our continuous integration / delivery infrastructure. As of now we can say that the Jenkins-orchestrated gang consisting of Ansible, Vagrant, Gradle, LiveRebel and TestNG is something an engineer can call a nirvana. Read more
Creative way to handle OutOfMemoryError
Wish to spend a day troubleshooting? Or make enemies among sysops? Registering pkill java to OutOfMemoryError events is one darn good way to achieve those goals. Read more