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

SEGV or SIGBUS in JVM with PopAsynchronousTest.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 1.4.0, 1.4.1
    • Fix Version/s: 1.4.1
    • Component/s: vm-legacy
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      rc
    • CPU:
      generic, sparc
    • OS:
      generic, solaris, solaris_7, solaris_8
    • Verification:
      Verified

      Description


      PopAsynchronousTest case fails in latest hotspot jvm. The jvm crashes with
      SEGV or SIGBUS.


      ###@###.### 2002-04-08


      The problem is VM is crashing in invokevirtual helper due to bad Lesp.

        __ ld_ptr(Rrecv, base + vtableEntry::method_offset_in_bytes(), Gmethod);
        
        The Rrecv is either a bad address or misaligned address. So we get SEGV or SIGBUS.
        

      I do not know how Lesp set up is done. If it is executing in pure -Xint mode the
      Lesp is never get bad. Beacuse it is switching from compiled frame to interpreted
      frame the Lesp got bad I think. I think as a part of deoptimization unpack_frame
      process the Lesp should be setup for the interpreted frames. Correct me if I am
      wrong.

      This is what is happening in the testcase when the first PopFrame request
      is pending:

      Stack trace:
      0xf9c8fc58() <==== Deoptimized frames
      0xf9c8fc58()
      0xf9c8fc58()


      Before Unpack_frames:
      0xf9c0c778()
      0xdead0001()
      0xdead0001()
      0xf9c8fc58()
      0xf9c8fc58()

      After unpack frames:
      0xf9c0c778()
      0xf9c06570() <=== deopt entry ( Now it is Interpreted frames )
      0xf9c0652c() <=== return entry ( Now it is Interpreted frames )
      0xf9c8fc58()
      0xf9c8fc58()


      After unpack frames it deopt entry code starts executing and it will
      enter the code in generate_throw_exception for actual frame pop and
      deopt entry get poped off here and returns to the return entry frame.


      After FramePop:
      0xf9c0652c() <=== return entry ( Now it is Interpreted frames )
      0xf9c8fc58()
      0xf9c8fc58()


      If the return entry starts executing and if the next byte code instruction
      is invokevirtual then it will crash in that code because the Lesp is
      not set up correctly as per the interpreter calling convention at this time.

      I do not know when and how the Lesp should be set up. I feel deoptimization
      unpack_frames should do it or popframe should set this Lesp. How to fix Lesp
      is not clear to me.




      I think we have another problem with save params and retrieve params.

      After unpack frames:
      0xf9c0652c() <=== return entry ( say maps to java method foo() of class X )
      0xf9c8fc58() <=== deoptimization handler
      0xf9c8fc58()

      If a PopFrame request is pending at this time and deoptimized_caller bit
      is set the popframe code in generate_throw_exception saves the
      parameter of current return entry point frame and then this frame
      get popped off from the stack and return it to deoptimized handler frame.
      Now popframe_processing_bit_mask is set in popframe_condition_addr.

      Now deoptimized handler unpacks the vframe so:

      After unpack frames:
      0xf9c8fc58() <=== deoptimization handler
      0xf9c04570() <=== deopt entry (say maps to java method bar() of class Y)
      0xf9c0652c() <=== return entry
      0xf9c8fc58()

      After unpack frame the HOTSWAP code in deoptimized handler removes the
      deopt entry frame and restore the previously saved params. This is
      some thing does not look right to me. Now it has replaced the
      java method bar() of class Y parameter got replaced with parameters
      of foo() of class X.

      See this code in c1_Runtime1_sparc.cpp

       __ restore() // Get out of the deoptimization handler frame
       
       This line of code removes the deopt entry frame and then do
       retrieving of params and then dispatch next byte code.

      If we can figure out how to set up the Lesp then we can easily
      fix this I think.



      Also we should check if the fix for bug 4646985. This may be related
      to this problem. Please check with Ken.

      Thanks,
      Swamy

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              kbr Kenneth Russell (Inactive)
              Reporter:
              swamyv Swamy Venkataramanappa
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: