weixin_39982236
weixin_39982236
2021-01-06 13:47

JDK8 Win64 java -version crash VMState: 0x000503ff Shared cache offset out of bounds

Happens only on JDK8 64bit (internal nightly build). Seems to be 100% reproducible. I have a set of diagnostic files saved. Last passed build was Nov 10 58d490796d0276f5c3f3b45a6cf21513ecf7bde1


00:01:43.811  unzip file: OpenJ9-JDK8-x86-64_windows-20191121-211505.tar.gz ...
00:01:58.863  unzip file: test-images.tar.gz ...
00:02:01.630  Run C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly/openjdkbinary/j2sdk-image/bin/java -version
00:02:01.630  Assertion failed at C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Nightly\build\windows-x86_64-normal-server-release\vm\compiler\env\J9SharedCache.cpp:457: false
00:02:01.630  VMState: 0x000503ff
00:02:01.630    Shared cache offset out of bounds
00:02:01.630  compiling java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at level: cold
00:02:01.630  
00:02:01.630  Unhandled exception
00:02:01.630  Type=Segmentation error vmState=0x000503ff
00:02:01.630  Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=0000000057F18A46 ContextFlags=0010001f
00:02:01.630  Handler1=0000000057C1B470 Handler2=00007FF87553CC70 InaccessibleWriteAddress=0000000000000000
00:02:01.630  RDI=000000000E868788 RSI=000000000E868780 RAX=0000000000000000 RBX=000A42E7ED469368
00:02:01.630  RCX=A1AEBD1D8CAD0000 RDX=0000000000000000 R8=0000000000000069 R9=00000000000000CB
00:02:01.630  R10=00000000000002C0 R11=0000000000000059 R12=0000000000000003 R13=FFFFFFFFF1797878
00:02:01.630  R14=000000000E6E7DB0 R15=0000000001824300
00:02:01.630  RIP=0000000057F18A46 RSP=000000000E8685E0 RBP=000000000E8687C8 GS=002B
00:02:01.630  FS=0053 ES=002B DS=002B
00:02:01.630  XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000)
00:02:01.631  Module=C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\j2sdk-image\jre\bin\compressedrefs\j9jit29.dll
00:02:01.631  Module_base_address=0000000057BD0000 Offset_in_DLL=0000000000348a46
00:02:01.631  
00:02:01.631  Method_being_compiled=java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
00:02:01.631  Target=2_90_20191121_232 (Windows Server 2016 10.0 build 14393)
00:02:01.631  CPU=amd64 (4 logical CPUs) (0x1fff8d000 RAM)
00:02:01.631  ----------- Stack Backtrace -----------
00:02:01.631  openjdk version "1.8.0_232-internal"
00:02:01.631  OpenJDK Runtime Environment (build 1.8.0_232-internal-jenkins_2019_11_21_18_40-b00)
00:02:01.631  Eclipse OpenJ9 VM (build ibm_sdk-b2a72599ec, JRE 1.8.0 Windows Server 2016 amd64-64-Bit Compressed References 20191121_232 (JIT enabled, AOT enabled)
00:02:01.631  OpenJ9   - b2a72599ec
00:02:01.631  OMR      - 8eb476a6e
00:02:01.631  JCL      - f6352f08a86 based on jdk8u232-b09)
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x2b65f6 (0x0000000057F18A46 [j9jit29+0x348a46])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x2b686d (0x0000000057F18CBD [j9jit29+0x348cbd])
00:02:02.506  j9jit_testarossa+0x7e84 (0x0000000057C47C94 [j9jit29+0x77c94])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x9a698 (0x0000000057CFCAE8 [j9jit29+0x12cae8])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x9e338 (0x0000000057D00788 [j9jit29+0x130788])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x9834d (0x0000000057CFA79D [j9jit29+0x12a79d])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x9caa2 (0x0000000057CFEEF2 [j9jit29+0x12eef2])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x9b4b3 (0x0000000057CFD903 [j9jit29+0x12d903])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0xa3ff2 (0x0000000057D06442 [j9jit29+0x136442])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x804c6 (0x0000000057CE2916 [j9jit29+0x112916])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x35cd6e (0x0000000057FBF1BE [j9jit29+0x3ef1be])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x35f0aa (0x0000000057FC14FA [j9jit29+0x3f14fa])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x3559d9 (0x0000000057FB7E29 [j9jit29+0x3e7e29])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x352cb1 (0x0000000057FB5101 [j9jit29+0x3e5101])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x3553a2 (0x0000000057FB77F2 [j9jit29+0x3e77f2])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x3f9c39 (0x000000005805C089 [j9jit29+0x48c089])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x3fa766 (0x000000005805CBB6 [j9jit29+0x48cbb6])
00:02:02.506  Java_java_lang_invoke_MutableCallSite_invalidate+0x259dff (0x0000000057EBC24F [j9jit29+0x2ec24f])
00:02:02.506  (0x0000000057C26786 [j9jit29+0x56786])
00:02:02.506  (0x0000000057C2828E [j9jit29+0x5828e])
00:02:02.506  j9port_init_library+0x1b476 (0x00007FF87553DE46 [j9prt29+0x1de46])
00:02:02.506  j9port_init_library+0x1b674 (0x00007FF87553E044 [j9prt29+0x1e044])
00:02:02.506  (0x0000000057C28B2C [j9jit29+0x58b2c])
00:02:02.506  (0x0000000057C290F2 [j9jit29+0x590f2])
00:02:02.506  (0x0000000057C23EDA [j9jit29+0x53eda])
00:02:02.506  (0x0000000057C26E8E [j9jit29+0x56e8e])
00:02:02.506  j9port_init_library+0x1b6af (0x00007FF87553E07F [j9prt29+0x1e07f])
00:02:02.506  (0x0000000057C286DD [j9jit29+0x586dd])
00:02:02.506  omrthread_detach+0x1fd (0x00007FF878E85D6D [J9THR29+0x5d6d])
00:02:02.506  _endthreadex+0x43 (0x00000000599E1D9F [msvcr100+0x21d9f])
00:02:02.506  _endthreadex+0xdf (0x00000000599E1E3B [msvcr100+0x21e3b])
00:02:02.506  BaseThreadInitThunk+0x14 (0x00007FF87FB184D4 [KERNEL32+0x84d4])
00:02:02.506  RtlUserThreadStart+0x21 (0x00007FF88023E851 [ntdll+0x6e851])
00:02:02.506  ---------------------------------------
00:02:02.506  JVMDUMP039I Processing dump event "gpf", detail "" at 2019/11/22 01:34:14 - please wait.
00:02:02.506  JVMDUMP032I JVM requested System dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\core.20191122.013414.15288.0001.dmp' in response to an event
00:02:10.626  JVMDUMP010I System dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\core.20191122.013414.15288.0001.dmp
00:02:10.626  JVMDUMP032I JVM requested Java dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\javacore.20191122.013414.15288.0002.txt' in response to an event
00:02:10.626  JVMDUMP010I Java dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\javacore.20191122.013414.15288.0002.txt
00:02:10.626  JVMDUMP032I JVM requested Snap dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\Snap.20191122.013414.15288.0003.trc' in response to an event
00:02:10.626  JVMDUMP010I Snap dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\Snap.20191122.013414.15288.0003.trc
00:02:10.626  JVMDUMP007I JVM Requesting JIT dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Nightly\openjdkbinary\jitdump.20191122.013414.15288.0004.dmp'

该提问来源于开源项目:eclipse/openj9

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

