2017-01-20 7 views
2

Actuellement, j'ai un fichier core-dump et je voudrais extraire le heap-dump. Tout ce que j'ai essayé, je reçois toujours le message d'erreur suivant:Extraction de heap-dump (hprof) à partir de Core-dump

[email protected]:~$ sudo /opt/java-MyApp/bin/jmap -dump:format=b,file=my-file.hprof /opt/java-MyApp/bin/java /home/god/tmp/core 
[sudo] password for god: 
Attaching to core /home/god/tmp/my-app-core-dump from executable /opt/java-MyApp/bin/java, please wait... 
Error attaching to core file: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) 
sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) 
    at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:411) 
    at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305) 
    at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:156) 
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:191) 
    at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) 
    at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83) 
    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:497) 
    at sun.tools.jmap.JMap.runTool(JMap.java:201) 
    at sun.tools.jmap.JMap.main(JMap.java:130) 

Si je tente d'ouvrir le noyau avec gdb, il fonctionne comme un charme:

gdb --core core 
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 
Copyright (C) 2016 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "x86_64-linux-gnu". 
Type "show configuration" for configuration details. 
For bug reporting instructions, please see: 
<http://www.gnu.org/software/gdb/bugs/>. 
Find the GDB manual and other documentation resources online at: 
<http://www.gnu.org/software/gdb/documentation/>. 
For help, type "help". 
Type "apropos word" to search for commands related to "word". 
[New LWP 11241] 
[New LWP 11242] 
[New LWP 11243] 
[New LWP 11244] 
[New LWP 11245] 
... 
[New LWP 23423] 
[New LWP 30560] 
[New LWP 11240] 
Core was generated by `/opt/java-MyApp/bin/java -Djava.util.logging.config.file=/opt/MyAp'. 
#0 0x0000003c838cc0a6 in ??() 
[Current thread is 1 (LWP 11241)] 
(gdb) 

De toutes les choses que j'ai lu, je devrais assurez-vous que la JVM est installée sur le même chemin et la même version que celle utilisée lors du vidage du core en utilisant {{gcore}}. Étant fait que tout ce que j'ai besoin de faire est d'appeler jmpa avec ce jvm exacte:

sudo $JVM_USED_WHILE_GCORE_HOME/bin/jmap -dump:format=b,file=$OUTPUT_HPROF_FILE $JVM_USED_WHILE_GCORE_HOME/bin/java $CORE_FILE_PATH 

Y at-il quelque chose qui me manque? Pourquoi est-ce que j'obtiens constamment le message d'erreur "Impossible de trouver le symbole" gHotSpotVMTypes "in remote process"?

+0

Sous gdb, pouvez-vous trouver le symbole 'gHotSpotVMTypes'? – apangin

+0

ne sont pas toutes les versions OpenJDK? Ou que puis-je vérifier? –

+0

Tapez 'p gHotSpotVMTypes' sous gdb – apangin

Répondre

1

Le problème était assez simple. Le chemin /opt/java-MyApp/bin/java était un symlink, une fois que j'ai recréé la structure comme j'avais sur la machine utilisée pour générer le core-dump, cela a fonctionné comme un charme. Il semble que les bibliothèques sont utilisées par son chemin canonique.