United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4828700 : JDK 1.4.1_02 C1 crashes during compilation

Details
Type:
Bug
Submit Date:
2003-03-06
Status:
Resolved
Updated Date:
2003-03-18
Project Name:
JDK
Resolved Date:
2003-03-18
Component:
hotspot
OS:
solaris_8
Sub-Component:
compiler
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.1_02
Fixed Versions:
1.4.2 (b19)

Related Reports
Backport:

Sub Tasks

Description
JDK 1.4.1_02 C1 crashes during compilation, on Sol8.

Attached is a standalone reproduceable test case (testcase_030603.tar) which 
exhibits this problem (untar and run "ksh test_template.sh" to reproduce the
problem).

The hotspot error is as follows:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 4 occurred at PC=0xB2F6C
Function=[Unknown.]
Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.

Current Java thread:

Dynamic libraries:
0x10000         /export/javaprod/j2sdk1.4.1_02/bin/java
0xff340000      /usr/lib/libthread.so.1
0xff380000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff320000      /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
0xfe000000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/client/libjvm.so
0xff2d0000      /usr/lib/libCrun.so.1
0xff1d0000      /usr/lib/libsocket.so.1
0xff100000      /usr/lib/libnsl.so.1
0xff0d0000      /usr/lib/libm.so.1
0xff300000      /usr/lib/libw.so.1
0xff0b0000      /usr/lib/libmp.so.2
0xff060000    /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/native_threads/libhpi.so
0xff030000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/libverify.so
0xfe7c0000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/libjava.so
0xfe7a0000      /export/javaprod/j2sdk1.4.1_02/jre/lib/sparc/libzip.so
0xfe4e0000      /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2

Local Time = Thu Mar  6 11:03:19 2003
Elapsed Time = 9
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.1_02-b06 mixed mode)
#
# An error report file has been saved as hs_err_pid2145.log.
# Please refer to the file for further information.
#
Abort - core dumped