48条回答

  • weixin_39647458 weixin_39647458 4月前

    Moving this to 0.19 as it's too late to put further changes into 0.18

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    Provided Irwin with sdk, build workspace and test workspace with crash files.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    Thanks to for the SDK+.pdb files+crash environment.

    Call stack:

    
    ...
    [0x13]   ntdll!KiUserExceptionDispatcher + 0x3a   
    [0x14]   j9jit29!TR_J9VMBase::matchRAMclassFromROMclass + 0x89   
    [0x15]   j9jit29!TR_IPBCDataCallGraph::loadFromPersistentCopy + 0x112   
    [0x16]   j9jit29!TR_IProfiler::profilingSample + 0x378   
    [0x17]   j9jit29!TR_IProfiler::getCGProfilingData + 0x2d   
    [0x18]   j9jit29!TR_IProfiler::createIProfilingValueInfo + 0x322   
    [0x19]   j9jit29!TR_ExternalValueProfileInfo::getValueInfo + 0x77   
    [0x1a]   j9jit29!TR_ValueProfileInfoManager::getValueInfo + 0x175   
    [0x1b]   j9jit29!TR_ValueProfileInfoManager::getProfiledValueInfo + 0x43   
    [0x1c]   j9jit29!TR::X86CallSite::computeProfiledTargets + 0x1ae   
    [0x1d]   j9jit29!TR::X86CallSite::X86CallSite + 0x120   
    [0x1e]   j9jit29!J9::X86::PrivateLinkage::buildIndirectDispatch + 0x7f   
    ...
    

    The crash happens in TR_J9VMBase::matchRAMclassFromROMclass in https://github.com/eclipse/openj9/blob/bd833c7e3699d3412286ca4f7aa3af872810860f/runtime/compiler/env/VMJ9.cpp#L525 The value of J9ROMClass *clazz is 0x00000000101166A5 which is a bogus pointer, resulting in the crash.

    After digging through the assembly (which took longer than it should've because windbg is so amazing that it doesn't provide register context for the various frames), I found that the offset passed to isOffsetInSharedCache(csInfoClazzOffset, &romClass) is 0x00000000000065B5.

    From jdmpview:

    
    > !j9sharedclasscachedescriptor 0x000000000F76C498
    ...
            0x0: class J9SharedCacheHeader* cacheStartAddress = !j9sharedcacheheader 0x00000000101100F0
    ...
    

    If I do 0x00000000000065B5+0x00000000101100F0 I get the bad address 0x00000000101166A5.

    From the TR_IPBCDataCallGraphStorage *, I was able to look at the other entries in the store->_csInfo array:

    
    > !j9x 0x000000000FF09FA0,64
    0x0FF09FA0 :  03000000000a2b89 00000000000007d1 [ .+.............. ]
    0x0FF09FB0 :  00000000000f3950 0000000000000000 [ P9.............. ]
    0x0FF09FC0 :  00000000000065b5 000000005c9824ac [ .e.......$.\.... ]
    0x0FF09FD0 :  00007ff6bd2d0020 00007ff6bd2c0ba0 [  .-.......,..... ]
    0x0FF09FE0 :  00007ff6bd2815e0 000000005c4ed62e [ ..(.......N\.... ]
    0x0FF09FF0 :  0000000000000000 000000000ff0a0f0 [ ................ ]
    

    store->_csInfo starts at 0x0FF09FB0, so the three entries are: 00000000000f3950, 0000000000000000, and 00000000000065b5 (the last being the bad offset). As a sanity check, I used the first entry to calculate what the J9ROMClass would be:

    00000000000f3950+0x00000000101100F0=0x10203A40

    
    > !j9romclass 0x10203A40
    J9ROMClass at 0x10203a40 {
      Fields for J9ROMClass:
            0x0: U32 romSize = 0x00001030 (4144)
            0x4: U32 singleScalarStaticCount = 0x00000001 (1)
            0x8: J9SRP(J9UTF8) className = !j9utf8 0x0000000010203904
    ...
    > !j9utf8 0x0000000010203904
    J9UTF8 at 0x10203904 {
      Fields for J9UTF8:
            0x0: U16 length = 0x001D (29)
            0x2: U8[] data = !j9x 0x0000000010203906
    }
    > !j9x 0x0000000010203906,29
    0x10203906 :  6e616c2f6176616a 6361726168432f67 [ java/lang/Charac ]
    0x10203916 :  4c61746144726574 000800316e697461 [ terDataLatin1... ]
    0x10203926 :  65636e6174736e69                  [ instance ]
    

    So clearly the first entry seems reasonable.

    Additionaly, looking at the javacore:

    
    1SCLTEXTCSUM       Cache Summary
    NULL               ------------------
    ...
    2SCLTEXTRCS            ROMClass start address                    = 0x0000000010169000
    2SCLTEXTRCE            ROMClass end address                      = 0x000000001085DC20
    ...
    

    The start offset is 0x58F10 and the end offset is 0x74DB30, so the bad offset 0x65b5 doesn't even point into the ROMClass section...

    Not really sure how we end up in this situation, that too only on Windows...

    点赞 评论 复制链接分享
  • weixin_39647458 weixin_39647458 4月前

    Any update on this? It's currently tagged against 0.19.0 and we're seeing more and more instances of this failure in the wild

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    Haven't really had time to look at this yet; I managed to get to a point where I can build Windows on some of the internal build machines, so now it'll just be a matter of reproducing and iterating.

    点赞 评论 复制链接分享
  • weixin_39647458 weixin_39647458 4月前

    +1 to iterating to solve this.

    There is discussion that will be occurring during tomorrow's OpenJ9 community call about whether we should do a 0.18.2 release and this would be an issue we'd want resolved in any point release we do.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    I managed to get to a point where I can build Windows on some of the internal build machines

    Spoke too soon, still can't build 🎉

    this would be an issue we'd want resolved in any point release we do.

    Yeah makes sense. The tiny silver lining is that the issue can be mitigated by either running with -Xshareclasses:none or by running with -Xjit:dontUsePersistentIprofiler -Xaot:dontUsePersistentIprofiler (see https://github.com/eclipse/openj9/issues/8517#issuecomment-583014632 & https://github.com/eclipse/openj9/issues/8404#issuecomment-583031614)

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    I'm able to reproduce this on one of the internal windows machines. What's hilarious (sarcasm) is that the reason things like -version fail is because it's loading from the SCC that was created by the openj9 instance the Jenkins slave instance is running on. I've been running with https://github.com/dsouzai/openj9/commit/41e104372f2d188cd943e329fe6ef51f554c3360 , but that's kind of useless because we're not actually adding to the SCC (because it's in use). Additionally, when it fails, the offset does end up being in the class range, it just ends up being invalid.

    I suppose what I'll have to do is run some java code that populates a different SCC and add some additional checks (like ensuring in the store to scc run, the j9class eyecatcher is there, etc.).

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    I can confirm if I run a slave with -Xshareclasses:none the tests run fine. This reiterates an initial concern I had of migrating to Jenkins since the slaves themselves have a java process running on them. Do we need to think more about this in general? How can we avoid these types of situations? Or maybe it is desirable to have this environment as it has exposed this corner case?

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    With 0.17, this is what I see with -Xshareclasses:verbose:

    
    $ ./jdk8u232-b09/bin/java -Xdump:none -Xshareclasses:verbose -version
    [-Xshareclasses persistent cache enabled]
    [-Xshareclasses verbose output enabled]
    JVMSHRC237I Opened shared classes persistent cache sharedcc_LOCAL SERVICE
    JVMSHRC246I Attached shared classes persistent cache sharedcc_LOCAL SERVICE
    JVMSHRC765I Memory page protection on runtime data, string read-write data and partially filled pages is successfully enabled
    openjdk version "1.8.0_232"
    OpenJDK Runtime Environment (build 1.8.0_232-b09)
    Eclipse OpenJ9 VM (build openj9-0.17.0, JRE 1.8.0 Windows Server 2016 x86-32-Bit 20191101_367 (JIT enabled, AOT enabled)
    OpenJ9   - 77c1cf708
    OMR      - 20db4fbc1
    JCL      - 3504dff40aa based on jdk8u232-b09)
    JVMSHRC168I Total shared class bytes read=2008896. Total bytes stored=680
    JVMSHRC818I Total unstored bytes due to the setting of shared cache soft max is 0. Unstored AOT bytes due to the setting of -Xscmaxaot is 0. Unstored JIT bytes due to the setting of -Xscmaxjitdata is 0.
    

    with 0.18 (and an SCC created by a 0.17 JVM, which can't be deleted because the process is still running):

    
    $ ./openj9-openjdk-jdk8/build/windows-x86_64-normal-server-release/images/j2sdk-image/bin/java -Xdump:none -Xshareclasses:verbose -version
    [-Xshareclasses persistent cache enabled]
    [-Xshareclasses verbose output enabled]
    JVMSHRC237I Opened shared classes persistent cache sharedcc_LOCAL SERVICE
    JVMSHRC241E Error: unable to delete shared class cache file
    JVMSHRC336E Port layer error code = -100
    JVMSHRC337E Platform error message: (32) The process cannot access the file because it is being used by another process.
    JVMSHRC237I Opened shared classes persistent cache sharedcc_LOCAL SERVICE
    JVMSHRC246I Attached shared classes persistent cache sharedcc_LOCAL SERVICE
    JVMSHRC765I Memory page protection on runtime data, string read-write data and partially filled pages is successfully enabled
    JVMJITM005W AOT code in the shared class cache cannot run on current JVM release. Ignoring AOT code in shared class cache.
    openjdk version "1.8.0_242-internal"
    OpenJDK Runtime Environment (build 1.8.0_242-internal-jenkins_2020_02_14_08_27-b00)
    Eclipse OpenJ9 VM (build HEAD-41e104372, JRE 1.8.0 Windows Server 2016 amd64-64-Bit Compressed References 20200214_000000 (JIT enabled, AOT enabled)
    OpenJ9   - 41e104372
    OMR      - 7a1b0239a
    JCL      - 8cf8a30581 based on jdk8u242-b08)
    JVMSHRC168I Total shared class bytes read=1333532. Total bytes stored=0
    JVMSHRC818I Total unstored bytes due to the setting of shared cache soft max is 851968. Unstored AOT bytes due to the setting of -Xscmaxaot is 0. Unstored JIT bytes due to the setting of -Xscmaxjitdata is 0.
    

    It's an open question as to why when I run with 0.17 I don't see a crash at all. However, in the 0.18 case, if we fail to delete the SCC, why do we continue to use it the one created by a different JVM version? Why not just run without an SCC? Doesn't it seem like a bad idea to use a SCC created by an older JVM version, especially if the newer JVM might update it; doesn't that risk a situation where the older JVM might not be able to interpret data written by the newer JVM?

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    That's not the way it was designed. If there is a cache incompatibility then we can change the cache generation number. Otherwise it's supposed to be safe to continue to use the existing cache, although not optimal. Many of the classes in the cache could be unchanged from the previous JVM version, and if not, it's handled properly.

    点赞 评论 复制链接分享
  • weixin_39608748 weixin_39608748 4月前

    We always try deleting the existing cache if it is from a different build. There are cases that we may not be able to delete it. In such cases, if the cache generation number is the same, it is compatible and safe to use. The generation number is part of the cache file name. We increment the cache generation number when there are in-compatible changes.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    If there is a cache incompatibility then we can change the cache generation number.

    We increment the cache generation number when there are in-compatible changes.

    How is incompatibility determined? Is it something where a dev has to explicitly know when some change to the sharedcache lib causes an incompatibility?

    点赞 评论 复制链接分享
  • weixin_39608748 weixin_39608748 4月前

    How is incompatibility determined? Is it something where a dev has to explicitly know when some change to the sharedcache lib causes an incompatibility?

    Yes. It is the developer who is changing the code needs to consider whether the change breaks compatibility.

    点赞 评论 复制链接分享
  • weixin_39647458 weixin_39647458 4月前

    Can you provide an update on this? We're getting close to the Milestone 2 date and need to try to get the Milestone issues resolved

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    No updates on my end yet; as far as I can tell, this issue seems to only occur when you have an SCC that's created by a 0.17 JVM, and used by a 0.18 JVM. What I have to do to reproduce it is run a 0.17 JVM to populate the SCC, keep it running to lock the SCC file, and then run a 0.18 JVM to load from that SCC. I'll also have to use two custom builds to add instrumentation to both. I haven't had the time to do all this.

    点赞 评论 复制链接分享
  • weixin_39992760 weixin_39992760 4月前

    Seems somewhat brittle to rely on every developer knowing when they've changed something that might make the contents of the shared cache incompatible. Given we're now enabling shared cache use by default which may expose us to more bugs of this nature, maybe now is the time to only use the cache if it was built by the current build?

    Is it more common for caches to be compatible or to be incompatible with older releases (ignoring AOT code because we always consider it to be incompatible)?

    We could also just not use iprofile data when we've determined the cache isn't valid for AOT use (presumably we properly figured out that we couldn't use the AOT code in the older cache).

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    maybe now is the time to only use the cache if it was built by the current build?

    This introduces a different issue, where no shared cache is used although use of one is expected. Since only the classes are used and not the AOT, I expect this doesn't much matter. Long ago there was a startup advantage to using ROM classes from the cache, but today it's essentially as fast to read the classes from disk and convert them. Would new AOT get created in a cache that already contains incompatible AOT?

    Is it more common for caches to be compatible or to be incompatible with older releases (ignoring AOT code because we always consider it to be incompatible)?

    The cache has mostly been compatible. We change the generation number when the cache format changes or ROM classes change. The current generation number is 41, and for years has been incremented by 2. This gives a hint of the number of incompatibilities since shared classes was introduced in Java 5. Whenever the generation number is changed, there is the possibility of leaving old caches on disk consuming disk space, as it's up to the user to clean them up.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    Would new AOT get created in a cache that already contains incompatible AOT?

    No, if a cache is deemed incompatible, we run as if there is no SCC. ...well except for the IProfiler, so I'm looking to have the IProfiler also reject info from a cache deemed incompatible.

    点赞 评论 复制链接分享
  • weixin_39583655 weixin_39583655 4月前

    Also , there are a few of these asserts; do they still hold in the multi SCC world?

    Yes, I actually added those asserts when I made the multi-layer changes.

    Rather than increase the offset size in the TR_IPBCData... family of classes from 4 to 8 bytes I left them as-is since it is extremely unlikely that we will have SCCs bigger than 4GiB. These asserts will catch those cases if we ever do hit them.

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    FWIW, This isn't happening in the XL or 32bit build. It is specific to win64 compressed jdk8.

    点赞 评论 复制链接分享
  • weixin_39913472 weixin_39913472 4月前

    I don't have an idea on how the assert could trigger; the safeguards are in place. I could try harder to see whether there is a very narrow synchronization issue, but given that the problem is 100% reproducible I doubt it's a race condition.

    点赞 评论 复制链接分享
  • weixin_39608748 weixin_39608748 4月前

    it is extremely unlikely that we will have SCCs bigger than 4GiB

    A SCC cannot be bigger than 4GB. We do not allow that.

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    I got one of these in an internal personal build. job/Test_openjdk8_j9_sanity.functional_x86-64_windows_Personal/74

    
    14:50:40      [javac] Assertion failed at C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\build\windows-x86_64-normal-server-release\vm\compiler\env\J9SharedCache.cpp:457: false
    14:50:40      [javac] VMState: 0x000503ff
    14:50:40      [javac]   Shared cache offset out of bounds
    14:50:40      [javac] compiling java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at level: cold
    14:50:40      [javac] 
    14:50:40      [javac] Unhandled exception
    14:50:40      [javac] Type=Segmentation error vmState=0x000503ff
    14:50:40      [javac] Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=00000000628ED0D6 ContextFlags=0010001f
    14:50:40      [javac] Handler1=00000000625EBB70 Handler2=00007FFFBF2ECCF0 InaccessibleWriteAddress=0000000000000000
    14:50:40      [javac] RDI=000000000F6489F8 RSI=000000000F6489F0 RAX=0000000000000000 RBX=000A42E7ED469368
    14:50:40      [javac] RCX=B090F807590C0000 RDX=0000000000000000 R8=0000000000000069 R9=00000000000000CB
    14:50:40      [javac] R10=00000000000002C0 R11=0000000000000059 R12=0000000000000003 R13=FFFFFFFFF09B7608
    14:50:40      [javac] R14=000000000ED04D70 R15=000000000E921530
    14:50:40      [javac] RIP=00000000628ED0D6 RSP=000000000F648850 RBP=000000000F648A38 GS=002B
    14:50:40      [javac] FS=0053 ES=002B DS=002B
    14:50:40      [javac] XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    14:50:40      [javac] Module=C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Personal\openjdkbinary\j2sdk-image\jre\bin\compressedrefs\j9jit29.dll
    14:50:40      [javac] Module_base_address=00000000625A0000 Offset_in_DLL=000000000034d0d6
    14:50:40      [javac] 
    14:50:40      [javac] Method_being_compiled=java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
    14:50:40      [javac] Target=2_90_20191213_247 (Windows Server 2016 10.0 build 14393)
    14:50:40      [javac] CPU=amd64 (4 logical CPUs) (0x1fff8d000 RAM)
    14:50:40      [javac] ----------- Stack Backtrace -----------
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x2ba646 (0x00000000628ED0D6 [j9jit29+0x34d0d6])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x2ba8bd (0x00000000628ED34D [j9jit29+0x34d34d])
    14:50:40      [javac] j9jit_testarossa+0x7e84 (0x00000000626182D4 [j9jit29+0x782d4])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x9e778 (0x00000000626D1208 [j9jit29+0x131208])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0xa2418 (0x00000000626D4EA8 [j9jit29+0x134ea8])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x9c42d (0x00000000626CEEBD [j9jit29+0x12eebd])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0xa0b82 (0x00000000626D3612 [j9jit29+0x133612])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x9f593 (0x00000000626D2023 [j9jit29+0x132023])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0xa80d2 (0x00000000626DAB62 [j9jit29+0x13ab62])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x804e6 (0x00000000626B2F76 [j9jit29+0x112f76])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x360ebe (0x000000006299394E [j9jit29+0x3f394e])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x36320a (0x0000000062995C9A [j9jit29+0x3f5c9a])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x359b29 (0x000000006298C5B9 [j9jit29+0x3ec5b9])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x356e01 (0x0000000062989891 [j9jit29+0x3e9891])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x3594f2 (0x000000006298BF82 [j9jit29+0x3ebf82])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x3fd069 (0x0000000062A2FAF9 [j9jit29+0x48faf9])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x3fdb96 (0x0000000062A30626 [j9jit29+0x490626])
    14:50:40      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x25da8f (0x000000006289051F [j9jit29+0x2f051f])
    14:50:40      [javac] (0x00000000625F6E66 [j9jit29+0x56e66])
    14:50:40      [javac] (0x00000000625F89EB [j9jit29+0x589eb])
    14:50:40      [javac] j9port_init_library+0x1b4f6 (0x00007FFFBF2EDEC6 [j9prt29+0x1dec6])
    14:50:40      [javac] j9port_init_library+0x1b6f4 (0x00007FFFBF2EE0C4 [j9prt29+0x1e0c4])
    14:50:40      [javac] (0x00000000625F928C [j9jit29+0x5928c])
    14:50:40      [javac] (0x00000000625F9852 [j9jit29+0x59852])
    14:50:40      [javac] (0x00000000625F45BA [j9jit29+0x545ba])
    14:50:40      [javac] (0x00000000625F756E [j9jit29+0x5756e])
    14:50:40      [javac] j9port_init_library+0x1b72f (0x00007FFFBF2EE0FF [j9prt29+0x1e0ff])
    14:50:40      [javac] (0x00000000625F8E3D [j9jit29+0x58e3d])
    14:50:40      [javac] omrthread_detach+0x1fd (0x00007FFFBF325D6D [J9THR29+0x5d6d])
    14:50:40      [javac] _endthreadex+0x43 (0x0000000063101D9F [MSVCR100+0x21d9f])
    14:50:40      [javac] _endthreadex+0xdf (0x0000000063101E3B [MSVCR100+0x21e3b])
    14:50:40      [javac] BaseThreadInitThunk+0x14 (0x00007FFFCE5284D4 [KERNEL32+0x84d4])
    14:50:40      [javac] RtlUserThreadStart+0x21 (0x00007FFFCF5BE851 [ntdll+0x6e851])
    14:50:40      [javac] ---------------------------------------
    
    点赞 评论 复制链接分享
  • weixin_39647458 weixin_39647458 4月前

    What's the status of this issue? We're trying to close out the 0.18 milestone

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    I have no idea why the problem occurs. I can put in the fix that will stop the assert from occurring (and will be functionally correct) if you feel this issue is problematic enough that we can't carry it forward to the next release.

    点赞 评论 复制链接分享
  • weixin_39913472 weixin_39913472 4月前

    Please deliver the fix you proposed.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    Opened https://github.com/eclipse/openj9/pull/8227

    I'm guessing I'll have to open a separate PR for 0.18?

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    I am still seeing this internally however it doesn't seem to be 100% reproducible now. Looking at last night's win64 jdk8 build at the end of the compile java -version looks fine. However 9 out of 11 test targets fail with the same crash error. Some fail immediately at the start of the ant compile task and some midway through the same compile task.

    
    00:15:44.575  compile:
    00:15:44.575       [echo] Ant version is Apache Ant(TM) version 1.10.5 compiled on July 10 2018
    00:15:44.575       [echo] ============COMPILER SETTINGS============
    00:15:44.575       [echo] ===fork:                         yes
    00:15:44.575       [echo] ===debug:                        on
    00:15:44.575      [javac] Compiling 13 source files to C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.system_x86-64_windows_Personal\openjdk-tests\TKG\bin
    00:15:48.636      [javac] Unhandled exception
    00:15:48.636      [javac] Type=Segmentation error vmState=0x000503ff
    
    
    00:30:39.671  Generating make file C:\Users\jenkins\workspace\Test_openjdk8_j9_sanity.functional_x86-64_windows_Personal\openjdk-tests\TKG/../functional/cmdLineTests/jvmtitests/autoGen.mk
    00:30:39.671  Unhandled exception
    00:30:39.671  Type=Segmentation error vmState=0x000503ff
    
    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    can you please provide the full output for the error. I assume the assertion is gone from the message now. That seems to be what #8227 changed.

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    fyi I've reopened this.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    fyi I've reopened this.

    yeah a good idea, the "fix" wasn't really a fix after all...

    The check was doing

    
    if (comp->fej9()->sharedCache()->isPointerInSharedCache((void *)csInfoClazz))
    

    but csInfoClazz isn't a pointer, it's an offset, so this check is useless... sigh

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    can you please create a PR for the v0.18.0-release branch.

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    Still seeing this crash on 3/4 test targets based on 5ea61ceb3d14993e11703dd2b6d4080a2290f087 /job/Pipeline-Build-Test-Personal/4562/

    
    00:06:07.949  compile:
    00:06:07.949       [echo] Ant version is Apache Ant(TM) version 1.10.5 compiled on July 10 2018
    00:06:07.949       [echo] ============COMPILER SETTINGS============
    00:06:07.949       [echo] ===fork:                         yes
    00:06:07.949       [echo] ===debug:                        on
    00:06:08.824      [javac] Compiling 13 source files to C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\bin
    00:06:09.683      [javac] Unhandled exception
    00:06:09.683      [javac] Type=Segmentation error vmState=0x000503ff
    00:06:09.683      [javac] Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=0000000061A09C49 ContextFlags=0010001f
    00:06:09.683      [javac] Handler1=00000000619CBBA0 Handler2=00007FFFB6ACCCF0 InaccessibleReadAddress=0000000082A2F189
    00:06:09.683      [javac] RDI=000000000229A300 RSI=000000000F98E830 RAX=000000000F98E888 RBX=00007FF695800000
    00:06:09.683      [javac] RCX=0000000000000000 RDX=0000000001BC46A8 R8=0000000000000001 R9=0000000000000004
    00:06:09.683      [javac] R10=00007FFFB6C4CB28 R11=000000000F988960 R12=000000000F265BB0 R13=0000000063416261
    00:06:09.683      [javac] R14=0000000082A2F18B R15=00000000000000A0
    00:06:09.683      [javac] RIP=0000000061A09C49 RSP=000000000F988970 RBP=000000001F618F20 GS=002B
    00:06:09.683      [javac] FS=0053 ES=002B DS=002B
    00:06:09.683      [javac] XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.683      [javac] XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.683      [javac] XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.683      [javac] XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.683      [javac] XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.683      [javac] XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.683      [javac] XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    00:06:09.684      [javac] Module=C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdkbinary\j2sdk-image\jre\bin\compressedrefs\j9jit29.dll
    00:06:09.684      [javac] Module_base_address=0000000061980000 Offset_in_DLL=0000000000089c49
    00:06:09.684      [javac] 
    00:06:09.684      [javac] Method_being_compiled=sun/net/www/protocol/jar/Handler.parseContextSpec(Ljava/net/URL;Ljava/lang/String;)Ljava/lang/String;
    00:06:09.684      [javac] Target=2_90_20200113_281 (Windows Server 2016 10.0 build 14393)
    00:06:09.684      [javac] CPU=amd64 (4 logical CPUs) (0x1fff8d000 RAM)
    00:06:09.684      [javac] ----------- Stack Backtrace -----------
    00:06:09.684      [javac] Java_java_lang_invoke_InterfaceHandle_convertITableIndexToVTableIndex+0x439 (0x0000000061A09C49 [j9jit29+0x89c49])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x9d9e2 (0x0000000061AB0522 [j9jit29+0x130522])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0xa1658 (0x0000000061AB4198 [j9jit29+0x134198])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x9b99a (0x0000000061AAE4DA [j9jit29+0x12e4da])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x36304a (0x0000000061D75B8A [j9jit29+0x3f5b8a])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x3650ea (0x0000000061D77C2A [j9jit29+0x3f7c2a])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x35ba09 (0x0000000061D6E549 [j9jit29+0x3ee549])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x358ce1 (0x0000000061D6B821 [j9jit29+0x3eb821])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x35b3d2 (0x0000000061D6DF12 [j9jit29+0x3edf12])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x3feff9 (0x0000000061E11B39 [j9jit29+0x491b39])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x3ffb26 (0x0000000061E12666 [j9jit29+0x492666])
    00:06:09.684      [javac] Java_java_lang_invoke_MutableCallSite_invalidate+0x26094b (0x0000000061C7348B [j9jit29+0x2f348b])
    00:06:09.684      [javac] (0x00000000619D6E96 [j9jit29+0x56e96])
    00:06:09.684      [javac] (0x00000000619D8A1B [j9jit29+0x58a1b])
    00:06:09.684      [javac] j9port_init_library+0x1b4f6 (0x00007FFFB6ACDEC6 [j9prt29+0x1dec6])
    00:06:09.684      [javac] j9port_init_library+0x1b6f4 (0x00007FFFB6ACE0C4 [j9prt29+0x1e0c4])
    00:06:09.684      [javac] (0x00000000619D92BC [j9jit29+0x592bc])
    00:06:09.684      [javac] (0x00000000619D9882 [j9jit29+0x59882])
    00:06:09.684      [javac] (0x00000000619D45EA [j9jit29+0x545ea])
    00:06:09.684      [javac] (0x00000000619D759E [j9jit29+0x5759e])
    00:06:09.684      [javac] j9port_init_library+0x1b72f (0x00007FFFB6ACE0FF [j9prt29+0x1e0ff])
    00:06:09.684      [javac] (0x00000000619D8E6D [j9jit29+0x58e6d])
    00:06:09.684      [javac] omrthread_detach+0x1fd (0x00007FFFBF375D6D [J9THR29+0x5d6d])
    00:06:09.684      [javac] _endthreadex+0x43 (0x00000000624E1D9F [MSVCR100+0x21d9f])
    00:06:09.684      [javac] _endthreadex+0xdf (0x00000000624E1E3B [MSVCR100+0x21e3b])
    00:06:09.684      [javac] BaseThreadInitThunk+0x14 (0x00007FFFCE5284D4 [KERNEL32+0x84d4])
    00:06:09.684      [javac] RtlUserThreadStart+0x21 (0x00007FFFCF5BE851 [ntdll+0x6e851])
    00:06:09.684      [javac] ---------------------------------------
    00:06:09.684      [javac] JVMDUMP039I Processing dump event "gpf", detail "" at 2020/01/13 18:13:23 - please wait.
    00:06:09.684      [javac] JVMDUMP032I JVM requested System dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\core.20200113.181323.12108.0001.dmp' in response to an event
    00:06:13.528      [javac] JVMDUMP010I System dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\core.20200113.181323.12108.0001.dmp
    00:06:13.528      [javac] JVMDUMP032I JVM requested Java dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\javacore.20200113.181323.12108.0002.txt' in response to an event
    00:06:13.529      [javac] JVMDUMP010I Java dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\javacore.20200113.181323.12108.0002.txt
    00:06:13.529      [javac] JVMDUMP032I JVM requested Snap dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\Snap.20200113.181323.12108.0003.trc' in response to an event
    00:06:13.529      [javac] JVMDUMP010I Snap dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\Snap.20200113.181323.12108.0003.trc
    00:06:13.529      [javac] JVMDUMP007I JVM Requesting JIT dump using 'C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\jitdump.20200113.181323.12108.0004.dmp'
    00:06:13.529      [javac] JVMDUMP010I JIT dump written to C:\Users\jenkins\workspace\Test_openjdk8_j9_extended.functional_x86-64_windows_Personal\openjdk-tests\TKG\scripts\jitdump.20200113.181323.12108.0004.dmp
    00:06:13.529      [javac] JVMDUMP013I Processed dump event "gpf", detail "".
    00:06:13.529  
    00:06:13.529  BUILD FAILED
    
    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    reopened again.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    I don't think this is the same issue. Before it was an assert firing which was fixed in https://github.com/eclipse/openj9/pull/8261; now it's a seg fault.

    In order to figure out where exactly the crash is happening, we'd need a proper stack trace. Is there any way to get a windows build with symbols, because at the moment, it's pretty much impossible to debug even with a core dump. I've attempted to build openj9 on a windows box and that did not go well, so I'd much rather there be a job somewhere that can produce a build with symbols.

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    I believe you need to build it yourself and retrieve the .pdb files from the build, as there isn't yet a build that archives them. There are some environment variables that enable debug for various components, seen in https://blog.openj9.org/2018/06/05/debugging-openj9-in-docker-with-gdb/, I assume you want export BUILD_CONFIG=debug. might have suggestions as I think he recently produced a build for debugging, although probably not with JIT symbols.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    I believe you need to build it yourself and retrieve the .pdb files from the build,

    I've tried building it myself when this issue was first opened up; I followed the instructions on the build page, and I was even given a stencil for a VM. I spent several hours just attempting to build, but I kept running into issue after issue.

    I don't need debug symbols, I would just need the .pdb files from a regular build; so really I just need a machine that's been set up properly to produce a windows build that I can use to get the symbols to look at a corefile. Although given that it's crashing in an ANT script, I guess there is no core file so I'm gonna need 's help to collect the core files.

    seen in https://blog.openj9.org/2018/06/05/debugging-openj9-in-docker-with-gdb/

    I should note, I don't have any problem building OpenJ9 on Linux; Window though....

    点赞 评论 复制链接分享
  • weixin_39981041 weixin_39981041 4月前

    , I can help you to produce a windows build with .pdb files (might take 2~3 hours to finish) and drop it somewhere in the /team folder if you need.

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    I can help you to produce a windows build with .pdb files (might take 2~3 hours to finish)

    Sure, though I believe 's generating one right now; I guess we'll see how that goes before you spend time generating the build.

    FWIW though, the sha's would be OpenJ9: 5ea61ce OMR: 9661da2 OpenJDK8: 3830f78 - openj9-openjdk-jdk8

    点赞 评论 复制链接分享
  • weixin_39981041 weixin_39981041 4月前

    I just grabbed all the latest changes for compilation if this works for you.

    
    /openj9-openjdk-jdk8
    $ git rev-parse --verify HEAD
    d6ae19472fa0a8000670e572ce297637214308a0
    
    /openj9-openjdk-jdk8/omr
    $ git rev-parse --verify HEAD
    947946e7dc3f0b0694401bd72aac5d26c779e8d8
    
    /openj9-openjdk-jdk8/openj9
    $ git rev-parse --verify HEAD
    bbf11e53d9b043d59ca456b51cf625de035dd23e
    
    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    cc

    点赞 评论 复制链接分享
  • weixin_39878646 weixin_39878646 4月前

    pls put the diagnostic files in /team/triage/openj9-7890

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    This also needs https://github.com/ibmruntimes/openj9-openjdk-jdk/issues/155

    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    This is very likely a similar issue as https://github.com/eclipse/openj9/pull/7379 and https://github.com/eclipse/omr/pull/4418; once a stack trace is available it should be pretty trivial to fix. However, I've had no luck with my attempts to build on windows to try and get the .pdb files.

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    put the diagnostic files in /team/triage/openj9-7890

    Done

    点赞 评论 复制链接分享
  • weixin_39982236 weixin_39982236 4月前

    Got the same crash trying to do a compile on win64 jdk8

    
    02:21:48.120  ## Finished docs (build time 00:06:52)
    02:21:48.120  
    02:21:51.012  /usr/bin/make -s VERBOSE="-s" LOG_LEVEL="warn" -I /cygdrive/c/Users/jenkins/workspace/Build_JDK8_x86-64_windows_Personal/make/common -f /cygdrive/c/Users/jenkins/workspace/Build_JDK8_x86-64_windows_Personal/closed/OpenJ9.gmk SPEC=/cygdrive/c/Users/jenkins/workspace/Build_JDK8_x86-64_windows_Personal/build/windows-x86_64-normal-server-release/spec.gmk openj9_test_image
    02:22:15.466  /cygdrive/c/Users/jenkins/workspace/Build_JDK8_x86-64_windows_Personal/build/windows-x86_64-normal-server-release/images/j2re-image/bin/java -version 2>&1 | /usr/bin/tee /cygdrive/c/Users/jenkins/workspace/Build_JDK8_x86-64_windows_Personal/build/windows-x86_64-normal-server-release/images/test/openj9/java-version.txt
    02:22:18.197  Assertion failed at C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\build\windows-x86_64-normal-server-release\vm\compiler\env\J9SharedCache.cpp:457: false
    02:22:18.197  VMState: 0x000503ff
    02:22:18.197    Shared cache offset out of bounds
    02:22:18.197  compiling java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at level: cold
    02:22:18.197  
    02:22:18.197  Unhandled exception
    02:22:18.197  Type=Segmentation error vmState=0x000503ff
    02:22:18.197  Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=000000005AC98AA6 ContextFlags=0010005f
    02:22:18.197  Handler1=000000005A99B660 Handler2=00007FF844A6CC70 InaccessibleWriteAddress=0000000000000000
    02:22:18.197  RDI=000000000F278A58 RSI=000000000F278A50 RAX=0000000000000000 RBX=000A42E7ED469368
    02:22:18.197  RCX=AF401CC8473C0000 RDX=0000000000000000 R8=0000000000000069 R9=00000000000000CB
    02:22:18.197  R10=00000000000002C0 R11=0000000000000059 R12=0000000000000003 R13=FFFFFFFFF0D875A8
    02:22:18.197  R14=000000000E72AC00 R15=000000000195F6E0
    02:22:18.197  RIP=000000005AC98AA6 RSP=000000000F2788B0 RBP=000000000F278A98 GS=002B
    02:22:18.197  FS=0053 ES=002B DS=002B
    02:22:18.197  XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:18.197  Module=C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\build\windows-x86_64-normal-server-release\images\j2re-image\bin\compressedrefs\j9jit29.dll
    02:22:18.197  Module_base_address=000000005A950000 Offset_in_DLL=0000000000348aa6
    02:22:18.197  
    02:22:18.198  Method_being_compiled=java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
    02:22:18.198  Target=2_90_20191128_219 (Windows Server 2016 10.0 build 14393)
    02:22:18.198  CPU=amd64 (8 logical CPUs) (0x3fff9a000 RAM)
    02:22:18.198  ----------- Stack Backtrace -----------
    02:22:18.198  openjdk version "1.8.0_242-internal"
    02:22:18.198  OpenJDK Runtime Environment (build 1.8.0_242-internal-jenkins_2019_11_28_13_45-b00)
    02:22:18.198  Eclipse OpenJ9 VM (build master-630b93cdc, JRE 1.8.0 Windows Server 2016 amd64-64-Bit Compressed References 20191128_219 (JIT enabled, AOT enabled)
    02:22:18.198  OpenJ9   - 630b93cdc
    02:22:18.198  OMR      - df66e8cca
    02:22:18.198  JCL      - 680fa0e62db based on jdk8u242-b01)
    02:22:18.198  TR::trap+0xc6 (assert.cpp:64, 0x000000005AC98AA6 [j9jit29+0x348aa6])
    02:22:18.198  TR::fatal_assertion+0x1d (assert.cpp:165, 0x000000005AC98D1D [j9jit29+0x348d1d])
    02:22:18.198  TR_J9SharedCache::pointerFromOffsetInSharedCache+0x54 (j9sharedcache.cpp:457, 0x000000005A9C7E84 [j9jit29+0x77e84])
    02:22:18.198  TR_IPBCDataCallGraph::loadFromPersistentCopy+0xe8 (iprofiler.cpp:3148, 0x000000005AA7CBB8 [j9jit29+0x12cbb8])
    02:22:18.198  TR_IProfiler::profilingSample+0x378 (iprofiler.cpp:1514, 0x000000005AA80858 [j9jit29+0x130858])
    02:22:18.198  TR_IProfiler::getCGProfilingData+0x2d (iprofiler.cpp:3204, 0x000000005AA7A86D [j9jit29+0x12a86d])
    02:22:18.198  TR_IProfiler::createIProfilingValueInfo+0x322 (iprofiler.cpp:2401, 0x000000005AA7EFC2 [j9jit29+0x12efc2])
    02:22:18.198  TR_IProfiler::getValueProfileInfo+0x1a3 (iprofiler.cpp:2538, 0x000000005AA7D9D3 [j9jit29+0x12d9d3])
    02:22:18.198  TR_ValueProfileInfoManager::getValueInfo+0x162 (j9profiler.cpp:986, 0x000000005AA86512 [j9jit29+0x136512])
    02:22:18.198  TR_ProfileableCallSite::findProfiledCallTargets+0x86 (j9inliner.cpp:1097, 0x000000005AA629E6 [j9jit29+0x1129e6])
    02:22:18.198  TR_InlinerBase::getSymbolAndFindInlineTargets+0x30e (inliner.cpp:3996, 0x000000005AD3EFAE [j9jit29+0x3eefae])
    02:22:18.198  TR_DumbInliner::analyzeCallSite+0xda (inliner.cpp:1316, 0x000000005AD412EA [j9jit29+0x3f12ea])
    02:22:18.198  TR_DumbInliner::inlineCallTargets+0x359 (inliner.cpp:1276, 0x000000005AD37C19 [j9jit29+0x3e7c19])
    02:22:18.198  TR_InlinerBase::performInlining+0x91 (inliner.cpp:454, 0x000000005AD34EF1 [j9jit29+0x3e4ef1])
    02:22:18.198  TR_TrivialInliner::perform+0x1c2 (inliner.cpp:229, 0x000000005AD375E2 [j9jit29+0x3e75e2])
    02:22:18.198  OMR::Optimizer::performOptimization+0x1709 (omroptimizer.cpp:2061, 0x000000005ADDAFE9 [j9jit29+0x48afe9])
    02:22:18.198  OMR::Optimizer::optimize+0x426 (omroptimizer.cpp:1143, 0x000000005ADDBB16 [j9jit29+0x48bb16])
    02:22:18.198  OMR::Compilation::compile+0x71f (omrcompilation.cpp:1074, 0x000000005AC3C28F [j9jit29+0x2ec28f])
    02:22:18.198  TR::CompilationInfoPerThreadBase::compile+0x7d6 (compilationthread.cpp:8954, 0x000000005A9A6976 [j9jit29+0x56976])
    02:22:18.198  TR::CompilationInfoPerThreadBase::wrappedCompile+0x11ee (compilationthread.cpp:8486, 0x000000005A9A847E [j9jit29+0x5847e])
    02:22:18.198  runInTryExcept+0x16 (omrsignal.c:220, 0x00007FF844A6DE46 [j9prt29+0x1de46])
    02:22:18.198  omrsig_protect+0x1d4 (omrsignal.c:286, 0x00007FF844A6E044 [j9prt29+0x1e044])
    02:22:18.198  TR::CompilationInfoPerThreadBase::compile+0x3fc (compilationthread.cpp:7645, 0x000000005A9A8D1C [j9jit29+0x58d1c])
    02:22:18.198  TR::CompilationInfoPerThread::processEntry+0x202 (compilationthread.cpp:4192, 0x000000005A9A92E2 [j9jit29+0x592e2])
    02:22:18.198  TR::CompilationInfoPerThread::processEntries+0x15a (compilationthread.cpp:3882, 0x000000005A9A40CA [j9jit29+0x540ca])
    02:22:18.198  protectedCompilationThreadProc+0x17e (compilationthread.cpp:3691, 0x000000005A9A707E [j9jit29+0x5707e])
    02:22:18.198  omrsig_protect+0x20f (omrsignal.c:297, 0x00007FF844A6E07F [j9prt29+0x1e07f])
    02:22:18.198  compilationThreadProc+0x26d (compilationthread.cpp:3599, 0x000000005A9A88CD [j9jit29+0x588cd])
    02:22:18.198  thread_wrapper+0x12d (omrthread.c:1634, 0x00007FF844AA5D6D [J9THR29+0x5d6d])
    02:22:18.198  _endthreadex+0x43 (0x000000005B3C1D9F [msvcr100+0x21d9f])
    02:22:18.198  _endthreadex+0xdf (0x000000005B3C1E3B [msvcr100+0x21e3b])
    02:22:18.198  BaseThreadInitThunk+0x14 (0x00007FF8533F84D4 [KERNEL32+0x84d4])
    02:22:18.198  RtlUserThreadStart+0x21 (0x00007FF853B1E8B1 [ntdll+0x6e8b1])
    02:22:18.198  ---------------------------------------
    02:22:18.198  JVMDUMP039I Processing dump event "gpf", detail "" at 2019/11/28 15:57:07 - please wait.
    02:22:18.198  JVMDUMP032I JVM requested System dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\core.20191128.155707.9096.0001.dmp' in response to an event
    02:22:42.485  JVMDUMP010I System dump written to C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\core.20191128.155707.9096.0001.dmp
    02:22:42.485  JVMDUMP032I JVM requested Java dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\javacore.20191128.155707.9096.0002.txt' in response to an event
    02:22:42.485  JVMDUMP010I Java dump written to C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\javacore.20191128.155707.9096.0002.txt
    02:22:42.485  JVMDUMP032I JVM requested Snap dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\Snap.20191128.155707.9096.0003.trc' in response to an event
    02:22:42.485  JVMDUMP010I Snap dump written to C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\Snap.20191128.155707.9096.0003.trc
    02:22:42.485  JVMDUMP007I JVM Requesting JIT dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\jitdump.20191128.155707.9096.0004.dmp'
    02:22:45.439  ----- Build times -------
    02:22:45.439  Start 2019-11-28 13:50:23
    02:22:45.439  End   2019-11-28 15:57:32
    02:22:45.439  00:01:46 corba
    02:22:45.439  00:03:00 demos
    02:22:45.439  00:06:52 docs
    02:22:45.439  00:16:49 images
    02:22:45.439  00:01:43 jaxp
    02:22:45.439  00:09:40 jaxws
    02:22:45.439  00:25:48 jdk
    02:22:45.439  00:01:46 langtools
    02:22:45.439  00:00:47 nashorn
    02:22:45.439  02:07:10 TOTAL
    02:22:45.439  -------------------------
    02:22:46.354  Finished building OpenJDK for target 'all'
    [Pipeline] }
    [Pipeline] // dir
    [Pipeline] }
    [Pipeline] // withEnv
    [Pipeline] }
    [Pipeline] // stage
    [Pipeline] stage
    [Pipeline] { (Java Version)
    [Pipeline] dir
    02:22:46.896  Running in C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal
    [Pipeline] {
    [Pipeline] sh
    02:22:49.318  + build/windows-x86_64-normal-server-release/images/j2sdk-image/bin/java -version
    02:22:50.318  Assertion failed at C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\build\windows-x86_64-normal-server-release\vm\compiler\env\J9SharedCache.cpp:457: false
    02:22:50.318  VMState: 0x000503ff
    02:22:50.318    Shared cache offset out of bounds
    02:22:50.318  compiling java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at level: cold
    02:22:50.318  
    02:22:50.318  Unhandled exception
    02:22:50.318  Type=Segmentation error vmState=0x000503ff
    02:22:50.318  Windows_ExceptionCode=c0000005 J9Generic_Signal=00000004 ExceptionAddress=000000005AC98AA6 ContextFlags=0010005f
    02:22:50.318  Handler1=000000005A99B660 Handler2=00007FF844A6CC70 InaccessibleWriteAddress=0000000000000000
    02:22:50.318  RDI=000000000FD68B58 RSI=000000000FD68B50 RAX=0000000000000000 RBX=000A42E7ED469368
    02:22:50.318  RCX=AF4FCAD190C30000 RDX=0000000000000000 R8=0000000000000069 R9=00000000000000CB
    02:22:50.318  R10=00000000000002C0 R11=0000000000000059 R12=0000000000000003 R13=FFFFFFFFF02974A8
    02:22:50.318  R14=000000000EA1DE00 R15=000000000ECBA1C0
    02:22:50.318  RIP=000000005AC98AA6 RSP=000000000FD689B0 RBP=000000000FD68B98 GS=002B
    02:22:50.318  FS=0053 ES=002B DS=002B
    02:22:50.318  XMM0 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM1 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM2 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM3 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM4 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM5 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM6 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM7 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM8 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM9 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM10 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM11 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM12 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM13 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM14 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  XMM15 0000000000000000 (f: 0.000000, d: 0.000000e+000)
    02:22:50.318  Module=C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\build\windows-x86_64-normal-server-release\images\j2sdk-image\jre\bin\compressedrefs\j9jit29.dll
    02:22:50.318  Module_base_address=000000005A950000 Offset_in_DLL=0000000000348aa6
    02:22:50.318  
    02:22:50.318  Method_being_compiled=java/util/Hashtable.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
    02:22:50.318  Target=2_90_20191128_219 (Windows Server 2016 10.0 build 14393)
    02:22:50.318  CPU=amd64 (8 logical CPUs) (0x3fff9a000 RAM)
    02:22:50.318  ----------- Stack Backtrace -----------
    02:22:50.318  openjdk version "1.8.0_242-internal"
    02:22:50.318  OpenJDK Runtime Environment (build 1.8.0_242-internal-jenkins_2019_11_28_13_45-b00)
    02:22:50.319  Eclipse OpenJ9 VM (build master-630b93cdc, JRE 1.8.0 Windows Server 2016 amd64-64-Bit Compressed References 20191128_219 (JIT enabled, AOT enabled)
    02:22:50.319  OpenJ9   - 630b93cdc
    02:22:50.319  OMR      - df66e8cca
    02:22:50.319  JCL      - 680fa0e62db based on jdk8u242-b01)
    02:22:50.319  TR::trap+0xc6 (assert.cpp:64, 0x000000005AC98AA6 [j9jit29+0x348aa6])
    02:22:50.319  TR::fatal_assertion+0x1d (assert.cpp:165, 0x000000005AC98D1D [j9jit29+0x348d1d])
    02:22:50.319  TR_J9SharedCache::pointerFromOffsetInSharedCache+0x54 (j9sharedcache.cpp:457, 0x000000005A9C7E84 [j9jit29+0x77e84])
    02:22:50.319  TR_IPBCDataCallGraph::loadFromPersistentCopy+0xe8 (iprofiler.cpp:3148, 0x000000005AA7CBB8 [j9jit29+0x12cbb8])
    02:22:50.319  TR_IProfiler::profilingSample+0x378 (iprofiler.cpp:1514, 0x000000005AA80858 [j9jit29+0x130858])
    02:22:50.319  TR_IProfiler::getCGProfilingData+0x2d (iprofiler.cpp:3204, 0x000000005AA7A86D [j9jit29+0x12a86d])
    02:22:50.319  TR_IProfiler::createIProfilingValueInfo+0x322 (iprofiler.cpp:2401, 0x000000005AA7EFC2 [j9jit29+0x12efc2])
    02:22:50.319  TR_IProfiler::getValueProfileInfo+0x1a3 (iprofiler.cpp:2538, 0x000000005AA7D9D3 [j9jit29+0x12d9d3])
    02:22:50.319  TR_ValueProfileInfoManager::getValueInfo+0x162 (j9profiler.cpp:986, 0x000000005AA86512 [j9jit29+0x136512])
    02:22:50.319  TR_ProfileableCallSite::findProfiledCallTargets+0x86 (j9inliner.cpp:1097, 0x000000005AA629E6 [j9jit29+0x1129e6])
    02:22:50.319  TR_InlinerBase::getSymbolAndFindInlineTargets+0x30e (inliner.cpp:3996, 0x000000005AD3EFAE [j9jit29+0x3eefae])
    02:22:50.319  TR_DumbInliner::analyzeCallSite+0xda (inliner.cpp:1316, 0x000000005AD412EA [j9jit29+0x3f12ea])
    02:22:50.319  TR_DumbInliner::inlineCallTargets+0x359 (inliner.cpp:1276, 0x000000005AD37C19 [j9jit29+0x3e7c19])
    02:22:50.319  TR_InlinerBase::performInlining+0x91 (inliner.cpp:454, 0x000000005AD34EF1 [j9jit29+0x3e4ef1])
    02:22:50.319  TR_TrivialInliner::perform+0x1c2 (inliner.cpp:229, 0x000000005AD375E2 [j9jit29+0x3e75e2])
    02:22:50.319  OMR::Optimizer::performOptimization+0x1709 (omroptimizer.cpp:2061, 0x000000005ADDAFE9 [j9jit29+0x48afe9])
    02:22:50.319  OMR::Optimizer::optimize+0x426 (omroptimizer.cpp:1143, 0x000000005ADDBB16 [j9jit29+0x48bb16])
    02:22:50.319  OMR::Compilation::compile+0x71f (omrcompilation.cpp:1074, 0x000000005AC3C28F [j9jit29+0x2ec28f])
    02:22:50.319  TR::CompilationInfoPerThreadBase::compile+0x7d6 (compilationthread.cpp:8954, 0x000000005A9A6976 [j9jit29+0x56976])
    02:22:50.319  TR::CompilationInfoPerThreadBase::wrappedCompile+0x11ee (compilationthread.cpp:8486, 0x000000005A9A847E [j9jit29+0x5847e])
    02:22:50.319  runInTryExcept+0x16 (omrsignal.c:220, 0x00007FF844A6DE46 [j9prt29+0x1de46])
    02:22:50.319  omrsig_protect+0x1d4 (omrsignal.c:286, 0x00007FF844A6E044 [j9prt29+0x1e044])
    02:22:50.319  TR::CompilationInfoPerThreadBase::compile+0x3fc (compilationthread.cpp:7645, 0x000000005A9A8D1C [j9jit29+0x58d1c])
    02:22:50.319  TR::CompilationInfoPerThread::processEntry+0x202 (compilationthread.cpp:4192, 0x000000005A9A92E2 [j9jit29+0x592e2])
    02:22:50.319  TR::CompilationInfoPerThread::processEntries+0x15a (compilationthread.cpp:3882, 0x000000005A9A40CA [j9jit29+0x540ca])
    02:22:50.319  protectedCompilationThreadProc+0x17e (compilationthread.cpp:3691, 0x000000005A9A707E [j9jit29+0x5707e])
    02:22:50.319  omrsig_protect+0x20f (omrsignal.c:297, 0x00007FF844A6E07F [j9prt29+0x1e07f])
    02:22:50.319  compilationThreadProc+0x26d (compilationthread.cpp:3599, 0x000000005A9A88CD [j9jit29+0x588cd])
    02:22:50.319  thread_wrapper+0x12d (omrthread.c:1634, 0x00007FF844AA5D6D [J9THR29+0x5d6d])
    02:22:50.319  _endthreadex+0x43 (0x000000005B3C1D9F [msvcr100+0x21d9f])
    02:22:50.319  _endthreadex+0xdf (0x000000005B3C1E3B [msvcr100+0x21e3b])
    02:22:50.319  BaseThreadInitThunk+0x14 (0x00007FF8533F84D4 [KERNEL32+0x84d4])
    02:22:50.319  RtlUserThreadStart+0x21 (0x00007FF853B1E8B1 [ntdll+0x6e8b1])
    02:22:50.319  ---------------------------------------
    02:22:50.319  JVMDUMP039I Processing dump event "gpf", detail "" at 2019/11/28 15:57:39 - please wait.
    02:22:50.319  JVMDUMP032I JVM requested System dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\core.20191128.155739.2652.0001.dmp' in response to an event
    02:22:53.305  JVMDUMP010I System dump written to C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\core.20191128.155739.2652.0001.dmp
    02:22:53.305  JVMDUMP032I JVM requested Java dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\javacore.20191128.155739.2652.0002.txt' in response to an event
    02:22:54.224  JVMDUMP010I Java dump written to C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\javacore.20191128.155739.2652.0002.txt
    02:22:54.224  JVMDUMP032I JVM requested Snap dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\Snap.20191128.155739.2652.0003.trc' in response to an event
    02:22:54.224  JVMDUMP010I Snap dump written to C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\Snap.20191128.155739.2652.0003.trc
    02:22:54.224  JVMDUMP007I JVM Requesting JIT dump using 'C:\Users\jenkins\workspace\Build_JDK8_x86-64_windows_Personal\jitdump.20191128.155739.2652.0004.dmp'
    
    点赞 评论 复制链接分享
  • weixin_39682477 weixin_39682477 4月前

    Thanks , that helps a lot.

    So, this is easy enough to fix (just check whether the pointer is in the SCC before trying to load from it), but I don't understand why the problem is happening in the first place.

    The assert fires because in https://github.com/eclipse/openj9/blob/7f2b25241458f5beeae53881201ed0b4342b60a7/runtime/compiler/runtime/IProfiler.cpp#L3140-L3148 store->_csInfo.getClazz(i) isn't in the SCC. However, there's this safety check when adding to the store: https://github.com/eclipse/openj9/blob/7f2b25241458f5beeae53881201ed0b4342b60a7/runtime/compiler/runtime/IProfiler.cpp#L3098-L3122

    So given that the offset was definitely in the SCC when it was stored, I don't get how it could no longer be in the SCC 😕 .

    Maybe we allocated the wrong object here: https://github.com/eclipse/openj9/blob/7f2b25241458f5beeae53881201ed0b4342b60a7/runtime/compiler/runtime/IProfiler.cpp#L1500-L1513 but it's kind of a stretch.

    do you have any ideas?

    Also , there are a few of these asserts; do they still hold in the multi SCC world?

    点赞 评论 复制链接分享

相关推荐