Errore di dump heap su Centos 64bit e openjdk 7

Sto provando a generare un dump dell'heap sul mio computer che esegue un glassfish 3.1.2 utilizzando un java open-jdk7.Errore di dump heap su Centos 64bit e openjdk 7

sto usando il seguente comando:

jmap -dump:live,format=b,file=dump.t -F 24935

Ma continuo a ricevere questo errore:

Attaching to process ID 24935, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 23.7-b01 
Dumping heap to dump.t ... 
Exception in thread "main" java.lang.reflect.InvocationTargetException 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
     at java.lang.reflect.Method.invoke(Method.java:601) 
     at sun.tools.jmap.JMap.runTool(JMap.java:197) 
     at sun.tools.jmap.JMap.main(JMap.java:128) 
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: Expecting GenCollectedHeap, G1CollectedHeap, or ParallelScavengeHeap, but got sun.jvm.hotspot.gc_interface.CollectedHeap 
     at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) 
     at sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:605) 
     at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:244) 
     at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51) 
     at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:416) 
     at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:56) 
     at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) 
     at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77) 
     ... 6 more

Qui è la mia versione di Java:

[ufasoli]$ java -version 
java version "1.7.0_19" 
OpenJDK Runtime Environment (rhel-2.3.9.1.el6_4-x86_64) 
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

L'esatta CentOS versione è:

CentOS release 6.3 (Final)

Qualche idea?

fonte

2013-05-16 ufasoli

È stato riparato? sto affrontando lo stesso – Peter

in realtà sì, ma temo di non ricordare più esattamente quello che ho fatto. Quello che posso dirti è che ha qualcosa a che fare con le opzioni di comando – ufasoli

questo distacco così io non continuo a dimenticare la soluzione me: P

Questo funziona:

$ sudo /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/bin/jmap -dump:format=b,file=./testDump 8894 
Dumping heap to /home/<snip>/testDump ... 
Heap dump file created

Questo fallisce:

$ sudo /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51.x86_64/bin/jmap -heap:format=b  8894 
Attaching to process ID 8894, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 24.45-b08 
Dumping heap to heap.bin ... 
Exception in thread "main" java.lang.reflect.InvocationTargetException 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:606) 
at sun.tools.jmap.JMap.runTool(JMap.java:197) 
at sun.tools.jmap.JMap.main(JMap.java:128) 
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: Expecting GenCollectedHeap, G1CollectedHeap, or ParallelScavengeHeap, but got sun.jvm.hotspot.gc_interface.CollectedHeap 
at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) 
at sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:604) 
at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:244) 
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(AbstractHeapGraphWriter.java:51) 
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:416) 
at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:56) 
at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) 
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77) 
... 6 more

fonte

2014-04-21 06:32:49

quelli non hanno più l'opzione -F ? – rogerdpack

Provare a eseguire senza l'opzione -F

fonte

2013-09-24 14:22:55 LaSombra

sfortunatamente senza -FI get '12829: Impossibile aprire il file socket: processo di destinazione non risponde o VM HotSpot non caricata' – rogerdpack

Secondo http://iamadevops.tumblr.com/post/109281462774/howto-fix-jmap-f-dump-format-b-on-archlinux la soluzione è "ricompilare java con il debug sy i simboli non sono stati eliminati ".

fonte

2015-04-08 21:35:14 rogerdpack

Non c'è bisogno di farlo - invece è sufficiente eseguire il comando come l'utente * exact * (nota: * not * root) che ha avviato il processo dovrebbe funzionare – kittylyst

Se non si ha la possibilità di ricompilare il codice con i simboli di debug e si dispone di JMX configurato, è possibile provare a generare un heapdump con VisualVM.

Per questo, avviare VisualVM e connettersi all'host tramite JMX. Nella parte superiore del pannello del monitor, vedrai un pulsante "Head Dump".

Il formato è il file di dump sarà diverso, ma sarà possibile aprirlo con jhat o VisualVM.

fonte

2015-06-09 11:02:18

questo potrebbe essere correlato, ma su alcune versioni di Java, sembra che ci sia una leggera stranezza sulla recente/Centos RHEL (versione> = 6), per cui jmap, jstack e gli amici hanno bisogno di essere eseguito come l'esatto utente che avviato il processo - e non funzionerà se eseguito come root.

un comando come:

sudo -H -u <USERNAME WHO STARTED PROCESS> jmap -histo <PID>

dovrebbe prendersi cura di esso, a patto di avere adeguati privilegi sudo.

fonte

2016-12-30 15:01:44 kittylyst

Errore di dump heap su Centos 64bit e openjdk 7

risposta

Problemi correlati