JDK-4828700 : JDK 1.4.1_02 C1 crashes during compilation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1_02
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-03-06
  • Updated: 2003-03-18
  • Resolved: 2003-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 b19Fixed
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
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-b19 mantis-beta tiger-b03
14-06-2004
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.
11-06-2004
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
10-03-2003