Bug 1010786
Summary: | jmap and jstack are not working with openjdk | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Liran Zelkha <lzelkha> | ||||
Component: | java-1.7.0-openjdk | Assignee: | Severin Gehwolf <sgehwolf> | ||||
Status: | CLOSED ERRATA | QA Contact: | OpenJDK QA <java-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.6 | CC: | ahughes, aph, asah, bazulay, bela.pesics, dbhole, iweiss, jvanek, lakagwu, lzelkha, ophers, schaudha, sgehwolf, svanoort, tlavigne, zzambers | ||||
Target Milestone: | rc | Keywords: | Reopened | ||||
Target Release: | 7.7 | ||||||
Hardware: | Unspecified | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | java-1.7.0-openjdk-1.7.0.201-2.6.16.4.el7 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1656996 1656997 (view as bug list) | Environment: | |||||
Last Closed: | 2019-08-06 13:02:56 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 1657863 | ||||||
Bug Blocks: | 1644888, 1656996, 1656997 | ||||||
Attachments: |
|
You don't give the exception thrown. Is it the same as this? Attaching to process ID 16089, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24.0-b56 Deadlock Detection: java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007fc980001000 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread) at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162) at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150) at sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) 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.jstack.JStack.runJStackTool(JStack.java:136) at sun.tools.jstack.JStack.main(JStack.java:102) Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x00007fc980001000 at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158) ... 15 more Can't print deadlocks:Unable to deduce type of thread from address 0x00007fc980001000 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread) Exception from jmap -heap: 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: java.lang.RuntimeException: unknown CollectedHeap type : class sun.jvm.hotspot.gc_interface.CollectedHeap at sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:146) at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:40) ... 6 more For jstack - it is as published above. Yes, jmap is as above for me too. It's very odd. I can't seem to replicate this on a local build, only with the system install so far. $ jmap -heap -F 4231 Attaching to process ID 4231, please wait... WARNING: Hotspot VM version 24.0-b56-r18ffb465e2ba does not match with SA version 24.0-b56. You may see unexpected results. Debugger attached successfully. Server compiler detected. JVM version is 24.0-b56-r18ffb465e2ba using thread-local object allocation. Parallel GC with 8 thread(s) Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 2105540608 (2008.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 174063616 (166.0MB) G1HeapRegionSize = 0 (0.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 33554432 (32.0MB) used = 671200 (0.640106201171875MB) free = 32883232 (31.359893798828125MB) 2.0003318786621094% used From Space: capacity = 5242880 (5.0MB) used = 0 (0.0MB) free = 5242880 (5.0MB) 0.0% used To Space: capacity = 5242880 (5.0MB) used = 0 (0.0MB) free = 5242880 (5.0MB) 0.0% used PS Old Generation capacity = 87556096 (83.5MB) used = 0 (0.0MB) free = 87556096 (83.5MB) 0.0% used PS Perm Generation capacity = 22020096 (21.0MB) used = 2793200 (2.6638031005859375MB) free = 19226896 (18.336196899414062MB) 12.684776669456845% used 657 interned Strings occupying 42704 bytes. Hate to nag - but any updates on this? We planned to release jmap and jstack scripts in ovirt 3.3. Hi Lukas, Concerning dates - I'm not sure. When is 6.5GA? Concerning Errata - I don't have permission to the errata site. Any other place I can download this version from? I can't actually replicate this from a local build as I said, only with a system install of 2.4.2. I'm afraid I won't have any more time to look at this right now as we have a security errata imminent. This is affecting the latest RHEL 6.4, java-1.7.0-openjdk-1.7.0.25-2.3.10.4.el6_4.x86_64, and Fedora 19, java-1.7.0-openjdk-1.7.0.60-2.4.2.7.fc19.x86_64, packages as well. $ /usr/lib/jvm/java-1.7.0-openjdk/bin/jmap -dump:format=b,file=jboss_test.hprof -F JBOSS_PID Attaching to process ID JBOSS_PID, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24.0-b56 Dumping heap to jboss_test.hprof ... 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 I could reproduce it on RHEL6.4 and F19, both 64-bits, when trying to take a heap dump of JBoss EAP. I could not find any reference to this issue on KCS, Google and OpenJDK bug reporting system. The closest reference I could find was JDK-6966967. I tried debugging, but it's way above my technical knowledge, the only think I could find is that it refer to collecting the live regions. This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. looks like still the same with java-1.7.0-openjdk-1.7.0.45-2.4.3.4.el6_5.x86_64 Sorry, I did not mean to unset needinfo, only adding myself to CC. report of similar issue on OpenJDK Runtime Environment (IcedTea6 1.13.1) (rhel-3.1.13.1.el6_5-x86_64) Is a new bugzilla required for 1.6? It's very odd that no-one mentioned the workaround. jmap and jstack need debuginfo. Install the -debuginfo openjdk package and it should work. Cheers Andrew. I can confirm this worked for me. This was not addressed in 1.7.0_55? I've not been able to replicate the issue after having upgraded. So is this issue reproducible any more? I can confirm this still occurs with the latest versions of OpenJDK 7, and it still poses a problem. On an Openshift Enterprise instance, I can see this when using JMap on a JBoss process, which SSH'd into the gear. Running java -version reports version: java version "1.7.0_71" OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) This is also reproducible on my dev laptop, running Fedora 20, testing JBoss or IntelliJ IDEA process. RPM -qa reports the package is: java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64. In both cases, the error is the same: Heap Usage: 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: java.lang.RuntimeException: unknown CollectedHeap type : class sun.jvm.hotspot.gc_interface.CollectedHeap at sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:146) at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:40) Unfortunately, for the OSE instances, installing the OpenJDK debuginfo package is probably not an option. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. QAcking, but we do not have any nice test around Clearing need-info as this is going to get fixed anyway. (In reply to jiri vanek from comment #35) > QAcking, but we do not have any nice test around The test should be similar to the detailed NMT issue. Except for this test debuginfo *must not* be installed: $ cat ~/HelloWait.java public class HelloWait { public static void main(String[] args) { System.out.println("Hello World"); try { while (true) { Thread.sleep(200); } } catch (InterruptedException e) { // ignore } } } $ javac HelloWait.java $ java HelloWait & $ sleep 1 && jstack -F $(jps | grep HelloWait | cut -d' ' -f1) > jstack.out 2>&1 $ grep InvocationTargetException jstack.out && echo FAIL $ jmap -dump:file=hellowait.hprof -F $(jps | grep HelloWait | cut -d' ' -f1) > jmap.out 2>&1 $ grep InvocationTargetException jmap.out && echo FAIL I see. Thanx! Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2005 |
Created attachment 801492 [details] Java test file Description of problem: When running jstack and jmap, exceptions occur. Version-Release number of selected component (if applicable): 1.7.0_25 How reproducible: Steps to Reproduce: 1.java com.redhat.test.TestJMap (Attached to bug description) 2.At another command console, run the following command: jstack -F <PID> jmap -heap -F <PID> 3. Actual results: Exception Expected results: Stack trace and heap dump Additional info: