JDK-4546590 : clsunload003 test crashes with runtime.cpp, 1552 in comp mode in build88
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.3.1_09,1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2001-12-04
  • Updated: 2002-04-17
  • Resolved: 2002-02-24
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.1 hopperFixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Test : nsk/jvmpi/events/clsunload003
TestBase : testbase_nsk
VM: -d64 -server
Mode:comp
OS: Solsparc(5.8 , 5.9)
Also,
Mode:comp , mixed
OS:Solx86 (32 bit)
VM:server

Steps to reproduce 
(solsprac):
================
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit /net/sqesvr.eng/export/vsn/VM/merlin/weekly/jdk/latest/solsparc/bin/java server -d64 -Xcomp
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.0-rc-b88 compiled mode)
#
# Error ID: 52554E54494D450E4350500610 01
#
# Problematic Thread: prio=5 tid=0x10010e440 nid=0x1 runnable 
#
Abort
STATUS=134

solx86 -Mixed
=========
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit /net/sqesvr.eng/export/vsn/VM/merlin/weekly/jdk/latest/solx86/bin/java 
server -Xmixed
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b88)
Java HotSpot(TM) Server VM (build 1.4.0-rc-b88, mixed mode)
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.0-rc-b88 mixed mode)
#
# Error ID: 52554E54494D450E4350500610
#
# Problematic Thread: prio=5 tid=0x806a500 nid=0x1 runnable 
#
Abort
STATUS=134

solx86-comp
============
sh doit /net/sqesvr.eng/export/vsn/VM/merlin/weekly/jdk/latest/solx86/bin/java 
server -Xcomp
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b88)
Java HotSpot(TM) Server VM (build 1.4.0-rc-b88, compiled mode)
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.0-rc-b88 compiled mode)
#
# Error ID: 52554E54494D450E4350500610
#
# Problematic Thread: prio=5 tid=0x806a500 nid=0x1 runnable 
#
Abort
STATUS=134


###@###.### 2001-12-04





Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper
14-06-2004

SUGGESTED FIX The fix is to wrap the call in runtime.cpp to fast_exception_handler_bci_for() with the same sort of do-loop found around other calls to this function in c1_Runtime1.cpp, interpreterRuntime.cpp and jvmdi.cpp. One can make the argument that a second exception should not be thrown while searching the exception table, but we can save that problem for a different bug. ###@###.### 2001-12-17 ------- runtime.cpp ------- 1443,1445c1443,1466 < int handler_bci = force_unwind ? -1 < : ssd.method()->fast_exception_handler_bci_for(exception->klass(), ssd.bci(), true, THREAD); < guarantee(!HAS_PENDING_EXCEPTION, "expected compilation of this method to bail out; see bug 4307310"); --- > int handler_bci = -1; > if (!force_unwind) { > bool should_repeat; > int bci = ssd.bci(); > do { > should_repeat = false; > // exception handler lookup > handler_bci = ssd.method()->fast_exception_handler_bci_for(exception->klass(), bci, true, THREAD); > if (HAS_PENDING_EXCEPTION) { > // We threw an exception while trying to find the exception handler. > // Transfer the new exception to the exception handle which will > // be set into thread local storage, and do another lookup for an > // exception handler for this exception, this time starting at the > // BCI of the exception handler which caused the exception to be > // thrown (bugs 4307310 and 4546590). > exception = Handle(PENDING_EXCEPTION); > CLEAR_PENDING_EXCEPTION; > if (handler_bci >= 0) { > bci = handler_bci; > should_repeat = true; > } > } > } while (should_repeat == true); > } ###@###.### 2003-11-06
06-11-2003

PUBLIC COMMENTS Verified the bug on solx86. However while trying to verify the bug for solsparc noticed that the test does not progress and just hangs . Will be submitting a new bug for the solsparc failure. ###@###.### 2002-03-18
18-03-2002

EVALUATION Might be a regression of bug 4307310. ###@###.### 2001-12-05 This is related to, but not the same as 4307310. In the process of looking for a handler in a compiled method for an OutOfMemory exception, the VM generates a second pending execption. The runtime code for C2 does not handle this situation properly. ###@###.### 2001-12-12
12-12-2001