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 Dmitry 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 Dmitry 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 Dmitry 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 Dmitry 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 Dmitry 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 Dmitry Samersoff added a comment - ForceEralyReturn call makes receiver frame invalid when other thread attempts to execute invokevirtual so hotspot either crashes or asserts.

            People

            • Assignee:
              dsamersoff Dmitry Samersoff
              Reporter:
              sboikovsunw Semen Boikov (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Imported:
                Indexed: