Błąd zrzucania sterty Java - metadane nie wydają się polimorficzne

Question

Otrzymuję ten Stacktrace podczas próby pobrania zrzutu sterty z działającego procesu Java. Co powoduje to i co muszę zrobić, aby utworzyć odpowiedni zrzut sterty?

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 

Środowisko: CentOS 64 bit, Java OpenJDK Runtime Environment (build 1.8.0_31-B13) OpenJDK 64-bitowy serwer VM (build 25.31-B07, tryb mieszany)

usign ps zobaczyć java wersja, która jest używana:

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

Moja pierwsza próba była:

/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 

że dostał mi:

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 

Więc wpadłem z opcją

/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 

Answer 1

Ok -F, znalazłem go.

Uruchomiłem polecenie jmap jako root, ale musiałem uruchomić jako użytkownik, który uruchomił proces java.

W moim przypadku:

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

wydaje się być związane z tym JDK bug: https://bugs.openjdk.java.net/browse/JDK-8075773

Answer 2

miałem ten problem na CentOS nawet gdy działa jako użytkownik, który rozpoczął się proces. Rozwiązałem go, instalując pakiet debuginfo odpowiadający pakietowi dostarczającemu narzędzie jmap.

Aby zainstalować pakiet debuginfo, zobacz this answer (zastępując pakiet java dla glibc). Wymaga pobrania/użycia narzędzia debuginfo-install i upewnienia się, że CentOS-Debuginfo.repo jest poprawnie skonfigurowany i włączony.

Answer 3

Wystąpił ten sam problem z próbą uruchomienia programu jmap na instancji AWS ElasticBeanstalk. Polecenie to ustalone było

sudo debuginfo-install java-1.8.0-openjdk-devel

BTW, jmap został zainstalowany na przykład AWS ElasticBeanstalk z poleceniem

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