I get this Stacktrace when trying to take a heap dump from a running Java process. What causes this and what do I have to do to make a proper heap dump?
Dumping heap to dump.bin ... Exception in thread "main" java.lang.reflect.InvocationTargetException 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:483) at sun.tools.jmap.JMap.runTool(JMap.java:201) at sun.tools.jmap.JMap.main(JMap.java:130) Caused by: java.lang.InternalError: Metadata does not appear to be polymorphic at sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:278) at sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) at sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:68) at sun.jvm.hotspot.memory.DictionaryEntry.klass(DictionaryEntry.java:71) at sun.jvm.hotspot.memory.Dictionary.classesDo(Dictionary.java:66) at sun.jvm.hotspot.memory.SystemDictionary.classesDo(SystemDictionary.java:190) at sun.jvm.hotspot.memory.SystemDictionary.allClassesDo(SystemDictionary.java:183) at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:942) at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:427) at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83) ... 6 more
Environment: CentOS 64 bit, Java OpenJDK Runtime Environment (build 1.8.0_31-b13) OpenJDK 64-Bit Server VM (build 25.31-b07, mixed mode)
Using ps
to see the java version that is used:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java
My first try was:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/bin/jmap -dump:format=b,file=dump.bin 14984
That got me :
14984: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding
So I ran with the -F
option
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/bin/jmap -F -dump:format=b,file=dump.bin 14984
This command sends a request to the JVM to generate a heap dump. One of its parameters is GC.heap_dump. It is as shown below: jcmd <pid> GC.heap_dump <file-path> <pid> - Process id of java process <file-path> - Path where the heap dump is to be generated
When you open a heap dump, Java VisualVM displays the Summary view by default. The Summary view displays the running environment where the heap dump was taken and other system properties.
As a rule of thumb, we should remember to use the HeapDumpOnOutOfMemoryError option always when running Java applications. For other purposes, any of the other tools can be perfectly used as long as we keep in mind the unsupported status of jmap.
Java heap related issues can cause severe damage to your application that will directly result in poor end user experience. Care must be taken to tune the Heap related parameters that suit your application. Out of the box default parameters are not enough. Java Heap is the memory used by your application to create and store objects.
Ok, I found it.
I was running the jmap
command as root
, but I had to run as the user that started the java process.
In my case:
sudo -u robau ./jmap -dump:format=b,file=/tmp/dump.bin 14984
Seems to be related to this JDK bug: https://bugs.openjdk.java.net/browse/JDK-8075773
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With