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

putfield_quick_w exception mishandled

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P3
    • 1.1.5
    • 1.1.2
    • hotspot
    • 1.1.5
    • x86
    • windows_nt
    • Verified

    Description



      Name: joT67522 Date: 08/28/97



      There is a bug in the virtual machine source file executeJava_p5.m4 . The handler
      for the opcode putfield_quick_w increments the interpreter pc before checking for
      an exception. If the bytecode is the last one in a try block, this will cause the pc not
      to be found in the exception handler table in the event of an exception.

      The original code from executeJava_p5.m4 is as follows:

          Def012(putfield_quick_w)
      mov edx, DWORD PTR _cp$[esp]
      mov ah, BYTE PTR [esi+1]
      mov al, BYTE PTR [esi+2]
      add esi, 3
      mov eax, DWORD PTR [edx+eax*4]
      mov edx, DWORD PTR [eax+fb_signature]
      mov eax, [eax+fb_offset]
      mov dl, BYTE PTR [edx]
      cmp dl, SIGNATURE_LONG
      je Lb($pqw_islong)
      cmp dl, SIGNATURE_DOUBLE
      je Lb($pqw_islong)
      Verify(ebx,ne,0,NullPointer,SP(2))
      mov ebx, DWORD PTR [ebx+o_obj]
      mov [ebx+eax], ecx
      xor eax, eax
      Ld_opc(0)
      Dispatch0
         Lb($pqw_islong):
      mov edx, [edi-4]

      It should be changed to:

          Def012(putfield_quick_w)
      mov edx, DWORD PTR _cp$[esp]
      mov ah, BYTE PTR [esi+1]
      mov al, BYTE PTR [esi+2]
         ; DELETE add esi, 3
      mov eax, DWORD PTR [edx+eax*4]
      mov edx, DWORD PTR [eax+fb_signature]
      mov eax, [eax+fb_offset]
      mov dl, BYTE PTR [edx]
      cmp dl, SIGNATURE_LONG
      je Lb($pqw_islong)
      cmp dl, SIGNATURE_DOUBLE
      je Lb($pqw_islong)
      Verify(ebx,ne,0,NullPointer,SP(2))
          ******* add esi, 3 ; *** ADD ******************************
      mov ebx, DWORD PTR [ebx+o_obj]
      mov [ebx+eax], ecx
      xor eax, eax
      Ld_opc(0)
      Dispatch0
         Lb($pqw_islong):
        ******** add esi, 3 ; *** ADD ******************************
      mov edx, [edi-4]

      I came across this problem running the following Java program with a JIT compiler that chose not to compile main:

        class IntList
        {
            public IntList next;
            IntList( ){ next = null; }
        }

        public class test
        {
            public static void main(String args[])
            {
                IntList x = new IntList();
                try {
                    x.next.next = x;
                } catch (NullPointerException f) {
                    System.out.println( "caught exception" );
                }
            }
        }

      The exception is not caught; a call stack is dumped instead.

      The bug does not occur if a JIT compiler is not loaded, because UseLosslessOpcodes
      gets set to FALSE and the putfield_quick opcode gets used instead of putfield_quick_w.
      It does not occur if the JIT compiler compiles main because (obviously) the interpreter
      does not run all.

      You can make the same bug occur if you either build a "null" JIT compiler or just go
      into the JVM code and force the global UseLosslessOpcodes to TRUE.



      company - equator technologies consulting , email - ###@###.###
      ======================================================================

      Attachments

        Activity

          People

            never Tom Rodriguez
            johsunw Joon Oh (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: