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.
  
=========================================================================