Hi all,
I'm having trouble using jmap(1) to create an hprof heap dump from a
core file on Oracle Solaris with version 8 of the Oracle JDK. This
worked with version 7 of the Oracle JDK:
$ cat Sleep.java
public class Sleep {
public static void main(String[] args) throws InterruptedException {
Thread.sleep(300000);
}
}
$ /opt/jdk1.7.0_76/bin/javac Sleep.java
$ /opt/jdk1.7.0_76/bin/java Sleep &
[1] 1348
$ gcore 1348
gcore: core.1348 dumped
$ jmap -dump:format=b,file=core1348.hprof /opt/jdk1.7.0_76/bin/java \
core.1348
Attaching to core core.1348 from executable /opt/jdk1.7.0_76/bin/java
Debugger attached successfully.
Client compiler detected.
JVM version is 24.76-b04
Dumping heap to core1348.hprof ...
Heap dump file created
This also works with version 8 of the Oracle JDK when lambdas are not
used:
$ /opt/jdk1.8.0_40/bin/javac Sleep.java
$ /opt/jdk1.8.0_40/bin/java Sleep &
[1] 1398
$ gcore 1398
gcore: core.1398 dumped
$ jmap -dump:format=b,file=core1398.hprof /opt/jdk1.8.0_40/bin/java \
core.1398
Attaching to core core.1398 from executable /opt/jdk1.8.0_40/bin/java
Debugger attached successfully.
Server compiler detected.
JVM version is 25.40-b25
Dumping heap to core1398.hprof ...
Heap dump file created
However, this no longer works with version 8 of the Oracle JDK when
lambdas are used:
$ cat LambdaSleep.java
import java.util.Arrays;
public class LambdaSleep {
public static void main(String[] args) throws InterruptedException {
String[] words = new String[] { "longer", "short" };
Arrays.sort(words, (first, second) ->
Integer.compare(first.length(), second.length()));
Thread.sleep(300000);
}
}
$ javac LambdaSleep.java
$ java LambdaSleep &
[1] 1416
$ gcore 1416
gcore: core.1416 dumped
$ jmap -dump:format=b,file=core1416.hprof /opt/jdk1.8.0_40/bin/java \
core.1416
Attaching to core core.1416 from executable /opt/jdk1.8.0_40/bin/java
Debugger attached successfully.
Server compiler detected.
JVM version is 25.40-b25
Dumping heap to core1416.hprof ...
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:497)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: can not get class
data for LambdaSleep$$Lambda$10x0000000100071828
at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance(
HeapHprofBinWriter.java:803)
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(
AbstractHeapGraphWriter.java:95)
at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(
ObjectHeap.java:353)
at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:171)
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(
AbstractHeapGraphWriter.java:51)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(
HeapHprofBinWriter.java:433)
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
Note that this problem only occurs when creating an hprof heap dump from
a core file. It doesn't occur when creating an hprof heap dump from a
live process:
$ java LambdaSleep &
[1] 1421
$ jmap -dump:format=b,file=core1421.hprof 1421
Dumping heap to core1421.hprof ...
Heap dump file created
I have reproduced this issue with Java version 1.8.0_40 (JVM version
25.40-b25) on the following platforms:
Oracle Solaris 10 9/10 s10x_u9wos_14a X86
Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
Oracle Solaris 11.1 X86
Oracle Solaris 11.2 X86
I found a similar issue in the JDK bug system (JDK-8044416), but the
last update there stated that JDK-8044416 "is about the -F
functionality" and to "please file a different bug for problems when
running without -F." I am running without -F, but I haven't been able to
find another bug that tracks the issue described above.
An update would be appreciated, as this bug greatly hampers our ability
to debug memory leaks in production.
Thanks,
Basil