The native stack is as follows:
jtech% /net/statt/opt/FD7/SUNWspro/bin/dbx /export/javaprod/j2sdk1.4.1_02/bin/java core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc
Reading java
core file header read successfully
Reading ld.so.1
Reading libthread.so.1
Reading libdl.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading libjvm.so
Reading libCrun.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.1
Reading libw.so.1
Reading libmp.so.2
Reading libhpi.so
Reading libverify.so
Reading libjava.so
Reading libzip.so
Reading en_US.ISO8859-1.so.2
detected a multithreaded program
t@1 (l@1) terminated by signal ABRT (Abort)
0xff359794: __sigprocmask+0x0008:       jmp     %o7 + 0x8
(dbx) 
(dbx) where                                                                  
current thread: t@1
=>[1] __sigprocmask(0x0, 0xffbecec8, 0x0, 0x0, 0x0, 0x0), at 0xff359794
  [2] _resetsig(0xff35bf6c, 0x0, 0x0, 0x288f0, 0xff36e000, 0x0), at 0xff34e9a0
  [3] _sigon(0x288f0, 0xff375938, 0x6, 0xffbecf9c, 0x288f0, 0x6), at 0xff34e140
  [4] _thrp_kill(0x0, 0x1, 0x6, 0xff36e000, 0x1, 0xff2be438), at 0xff351180
  [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2be3a4, 0x4), at 0xff24b568
  [6] abort(0xff2ba000, 0xffbed0f0, 0x0, 0xfffffff8, 0x4, 0xffbed111), at 0xff23587c
  [7] os::abort(0x1, 0xfe3efed6, 0xffbed190, 0x0, 0xfe43d4d4, 0xfe339314), at 0xfe33af48
  [8] os::handle_unexpected_exception(0x2c728, 0x4, 0xb2f6c, 0xffbedec8, 0x4, 0xfe33d164), at 0xfe339384
  [9] JVM_handle_solaris_signal(0xb2f6c, 0xffbedec8, 0xffbedc10, 0x4000, 0x4318, 0x0), at 0xfe33d410
  [10] __sighndlr(0x4, 0xffbedec8, 0xffbedc10, 0xfe33bd38, 0x28994, 0x28984), at 0xff35b830
  [11] sigacthandler(0x4, 0x288f0, 0x0, 0x0, 0x0, 0xff36e000), at 0xff358508
  ---- called from signal handler with signal 4 (SIGILL) ------
  [12] 0xb2f6c(0x82, 0x82, 0xffbee0b4, 0xfe428000, 0x1b84, 0xffbedfc8), at 0xb2f6b
  [13] 0xfa405c64(0xf6118168, 0x0, 0xffbee0c8, 0xfa415398, 0x2ccdc, 0xffbee058), at 0xfa405c63
  [14] 0xfa405c64(0xf20111b0, 0xffbee1e4, 0xffbee1e8, 0xfa415078, 0x1, 0xffbee100), at 0xfa405c63
  [15] 0xfa405c64(0xf20111b0, 0xffbee1f0, 0xffbee1f0, 0xfa415030, 0xfa40ac74, 0xffbee188), at 0xfa405c63
  [16] 0xfa405c64(0xf200ef48, 0xf6118168, 0x0, 0xfa415030, 0xf200ef48, 0xffbee218), at 0xfa405c63
  [17] 0xfa4989e8(0xf2071c00, 0xf2071ba0, 0xf200ef48, 0x0, 0x0, 0x0), at 0xfa4989e7
  [18] 0xfa405c64(0xf203dfd0, 0x20, 0x8, 0xfa415030, 0xf2200000, 0xffbee3c0), at 0xfa405c63
  [19] 0xfa405c64(0xf203dfd0, 0xb6, 0x2, 0xfa415030, 0xf6114250, 0xffbee448), at 0xfa405c63
  [20] 0xfa405c64(0xffbee530, 0x0, 0x0, 0xfa415030, 0x3611ec, 0xffbee4d0), at 0xfa405c63
  [21] 0xfa400118(0xffbee5bc, 0xffbee7b8, 0xa, 0xf61145f0, 0xfa40aae0, 0xffbee6b8), at 0xfa400117
  [22] JavaCalls::call_helper(0xffbee7b0, 0xffbee670, 0xffbee6b0, 0x2c728, 0x2c728, 0x5c00), at 0xfe0d4bec
  [23] jni_invoke_static(0x1, 0xffbee7b0, 0x0, 0x0, 0xba730, 0xffbee794), at 0xfe0ecafc
  [24] jni_CallStaticVoidMethod(0x2c7b4, 0x2d18c, 0xba730, 0x2d19c, 0x2c7b4, 0xf203dfc0), at 0xfe189854
  [25] main(0x4, 0x0, 0xba730, 0x2d19c, 0xba745, 0x284), at 0x12538
(dbx) quit
jtech% 
jtech% 
jtech% 

This problem does not happen with b16 of jdk 1.4.2 beta.


                                    

Comments
EVALUATION

Can reproduce with 1.4.1_02 but appears to be fixed already in 1.4.2.

###@###.### 2003-03-06


Given that this doesn't show up in the current release the customer should file
an escalation to have this fixed in a previous release if necessary.

###@###.### 2003-03-07


###@###.### was able to reproduce this with the current 1.4.2 and
further investigation shows that when the classes are compiled with the 1.4.1
javac both the 1.4.1 and 1.4.2 VMs crash, but when the classes are compiled with
the 1.4.2 javac (which I believe eliminates most jsr/ret pairs) the result works
on both 1.4.1 and 1.4.2. Will commit to 1.4.2 pending further investigation.

###@###.### 2003-03-10


The problem is that excessive amounts of relocation information are being
generated due to pathological inlining of jsr/rets in the JSP's bytecodes.
The 1.4.2 javac inlines these jsrs at the bytecode level; the VM then doesn't
need to perform any inlining. Added a bailout check on the relocation portion
of C1's temporary codebuffer.

###@###.### 2003-03-10


Fixed in 1.4.2.

###@###.### 2003-03-13
                                     
2003-03-10
WORK AROUND


1) A viable workaround is to exclude the following method in .hotspot_compiler
   file:
	      exclude notification_jsp_ _templateService
   This workaround works fine for the attached test case (testcase_030603.tar).
	      	  	
2) Also this problem does not happen with C2 (server) compiler, but 
   unfortunately using C2 compiler is not an option in this scenario.
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis-beta

FIXED IN:
mantis-beta

INTEGRATED IN:
mantis-b19
mantis-beta
tiger-b03


                                     
2004-06-14



Hardware and Software, Engineered to Work Together