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

Compiler2 seems to generate wrong native code(null-check) in 1.4.1._01

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.4.1_01
    • Fix Version/s: None
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_2000

      Description

      A licensee faces with hotspot crash which occurs at their important
      customer. This seems caused from invalid generated code by compiler2.

      The followings are their report.

      CONFIGURATION:
         - Windows 2000 Server (uni-processor)
         - 1.4.1_01 (server VM)
         
         
      === Licensee's Report =========
         
      The JVM(1.4.1_01 server VM) outputs the flowing and terminates.
        
      #
      # Fatal: null exception in compiled code
      #
      # Error ID: 53484152454432554E54494D450E435050019B

        Note : Error ID is decoded share/vm/runtime/sharedRuntime.cpp
        
      We investigate the log and source code.
      Compiler2 seems to generate wrong native code of "null check".
      That results in the abnormal end with some error at
        guarantee(cont_offset != 0, "null exception in compiled code");
      in sharedRuntime.cpp.

      The following are details.
       Note:
        We investigate in modifying the Sun's original source code.
       ( We enable the debug code #ifdef ASSERT - #endif block
        just before the above-mentioned "guarantee" in sharedRuntime.cpp
        in order that
          tty->print_cr("implicit exception happened at 0x%lx", pc)
         can work.)
         
         
         
      implicit exception happened at 0x886196
      ....
               main code [0x00886150,0x00886312] = 450
               exception code [0x00886312,0x00886320] = 14
               relocation [0x0088612C,0x00886150] = 36
               oops [0x00886474,0x008864D4] = 96
               scopes data [0x00886320,0x00886410] = 240
               scopes pcs [0x00886410,0x00886440] = 48
               nul chk table [0x00886440,0x00886474] = 52

      00886150 3b4104 cmp eax,[ecx+0x4]
      00886153 0f85a785fbff jne 0083e700
      00886159 90 nop
      0088615a 90 nop
      0088615b 90 nop
      0088615c 89842400c0ffff mov [esp-0x4000],eax
      00886163 81ec1c000000 sub esp,0x1c
      00886169 8b5908 mov ebx,[ecx+0x8]
      0088616c 8b4304 mov eax,[ebx+0x4]
      0088616f 81f8c0208a58 cmp eax,0x588a20c0
      00886175 0f857d010000 jne 008862f8
      0088617b 8974240c mov [esp+0xc],esi
      0088617f 896c2410 mov [esp+0x10],ebp
      00886183 897c2414 mov [esp+0x14],edi
      00886187 895c2404 mov [esp+0x4],ebx
      0088618b 8b5110 mov edx,[ecx+0x10]
      0088618e 890c24 mov [esp],ecx
      00886191 8b4b08 mov ecx,[ebx+0x8]
      00886194 8bc1 mov eax,ecx
      00886196 8b7804 mov edi,[eax+0x4] <-- null pointer exception
      00886199 85c9 test ecx,ecx
      0088619b 0f84e8000000 je 00886289

      Although the null pointer exception occurs at 0x886196, this exception is
      not included in the above nul check table[0x00886440,0x00886474]
      as "implicit exception".
      So, this "null pointer exception" at 0x886196 should be dealt as
      "explicit exception".

      We look at the code where exception occurs more closely.

      00886194 8bc1 mov eax,ecx
      00886196 8b7804 mov edi,[eax+0x4] <-- null pointer exception
      00886199 85c9 test ecx,ecx
      0088619b 0f84e8000000 je 00886289

      If the exception is dealt as "explicit exception", the code

         00886196 8b7804 mov edi,[eax+0x4] <-- null pointer exception
         
      should be placed after the following "test" instruction and "je" instruction.
      However, actually, that code are before test and je instructions.


      SUMMARY:

        - This null pointer exception is not included in nul chk table as
          implicit exception.
          This should be treated as explicit exception.
        - If the exception is treated so, the
            "mov edi,[eax+0x4]"
          is (should be) placed before test and je instructions, but actually not.
        - This JVM termination seems caused from the above inconsistency.
        - The consistency is caused from the native code which compiler2 generates.
        - We believe compiler2 generates such inconsistent native code.
        
      =========================================================================
        

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              rasbold Chuck Rasbold
              Reporter:
              tbaba Tadayuki Baba (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: