Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6449023

Crash in JDI test against ForceEarlyReturn

    Details

    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      Following JDI test fails because of debuggee VM crashes:
      nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007
      (this test should be included in testbase r07)

      This test starts in debuggee VM 20 threads and for one of them calls several times forceEarlyReturn (through com.sun.jdi.ThreadReference), test crashes very fast.

      Bug is reproduces on all platforms.

      hs_err file is attached.

        Issue Links

          Activity

          Hide
          sspitsyn Serguei Spitsyn added a comment -
          BT2:EVALUATION

          This can be a bug in the ForceEarlyReturn implementation,
          but more time is needed to investigate it.
          It is too late for Mustang RC, so I'm targetting it to the Mustang update 6u1.
          Show
          sspitsyn Serguei Spitsyn added a comment - BT2:EVALUATION This can be a bug in the ForceEarlyReturn implementation, but more time is needed to investigate it. It is too late for Mustang RC, so I'm targetting it to the Mustang update 6u1.
          Hide
          sspitsyn Serguei Spitsyn added a comment -
          BT2:EVALUATION

          Thanks to Alan who pointed out that this bug looks like an instance of the old bug:
           4926272 methodOopDesc::method_from_bcp is unsafe
          Show
          sspitsyn Serguei Spitsyn added a comment - BT2:EVALUATION Thanks to Alan who pointed out that this bug looks like an instance of the old bug:  4926272 methodOopDesc::method_from_bcp is unsafe
          Hide
          sspitsyn Serguei Spitsyn added a comment -
          BT2:EVALUATION

          It looks like this bug is a regression introduced in the Mustang b89 build.
          The build b88 has different failure mode indicating other problems which can be
          whether in the test itself or the other known problem in the product (which has not been
          fixed yet).
          Current plan is to isolate the particular prt integration caused this regression.
          Show
          sspitsyn Serguei Spitsyn added a comment - BT2:EVALUATION It looks like this bug is a regression introduced in the Mustang b89 build. The build b88 has different failure mode indicating other problems which can be whether in the test itself or the other known problem in the product (which has not been fixed yet). Current plan is to isolate the particular prt integration caused this regression.
          Hide
          sspitsyn Serguei Spitsyn added a comment -
          BT2:EVALUATION

          This is strange...
          It looks like this is not a regression which came from one of the prt integrations.
          It is reproducible if the build b89 has taken as a base of the prt_isolate search.
          And it is never reproducible if the build b88 is taken as a base.
          So, probably, some integration on the SDK side triggered this bug to appear.
          Another explanation would be that this bug appearence depends on the memory layout
          which always confuses any analysis.
          Show
          sspitsyn Serguei Spitsyn added a comment - BT2:EVALUATION This is strange... It looks like this is not a regression which came from one of the prt integrations. It is reproducible if the build b89 has taken as a base of the prt_isolate search. And it is never reproducible if the build b88 is taken as a base. So, probably, some integration on the SDK side triggered this bug to appear. Another explanation would be that this bug appearence depends on the memory layout which always confuses any analysis.
          Hide
          sspitsyn Serguei Spitsyn added a comment -
          BT2:EVALUATION

          I've deleted my last evaluation record as it was incorrect.
          It is another manifestation of the bug:
           4926272 methodOopDesc::method_from_bcp is unsafe
          I'm able to duplicate the 4926272 with the VM flag -XX:+UseConcMarkSweepGC using the test:
            nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007

          But more work needs to be done in order to prove that this bug is a dup of 4926272.
          The prove would be to demonstrate that the fix for 4926272 fixes 6449023 as well.
          Show
          sspitsyn Serguei Spitsyn added a comment - BT2:EVALUATION I've deleted my last evaluation record as it was incorrect. It is another manifestation of the bug:  4926272 methodOopDesc::method_from_bcp is unsafe I'm able to duplicate the 4926272 with the VM flag -XX:+UseConcMarkSweepGC using the test:   nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007 But more work needs to be done in order to prove that this bug is a dup of 4926272. The prove would be to demonstrate that the fix for 4926272 fixes 6449023 as well.
          Hide
          sspitsyn Serguei Spitsyn added a comment - - edited
          At the time when this issue was filed this test failure could be reproduced very reliably on all platforms.
          It is not reproducible on Solaris platforms now in hundreds of runs.
          Also I do not see fresh failing rules against this test which means the test did not fail in the nightly for a while.
          I'm closing this issue as "Cannot reproduce".
          Show
          sspitsyn Serguei Spitsyn added a comment - - edited At the time when this issue was filed this test failure could be reproduced very reliably on all platforms. It is not reproducible on Solaris platforms now in hundreds of runs. Also I do not see fresh failing rules against this test which means the test did not fail in the nightly for a while. I'm closing this issue as "Cannot reproduce".
          Hide
          dsamersoff Dmitriy Samersoff added a comment -
          Always reproducible with the same stack trace:

          Stack: [0x00002b75a3ebb000,0x00002b75a3fbc000], sp=0x00002b75a3fba7d8, free space=1021k
          Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
          j java.lang.String.valueOf(Ljava/lang/Object;)Ljava/lang/String;+10 java.base@9-internal
          j java.lang.StringBuilder.append(Ljava/lang/Object;)Ljava/lang/StringBuilder;+2 java.base@9-internal
          j nsk.share.jpda.ForceEarlyReturnTestThread.executeMethod(Ljava/lang/String;)V+904
          j nsk.share.jpda.ForceEarlyReturnTestThread.run()V+82
          v ~StubRoutines::call_stub
          V [libjvm.so+0xe70e90] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x960
          V [libjvm.so+0xe6ddf8] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x478
          V [libjvm.so+0xe6e0ae] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0xce
          V [libjvm.so+0xfb3bcf] thread_entry(JavaThread*, Thread*)+0xcf
          V [libjvm.so+0x16cf6ae] JavaThread::thread_main_inner()+0x24e
          V [libjvm.so+0x16cf94d] JavaThread::run()+0x1dd
          V [libjvm.so+0x13f9012] thread_native_entry(Thread*)+0x112
          C [libpthread.so.0+0x7494] start_thread+0xc4
          Show
          dsamersoff Dmitriy Samersoff added a comment - Always reproducible with the same stack trace: Stack: [0x00002b75a3ebb000,0x00002b75a3fbc000], sp=0x00002b75a3fba7d8, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j java.lang.String.valueOf(Ljava/lang/Object;)Ljava/lang/String;+10 java.base@9-internal j java.lang.StringBuilder.append(Ljava/lang/Object;)Ljava/lang/StringBuilder;+2 java.base@9-internal j nsk.share.jpda.ForceEarlyReturnTestThread.executeMethod(Ljava/lang/String;)V+904 j nsk.share.jpda.ForceEarlyReturnTestThread.run()V+82 v ~StubRoutines::call_stub V [libjvm.so+0xe70e90] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x960 V [libjvm.so+0xe6ddf8] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x478 V [libjvm.so+0xe6e0ae] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0xce V [libjvm.so+0xfb3bcf] thread_entry(JavaThread*, Thread*)+0xcf V [libjvm.so+0x16cf6ae] JavaThread::thread_main_inner()+0x24e V [libjvm.so+0x16cf94d] JavaThread::run()+0x1dd V [libjvm.so+0x13f9012] thread_native_entry(Thread*)+0x112 C [libpthread.so.0+0x7494] start_thread+0xc4
          Hide
          dsamersoff Dmitriy Samersoff added a comment - - edited
          Slightly modified hotspot gives us:

          [Current thread is 1 (Thread 0x2b6b03234700 (LWP 14840))]
          (gdb) bt
          #0 0x00002b6aab4a22e7 in raise () from /lib64/libc.so.6
          #1 0x00002b6aab4a376a in abort () from /lib64/libc.so.6
          #2 0x00002b6aac41f3ca in frame::retrieve_receiver (this=this@entry=0x2b6b0322f270, reg_map=reg_map@entry=0x2b6b0322f2a0) at /export/ESC/JDK-6449023/hs/hotspot/src/share/vm/runtime/frame.cpp:1057
          #3 0x00002b6aacd98d9d in SharedRuntime::find_callee_info_helper (thread=thread@entry=0x2b6ab08f1000, vfst=..., bc=@0x2b6b0323057c: Bytecodes::_invokevirtual, callinfo=...,
              __the_thread__=__the_thread__@entry=0x2b6ab08f1000) at /export/ESC/JDK-6449023/hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1159
          #4 0x00002b6aacd9b4c9 in SharedRuntime::find_callee_info (__the_thread__=0x2b6ab08f1000, callinfo=..., bc=@0x2b6b0323057c: Bytecodes::_invokevirtual, thread=0x2b6ab08f1000)
              at /export/ESC/JDK-6449023/hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1074
          #5 SharedRuntime::handle_ic_miss_helper (thread=thread@entry=0x2b6ab08f1000, __the_thread__=__the_thread__@entry=0x2b6ab08f1000)
              at /export/ESC/JDK-6449023/hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1520
          #6 0x00002b6aacda5e61 in SharedRuntime::handle_wrong_method_ic_miss (thread=0x2b6ab08f1000) at /export/ESC/JDK-6449023/hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1419
          #7 0x00002b6abe55629a in ?? ()
          #8 0x000000000000037f in ?? ()
          #9 0x0000000000000000 in ?? ()
          (gdb) frame 2
          #2 0x00002b6aac41f3ca in frame::retrieve_receiver (this=this@entry=0x2b6b0322f270, reg_map=reg_map@entry=0x2b6b0322f2a0) at /export/ESC/JDK-6449023/hs/hotspot/src/share/vm/runtime/frame.cpp:1057
          1057 abort();
          (gdb) p r
          $1 = {_o = 0x8b918108}
          (gdb) x/10x r._o
          0x8b918108: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe
          0x8b918118: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe
          0x8b918128: 0xbaadbabe 0xbaadbabe
          (gdb)

          Where:
          oop frame::retrieve_receiver(RegisterMap* reg_map) {
          ...
           VMReg reg = SharedRuntime::name_for_receiver();
           oop* oop_adr = caller.oopmapreg_to_location(reg, reg_map);
           oop r = *oop_adr;
          ...


          Show
          dsamersoff Dmitriy Samersoff added a comment - - edited Slightly modified hotspot gives us: [Current thread is 1 (Thread 0x2b6b03234700 (LWP 14840))] (gdb) bt #0 0x00002b6aab4a22e7 in raise () from /lib64/libc.so.6 #1 0x00002b6aab4a376a in abort () from /lib64/libc.so.6 #2 0x00002b6aac41f3ca in frame::retrieve_receiver (this=this@entry=0x2b6b0322f270, reg_map=reg_map@entry=0x2b6b0322f2a0) at /export/ESC/ JDK-6449023 /hs/hotspot/src/share/vm/runtime/frame.cpp:1057 #3 0x00002b6aacd98d9d in SharedRuntime::find_callee_info_helper (thread=thread@entry=0x2b6ab08f1000, vfst=..., bc=@0x2b6b0323057c: Bytecodes::_invokevirtual, callinfo=...,     __the_thread__=__the_thread__@entry=0x2b6ab08f1000) at /export/ESC/ JDK-6449023 /hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1159 #4 0x00002b6aacd9b4c9 in SharedRuntime::find_callee_info (__the_thread__=0x2b6ab08f1000, callinfo=..., bc=@0x2b6b0323057c: Bytecodes::_invokevirtual, thread=0x2b6ab08f1000)     at /export/ESC/ JDK-6449023 /hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1074 #5 SharedRuntime::handle_ic_miss_helper (thread=thread@entry=0x2b6ab08f1000, __the_thread__=__the_thread__@entry=0x2b6ab08f1000)     at /export/ESC/ JDK-6449023 /hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1520 #6 0x00002b6aacda5e61 in SharedRuntime::handle_wrong_method_ic_miss (thread=0x2b6ab08f1000) at /export/ESC/ JDK-6449023 /hs/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1419 #7 0x00002b6abe55629a in ?? () #8 0x000000000000037f in ?? () #9 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00002b6aac41f3ca in frame::retrieve_receiver (this=this@entry=0x2b6b0322f270, reg_map=reg_map@entry=0x2b6b0322f2a0) at /export/ESC/ JDK-6449023 /hs/hotspot/src/share/vm/runtime/frame.cpp:1057 1057 abort(); (gdb) p r $1 = {_o = 0x8b918108} (gdb) x/10x r._o 0x8b918108: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe 0x8b918118: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe 0x8b918128: 0xbaadbabe 0xbaadbabe (gdb) Where: oop frame::retrieve_receiver(RegisterMap* reg_map) { ...  VMReg reg = SharedRuntime::name_for_receiver();  oop* oop_adr = caller.oopmapreg_to_location(reg, reg_map);  oop r = *oop_adr; ...
          Hide
          dsamersoff Dmitriy Samersoff added a comment -
          ForceEralyReturn call makes receiver frame invalid when other thread attempts to execute invokevirtual so hotspot either crashes or asserts.
          Show
          dsamersoff Dmitriy Samersoff added a comment - ForceEralyReturn call makes receiver frame invalid when other thread attempts to execute invokevirtual so hotspot either crashes or asserts.
          Hide
          cjplummer Chris Plummer added a comment - - edited
          These failures look similar:

          RULE "nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007" Crash V ...[libjvm.so+...] Klass::method_at_vtable(int)+...
          RULE "nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007" Crash V ...[jvm.dll+...] Klass::method_at_vtable+...

          java.lang.String.valueOf() is on the java stack like other failures above, alone with SharedRuntime::handle_ic_miss_helper() on the native stack.
          Show
          cjplummer Chris Plummer added a comment - - edited These failures look similar: RULE "nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007" Crash V ...[libjvm.so+...] Klass::method_at_vtable(int)+... RULE "nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn007" Crash V ...[jvm.dll+...] Klass::method_at_vtable+... java.lang.String.valueOf() is on the java stack like other failures above, alone with SharedRuntime::handle_ic_miss_helper() on the native stack.
          Hide
          sspitsyn Serguei Spitsyn added a comment -
          This issue has not been seen in nightly since begin of June.
          Also, we never saw this failed on JDK10.
          I'm a little bit puzzled with this.
          Show
          sspitsyn Serguei Spitsyn added a comment - This issue has not been seen in nightly since begin of June. Also, we never saw this failed on JDK10. I'm a little bit puzzled with this.
          Hide
          cjplummer Chris Plummer added a comment -
          There are failures in 10, although not that many, and not with the regularity we saw with 9. Last failure on 10 was 2017-05-13, and I don't see any nightly failures on 10. Possibly we weren't doing quarantine runs on 10. On 9, if failed pretty much every week during nightlies, with the last one on 2017-08-26 (probably we didn't have much nightly testing after that).
          Show
          cjplummer Chris Plummer added a comment - There are failures in 10, although not that many, and not with the regularity we saw with 9. Last failure on 10 was 2017-05-13, and I don't see any nightly failures on 10. Possibly we weren't doing quarantine runs on 10. On 9, if failed pretty much every week during nightlies, with the last one on 2017-08-26 (probably we didn't have much nightly testing after that).
          Hide
          cjplummer Chris Plummer added a comment -
          I ran 300 times on JDK 10 on each supported platform and did not see any failures. 100 times with each of "-server -XX:TieredStopAtLevel=1", "-Xcomp -server -XX:TieredStopAtLevel=1", and " -Xmixed -server -XX:+UseG1GC", which are all options that were commonly reproduced failures in JDK 9. Given these results, I think this CR should be closed as CNR.
          Show
          cjplummer Chris Plummer added a comment - I ran 300 times on JDK 10 on each supported platform and did not see any failures. 100 times with each of "-server -XX:TieredStopAtLevel=1", "-Xcomp -server -XX:TieredStopAtLevel=1", and " -Xmixed -server -XX:+UseG1GC", which are all options that were commonly reproduced failures in JDK 9. Given these results, I think this CR should be closed as CNR.
          Hide
          sspitsyn Serguei Spitsyn added a comment - - edited
          Thanks, Chris!
          Closing this bug as "Cannot Reproduce".
          Please, reopen if it gets reproduced in JDK10 nightly.
          Show
          sspitsyn Serguei Spitsyn added a comment - - edited Thanks, Chris! Closing this bug as "Cannot Reproduce". Please, reopen if it gets reproduced in JDK10 nightly.
          Hide
          cjplummer Chris Plummer added a comment -
          This test was never removed from the quarantine list when the CR was closed. I just ran it 50 times, and it fails 29 on Linux/x64, 13 on macosx, and 7 on Windows/x64. However, I think it may be a different cause and introduced somewhat recently since I did not see these failures a month ago and the assert is different. In fact I think I ran it a week or two ago and saw no issues. I'll re-open this bug for now, but possibly a new one should be opened for it.

          Here's the assert and backtrace:

          # Internal Error (/scratch/opt/mach5/mesos/work_dir/slaves/55769d18-ab0b-47ef-be98-151e5144ba9a-S41969/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c4c8a46f-a98a-45c9-8591-42470ad27b27/runs/9ed2b119-bba5-44a6-bd2c-cfe799bd207c/workspace/open/src/hotspot/share/ci/ciEnv.cpp:957), pid=26394, tid=26425
          # assert(counter_changed) failed: failed dependencies, but counter didn't change

          Current thread (0x00007efecc3d7800): JavaThread "C2 CompilerThread2" daemon [_thread_in_vm, id=26425, stack(0x00007efe846e9000,0x00007efe847ea000)]

          Current CompileTask:
          C2: 8938 713 4 nsk.share.jpda.ForceEarlyReturnTestThread::executeMethod (1245 bytes)

          V [libjvm.so+0x181f112] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162
          V [libjvm.so+0x181fedf] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
          V [libjvm.so+0xb2d59d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
          V [libjvm.so+0x909900] ciEnv::validate_compile_task_dependencies(ciMethod*) [clone .part.105]+0x290
          V [libjvm.so+0x90f4e2] ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, RTMState)+0x702
          V [libjvm.so+0xa95446] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1766
          V [libjvm.so+0x8ae042] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2e2
          V [libjvm.so+0xa9faae] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38e
          V [libjvm.so+0xaa06a1] CompileBroker::compiler_thread_loop()+0x241
          V [libjvm.so+0x177950e] JavaThread::thread_main_inner()+0x22e
          V [libjvm.so+0x1779754] JavaThread::run()+0x184
          V [libjvm.so+0x14b333a] thread_native_entry(Thread*)+0xfa
          C [libpthread.so.0+0x7dc5] start_thread+0xc5
          Show
          cjplummer Chris Plummer added a comment - This test was never removed from the quarantine list when the CR was closed. I just ran it 50 times, and it fails 29 on Linux/x64, 13 on macosx, and 7 on Windows/x64. However, I think it may be a different cause and introduced somewhat recently since I did not see these failures a month ago and the assert is different. In fact I think I ran it a week or two ago and saw no issues. I'll re-open this bug for now, but possibly a new one should be opened for it. Here's the assert and backtrace: # Internal Error (/scratch/opt/mach5/mesos/work_dir/slaves/55769d18-ab0b-47ef-be98-151e5144ba9a-S41969/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c4c8a46f-a98a-45c9-8591-42470ad27b27/runs/9ed2b119-bba5-44a6-bd2c-cfe799bd207c/workspace/open/src/hotspot/share/ci/ciEnv.cpp:957), pid=26394, tid=26425 # assert(counter_changed) failed: failed dependencies, but counter didn't change Current thread (0x00007efecc3d7800): JavaThread "C2 CompilerThread2" daemon [_thread_in_vm, id=26425, stack(0x00007efe846e9000,0x00007efe847ea000)] Current CompileTask: C2: 8938 713 4 nsk.share.jpda.ForceEarlyReturnTestThread::executeMethod (1245 bytes) V [libjvm.so+0x181f112] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162 V [libjvm.so+0x181fedf] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f V [libjvm.so+0xb2d59d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd V [libjvm.so+0x909900] ciEnv::validate_compile_task_dependencies(ciMethod*) [clone .part.105]+0x290 V [libjvm.so+0x90f4e2] ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, RTMState)+0x702 V [libjvm.so+0xa95446] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1766 V [libjvm.so+0x8ae042] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2e2 V [libjvm.so+0xa9faae] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38e V [libjvm.so+0xaa06a1] CompileBroker::compiler_thread_loop()+0x241 V [libjvm.so+0x177950e] JavaThread::thread_main_inner()+0x22e V [libjvm.so+0x1779754] JavaThread::run()+0x184 V [libjvm.so+0x14b333a] thread_native_entry(Thread*)+0xfa C [libpthread.so.0+0x7dc5] start_thread+0xc5
          Hide
          sspitsyn Serguei Spitsyn added a comment -
          This crash is different that what we have seen before.
          I'll try to check if it is a relatively recent regression.
          Show
          sspitsyn Serguei Spitsyn added a comment - This crash is different that what we have seen before. I'll try to check if it is a relatively recent regression.
          Hide
          cjplummer Chris Plummer added a comment - - edited
          It appears to have been introduced yesterday. I could not reproduce it with any of the nightly binaries. Then I grabbed yesterday's nightly binary later in the day and it does reproduce with it. There were 4 compiler related commits yesterday.
          Show
          cjplummer Chris Plummer added a comment - - edited It appears to have been introduced yesterday. I could not reproduce it with any of the nightly binaries. Then I grabbed yesterday's nightly binary later in the day and it does reproduce with it. There were 4 compiler related commits yesterday.
          Hide
          sspitsyn Serguei Spitsyn added a comment - - edited
          I cloned the jdk/hs repository yesterday night and built the fastdebug image locally on linux-x64.
          Can't reproduce it yet . Should I use any specific options?
          I've alreay tried: "-Xcomp -server -XX:TieredStopAtLevel=1", and " -Xmixed -server -XX:+UseG1GC".
          Show
          sspitsyn Serguei Spitsyn added a comment - - edited I cloned the jdk/hs repository yesterday night and built the fastdebug image locally on linux-x64. Can't reproduce it yet . Should I use any specific options? I've alreay tried: "-Xcomp -server -XX:TieredStopAtLevel=1", and " -Xmixed -server -XX:+UseG1GC".
          Hide
          cjplummer Chris Plummer added a comment -
          It looks like it is due to JDK-8160548. I'm running again with the patch back in to verify.
          Show
          cjplummer Chris Plummer added a comment - It looks like it is due to JDK-8160548 . I'm running again with the patch back in to verify.
          Hide
          cjplummer Chris Plummer added a comment -
          I'm closing as CNR again and created JDK-8191733 for this new assert.
          Show
          cjplummer Chris Plummer added a comment - I'm closing as CNR again and created JDK-8191733 for this new assert.

            People

            • Assignee:
              sspitsyn Serguei Spitsyn
              Reporter:
              sboikovsunw Semen Boikov (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: