Almost every Java developer knows about jmapand jstack tools that come with the JDK. These provide functionality to extract heap and thread information of a running JVM instance. Easy.

What if there’s a running JVM that has produced a deadlock and you want to take a thread dump while the process is running? You go in and run the following.

jstack pid >> thread_dump.txt

Turns out the system doesn’t know what jstack is. You don’t panic, but you get a tiny sensation at the back of your head saying you’re not leaving early this Friday.

What has happened is the running JVM is based on a JRE and not a JDK. The JRE is a minimal runtime that doesn’t pack the monitoring and analysis tools that the JDK packs.

So what are our options here?

  1. Stop the process. Download JDK, start the process again on top of JDK and hope the deadlock happens again. Nope.
  2. Start JVisualVM on your laptop and hope the process has JMX enabled. Nope.
  3. tools.jarTO THE RESCUE!

Functionalities such as jstack are implemented in the tools.jar file which is packed inside <JDK_HOME>/lib folder. We can use this to invoke the JStackclass and get a thread dump of the running process.

So we march on to download and extract the JDK, and then to run the following.

java -classpath <JDK_HOME>/lib/tools.jar sun.tools.jstack.JStack <pid> >> thread_dump.txt

..and come across the following error.

Exception in thread "main" java.lang.UnsatisfiedLinkError: no attach in java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
        at java.lang.Runtime.loadLibrary0(Runtime.java:870)
        at java.lang.System.loadLibrary(System.java:1122)
        at sun.tools.attach.LinuxVirtualMachine.<clinit>(LinuxVirtualMachine.java:342)
        at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
        at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
        at sun.tools.jstack.JStack.runThreadDump(JStack.java:163)
        at sun.tools.jstack.JStack.main(JStack.java:116)

Darn it! Spoiled again!

How do we solve this? The above error is caused when the process can’t find libattach.so file which is related to the Dynamic Attachfunction related to JStack. Setting the following environment variable will help the JVM to find the libattach.so file.

export LD_LIBRARY_PATH=<JDK_HOME>/jre/lib/amd64/

Now let’s run JStack again, this time with results!

java -classpath <JDK_HOME>/lib/tools.jar sun.tools.jstack.JStack <pid> >> thread_dump.txt

Now that we have the thread dump, we move on to the heap dump. The tool we normally use is jmap but that too is not available on the JRE. So what? We can use the binary in the JDK’s bin directory right? right?

root@snowflake1 latest]# <JDK_HOME>/bin/jmap -heap <pid>
Attaching to process ID <pid>, please wait…
Error attaching to process: sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.102-b14. Target VM is 25.91-b14
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.102-b14. Target VM is 25.91-b14
 at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:435)
 at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305)
 at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
 at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
 at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
 at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:49)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at sun.tools.jmap.JMap.runTool(JMap.java:201)
 at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.102-b14. Target VM is 25.91-b14
 at sun.jvm.hotspot.runtime.VM.checkVMVersion(VM.java:227)
 at sun.jvm.hotspot.runtime.VM.<init>(VM.java:294)
 at sun.jvm.hotspot.runtime.VM.initialize(VM.java:370)
 at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:431)
 … 11 more

Nope! Unless you match the JDK version with theexact version the JRE is at you get the above issue (which is pretty self-explanatory). So we download the JDK of the JRE of on top our process is running and run jmap again.

<JDK_HOME>/bin/jmap -dump:file=heap_dump.hprof <pid>

Now you go home, a proud developer who took the first dump out of the running server. And no that does not sound good on a different context.

Written on September 7, 2016 by chamila de alwis.

Originally published on Medium