2015-11-16 19 views
16

Ich bekomme dieses Stacktrace, wenn ich versuche, einen Heap-Dump von einem laufenden Java-Prozess zu nehmen. Was verursacht dies und was muss ich tun, um einen richtigen Heapspeicherauszug zu erstellen?Java-Heap-Dump-Fehler - Metadaten scheinen nicht polymorph zu sein

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 

Umwelt: CentOS 64 Bit, Java OpenJDK Runtime Environment (build 1.8.0_31-b13) OpenJDK 64-Bit Server VM (Build 25.31-b07, mixed mode)

usign ps die Java zu sehen Version, die verwendet wird:

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java 

Mein erster Versuch war:

/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 

das bekam 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 lief ich mit der -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 
+1

Sind Sie sicher, dass Sie die gleiche Version von Java verwenden und sie sind beide 64 Bit? Und es mit dem gleichen Benutzer laufen? – biziclop

+0

Vielleicht im Zusammenhang mit https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1417962 – RobAu

Antwort

15

Ok, ich habe es gefunden.

Ich habe den jmap Befehl als root ausgeführt, aber ich musste als der Benutzer ausführen, der den Java-Prozess startete.

In meinem Fall:

sudo -u robau ./jmap -dump:format=b,file=/tmp/dump.bin 14984 

Scheint diesen JDK Fehler bezogen werden: https://bugs.openjdk.java.net/browse/JDK-8075773

+1

gibt es eine schöne integrierte Heap-Dateianalysator jhat /tmp/dump.bin, die Heap-Dump zu analysieren Datei und expose Ergebnisse auf Port 7000 –

6

ich auf CentOS dieses Problem hatte, auch wenn als Benutzer ausgeführt wird, der den Prozess gestartet hat. Was es für mich gelöst hat, war die Installation des debuginfo-Pakets, das dem Paket entspricht, das das jmap-Dienstprogramm liefert.

Um das debuginfo-Paket zu installieren, siehe this answer (ersetzen Sie Ihr Java-Paket für glibc). Dazu muss das debuginfo-install-Dienstprogramm aufgerufen/verwendet werden und sichergestellt werden, dass CentOS-Debuginfo.repo korrekt eingerichtet und aktiviert ist.

+0

Das gleiche Problem auf CentOS 7 zu. Ich habe das Paket von http://debuginfo.centos.org/7/x86_64/ heruntergeladen und manuell mit 'rpm -ivh java-1.8.0-openjdk-debuginfo * .rpm' installiert. Vielen Dank! – xonya

8

Ich stieß auf das gleiche Problem mit dem Versuch, jmap auf einer AWS ElasticBeanstalk-Instanz auszuführen. Der Befehl, der es befestigt war

sudo debuginfo-install java-1.8.0-openjdk-devel

BTW, jmap auf der AWS ElasticBeanstalk Instanz mit dem Befehl installiert wurde

sudo yum install java-1.8.0-openjdk-devel-1.8.0.91-0.b14.10.amzn1.x86_64