Other |
---|
tbdUnresolved |
Duplicate :
|
|
Duplicate :
|
|
Relates :
|
|
Relates :
|
JDK-8305678 :
|
Starting March 19th I've seen the following error or similar 5 times in Loom CI tier6-comp and tier7-comp testing: hsdb> + inspect 0x00000000b0300138 Error: sun.jvm.hotspot.debugger.UnmappedAddressException: b0300140 sun.jvm.hotspot.debugger.UnmappedAddressException: b0300140 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getInt(PageCache.java:96) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:363) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCompKlassAddressValue(DebuggerBase.java:477) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readCompKlassAddress(WindbgDebuggerLocal.java:322) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getCompKlassAddressAt(WindbgAddress.java:79) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:212) at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:181) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$25.doit(CommandProcessor.java:1109) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2212) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2182) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2053) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) Sometimes instead the exception is UnalignedAddressException. Failures so far have been on linux-x64 and windows-x64. Flags used are: tier6-comp: -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation tier7-comp: -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:-DoEscapeAnalysis The address being inspected (0x00000000b0300138) was gleaned from following part of the jstack output. It's the address that shows up as "waiting to lock", so it appears to be a java.lang.Class instance that is currently locked. "Thread-0" #33 prio=5 tid=0x000001dee6ce0040 nid=39056 waiting for monitor entry [0x0000009c9faff000] java.lang.Thread.State: BLOCKED (on object monitor) JavaThread state: _thread_blocked - LingeredAppWithLock.lockMethod(java.lang.Object) @bci=3, line=30, pc=0x000001ded4b1ecd0, Method*=0x000001dee0401640 (Compiled frame) - waiting to lock <0x00000000b0300138> (a java.lang.Class for LingeredAppWithLock) - LingeredAppWithLock.lambda$main$0() @bci=2, line=40, pc=0x000001ded4b1ecd0, Method*=0x000001dee0401ad8 (Compiled frame) - LingeredAppWithLock$$Lambda$1+0x0000000801000d30.run() @bci=0, pc=0x000001ded4b36b88, Method*=0x000001dee04076f0 (Compiled frame) - java.lang.Thread.run() @bci=13, line=1532, pc=0x000001ded4bfcc24, Method*=0x0000000800010d38 (Compiled frame)
|