JDK-4852688 : JCK1.4a-runtime tests fail with VM abort on Itanium/RH2.1AS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: itanium
  • Submitted: 2003-04-23
  • Updated: 2022-04-05
  • Resolved: 2003-05-13
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 b23Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description

Name: vsR10238			Date: 04/23/2003


Filed By       : J2SE-SQA [###@###.###
JDK            : JDK1.5.0, JDK1.4.2-b20, JDK1.4.2-b07, JDK1.4.2-b10
JCK            : JCK1.4a-runtime
Platform[s]    : RedHat Linux 2.1 Adv. Server/Itanium
switch/Mode    : -Xmixed, -Xcomp
JCK test owner : http://javaweb.eng/jck/usr/owners.jto
Falling test[s]: 
        api/java_lang/Character/index.html#attributesFullRange
        api/java_lang/Character/index.html#getAttrFullRange
        api/java_nio/ByteBuffer/index.html#GetPutXXX
        api/java_security/Signature/SignatureTests.html#SIGclone
        api/java_security/SignedObject/SignedObjectTests.html#verifyTests
        api/java_security/Signature/SignatureTests.html#update3
        api/java_security/Signature/SignatureTests.html#update4
        api/java_security/Signature/SignatureTests.html#verify
        api/java_security/SignedObject/SignedObjectTests.html#miscTests
        api/java_security/SignedObject/SignedObjectTests.html#getSignatureTests
        api/java_security/Signature/SignatureTests.html#toString
        api/java_security/Signature/SignatureTests.html#update2
        api/java_security/SignedObject/SignedObjectTests.html#CtorGetTests
        api/java_security/SignedObject/serial/index.html#ConstructorTests 
        api/java_security/Signature/SignatureTests.html#initSign
        api/java_security/Signature/SignatureTests.html#initVerify
        api/java_security/Signature/SignatureTests.html#signTests
        api/java_security/Signature/SignatureTests.html#update
        api/java_util/TimeZone/index.html#getDisplayName
        api/signaturetest/SignatureTest.html#java 
        api/signaturetest/SignatureTest.html#javax.swing

JCK1.4a-runtime tests fail with VM abort on Itanium/RH2.1AS in mixed or compiled mode.
The tests above fail always due to this reason. The tests pass in interpreted mode (-Xint).

The failure is reproducible with JDK1.4.2 builds b07-b20. Since JDK1.4.1 and JDK1.4.2 builds b06
and earlier always run in the interpreted mode (despite the -Xcomp switch), I am not marking
the test as REGRESSION although the tests pass on JDK1.4.1 and JDK1.4.2 builds b06
and earlier with -Xcomp.

The failure is probably caused by 4760743 or is related to this bug.

Some other tests fail intermittently. 
The following tests also failed on my manual(interactive) test run on RH2.1AS/Itanium, JDK1.4.2-b20:

        api/javax_swing/interactive/JInternalFrameTests.html#JInternalFrame
        api/javax_swing/interactive/JSliderTests.html#JSlider
        api/javax_swing/interactive/JCheckBoxTests.html#JCheckBox
        api/javax_swing/interactive/JDialogTests.html#JDialog
        api/javax_swing/interactive/JTableTests.html#JTable


Test source location:
=====================
/java/re/jck/1.4a/archive/fcs/binaries/JCK-runtime-14a/tests/api/java_security/Signature/update2Tests.java

How to reproduce:
=================
Run the following script (you may need to change its variables)
 
--- script start ---
#!/bin/bash

JCK="/net/jtgb4u4c.sfbay/export/sail16/JCK/jck14a/JCK-runtime-14a"
#JDK="/net/jtgb4u4c/export/sail16/JDK/1.4.2-b20/j2sdk1.4.2"
JDK="/java/re/jdk/1.4.2/promoted/rc/b20/binaries/linux-ia64"
#JDK="/java/re/jdk/1.4.1/promoted/fcs/b21/binaries/linux-ia64"

switches="-Xcomp"
CLASSPATH="$JCK/classes"

echo '========================='
$JDK/bin/java $switches -version
echo '========================='
echo $JDK/bin/java $switches -cp $CLASSPATH javasoft.sqe.tests.api.java.security.Signature.update2Tests 
echo '========================='
$JDK/bin/java $switches -cp $CLASSPATH javasoft.sqe.tests.api.java.security.Signature.update2Tests 

--- script end ---

Script output:
============

=========================
java version "1.4.2-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-rc-b20)
Java HotSpot(TM) 64-Bit Server VM (build 1.4.2-rc-b20, compiled mode)
=========================
/java/re/jdk/1.4.2/promoted/rc/b20/binaries/linux-ia64/bin/java -Xcomp -cp /net/jtgb4u4c.sfbay/export/sail16/JCK/jck14a/JCK-runtime-14a/classes javasoft.sqe.tests.api.java.security.Signature.update2Tests
=========================
#
# 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.2-rc-b20 compiled mode)
#
# Error ID: 4E4154495645294E53543F494116140E435050006F
#
# Problematic Thread: prio=1 tid=0x6000000000009760 nid=0x2b5d runnable 
#

Heap at VM Abort:
Heap
 def new generation   total 1984K, used 160K [0x2000000044860000, 0x2000000044a80000, 0x2000000045db0000)
  eden space 1792K,   8% used [0x2000000044860000, 0x20000000448880e0, 0x2000000044a20000)
  from space 192K,   0% used [0x2000000044a20000, 0x2000000044a20000, 0x2000000044a50000)
  to   space 192K,   0% used [0x2000000044a50000, 0x2000000044a50000, 0x2000000044a80000)
 tenured generation   total 1408K, used 0K [0x2000000045db0000, 0x2000000045f10000, 0x2000000048860000)
   the space 1408K,   0% used [0x2000000045db0000, 0x2000000045db0000, 0x2000000045db0200, 0x2000000045f10000)
 compacting perm gen  total 16384K, used 1474K [0x2000000048860000, 0x2000000049860000, 0x200000004c860000)
   the space 16384K,   8% used [0x2000000048860000, 0x20000000489d08f8, 0x20000000489d0a00, 0x2000000049860000)


Specific machine info:
======================
Hostname: JCC-ITANIUM-01
OS: RedHat Linux 2.1 Adv. Server (2.4.18-e.12smp)

======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-rc FIXED IN: mantis-rc INTEGRATED IN: mantis-b23 mantis-rc tiger tiger-b08 VERIFIED IN: mantis-rc tiger
08-07-2004

PUBLIC COMMENTS .
08-07-2004

SUGGESTED FIX The fix is to always generate an dummy methodDataOop during such a deopt, even if ProfileInterpreter is off. It gets marked appropriately, causing c2 to do the right thing. I've made the change ia64-specific, because I believe it's too late in the release cycle to safely make this change for all platforms. An alternative fix would be to disable heroic optimizations if ProfileInterpreter is off. I deemed this to be a potential performance regression, so didn't choose this option. I did verify that it also solves the problem. ###@###.### 2003-05-08
08-05-2003

EVALUATION Using the b21 jdk, the vm gets into an infinite compile/uncommon-trap/deopt loop. It doesn't assert. The infinite loop is caused by the fact that (1) methodDataOop's (i.e. ProfileInterpreter) are not supported in the ia64 port (2) c2 performs heroic optimizations that, when they fail, generate uncommon traps and deopt (3) deopt marks the methodData entry for the trapping bytecode as "don't do this again", so that c2 won't generate the offending code the next time around, but (4) there's no methodData entry to mark, so c2 regenerates the trapping code on the next go-round and (5) we do it all over again. ###@###.### 2003-05-01
01-05-2003