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

invokevirtual_quick_w exception mishandled

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      1.1.5
    • CPU:
      unknown
    • OS:
      solaris_2.5
    • Verification:
      Verified

      Description


      Date: Thu, 4 Sep 1997 11:26:47 -0700
      From: Frank Yellin <###@###.###>
      To: never@pan, david.bowen@pan
      CC: dlong@pan
      Subject: Bug in executeJava_p5.inc


      Dave and Tom:

      We've found a bug in executeJava_p5.inc, part of the assembly loop for the
      x86.

      The end of the code after the label Lb(ivqw_not_ijn) needs to be as follows:


      xor eax,eax
      xor edx,edx
      MOV(eax,al,BYTE PTR [esi+3])

      MOV(edx,dl, BYTE PTR [ecx + ee_exceptionKind]) ;exception?
      mov DWORD PTR [ebx + javaframe_optop], edi
      test edx,edx
      jnz Lb(N0_ivq_invoker_error)
         add esi,3 ;esi=frame->returnpc
         Dispatch0

      Note that that line "add esi,3" has been moved until after it has been
      determined that the method call finished without any errors. As a side
      effect, we needed to change
      MOV(eax,al,BYTE PTR [esi])
      to be
      MOV(eax,al,BYTE PTR [esi+3])

      Ignore the fact that in ur copy of the code, the antepenultimate line is
      jnz Lb(N0_ivq_invoker_error) a zero
      while yours has
      jnz Lb(NO_ivq_invoker_error) a capital o
      This is a historical bogon that should eventually be fixed. (I think zero
      goes better with N1 and N2, rather than the word "no")

      Not fixing this bug causes an assertion failure when running a debugged
      version of the code. One test in the JCK kills a process when it is in
      the middle of calling sink.notifyAll() in the following code.

          public synchronized void flush() throws IOException {
      if (sink != null) {
                  synchronized (sink) {
                      sink.notifyAll();
                  }
      }
          }

      The process notices the exception, but because it's PC (esi) has already
      been incremented, it thinks it is outside the range of the "synchronized".
      The lock is never released.

      == Frank

      john.bui@eng 1997-10-17

      No specific test case available. Implicity tested, verified with exposure.

        Attachments

          Activity

            People

            Assignee:
            never Tom Rodriguez
            Reporter:
            never Tom Rodriguez
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: