JDK-6227033 : hotspot crashes(SIGSEGV) when many local variables are used in one java program
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2005-02-09
  • Updated: 2010-08-03
  • Resolved: 2005-03-30
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 JDK 6
1.4.2_10Fixed 6 b30Fixed
Related Reports
Relates :  
Relates :  
Description
When a java program uses a lot of local variables,
hotspot crashes.

CONFIGURATION :
  JRE/JDK : JDK6.0b22/JDK5.0fcs/1.4.2_07
  OS      : Solaris8
        (SunOS goedel 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-60)
  
REPRODUCE :
  1) Compile the attached program(INT_TEST_3.java)
  2) Launch "java INT_TEST_3"
  
  You will see the following messages in terminal windows and a log file 
  is created under current directory.

goedel[25]% java -showversion INT_TEST_3
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b22)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b22, mixed mode)

START
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xf889db9c, pid=20000, tid=11
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b22 mixed mode)
# Problematic frame:
# J  INT_TEST_3.TEST_FUNC()I
#
# An error report file with more information is saved as hs_err_pid20000.lo
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Abort


NOTE:
  Hotspot does not seem to handle the case that stack offset becomes
  larger than 4096 on OSR.
  This seems to cause the reported issue...



###@###.### 2005-2-09 02:33:41 GMT

Comments
SUGGESTED FIX Fixed in 1.6 b30. Webrev for fix: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050323192658.kbr.c2_baseline/workspace/webrevs/webrev-2005.03.23/index.html ###@###.### 2005-06-22 22:51:43 GMT
2005-06-22

EVALUATION The attached test case crashes on SPARC under the client compiler from 1.4.2 forward and the server compiler from 1.5 forward. The server compiler in 1.4.2 seems to run the test case properly. On x86 the client compiler runs the test correctly with versions 1.4.2 - 1.6; the server compiler crashes with 1.4.2 but not with 1.5 or 1.6. The suggested fix for C1 on SPARC seems to address part of the problem but not all of it. 1.4.2_06 with the patch asserts during oop map construction during the compile, but if the assert is suppressed the compile succeeds and the code runs correctly. Interestingly, in a newer version of C1 which produces the OSR entry point very differently, the crash still occurs. We need to make multiple sub-CRs of this CR against C1 on 1.4.2, 1.5 and 1.6 and against C2 on 1.4.2 (on x86) and 1.5 and 1.6 (on SPARC). ###@###.### 2005-2-16 20:48:33 GMT Filed 6242350 to track the C2 changes. ###@###.### 2005-03-17 19:55:03 GMT The customer's suggested fix was integrated along with a new bailout which checks to make sure oops being placed into the oop map are not too far away from the stack pointer for the OopMapValue to encode. ###@###.### 2005-03-24 22:30:51 GMT
2005-02-16

WORK AROUND -Xint ###@###.### 2005-2-09 16:40:50 GMT
2005-02-09