JDK-4804070 : RegTest-CTE test 4701980/b4701980.java fails on Solaris x86
  • Type: Bug
  • Component: other-libs
  • Sub-Component: other
  • Affected Version: 1.4.2,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris_8,solaris_9
  • CPU: x86
  • Submitted: 2003-01-16
  • Updated: 2005-11-14
  • Resolved: 2003-09-09
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
5.0 tigerFixed
Related Reports
Relates :  
JDK-4701980 - HPROF: -Xrunhprof option crashes and restarts S1AS app server
Description

Name: asR10013			Date: 01/16/2003


Filed By       : J2SE-SQA [###@###.###
JDK            : JDK1.4.2-b12
Testbase       : RegTest-CTE
Platform[s]    : Solaris 8 (x86), Solaris 9 (x86)
switch/Mode    : -XX:MarkSweepAlwaysCompactCount=1 prof_options=-Xrunhprof:cpu=samples
Falling test[s]: 
        CTE_REGTEST/Generic/4701980/b4701980.java 

RegTest-CTE CTE_REGTEST/Generic/4701980/b4701980.java test fails on 
Solaris x86, JDK1.4.2 (tested with b12, b11):

	Working block size could not be found.
	Unexpected exception: java.lang.Exception: b4701980: test FAILed.

The test passes on Solaris 8 (x86), Solaris 9 (x86) 
without prof_options=-Xrunhprof:cpu=samples.

The test passes on Solaris 8 (sparc), Solaris 9 (sparc) 
as with prof_options=-Xrunhprof:cpu=samples as without it.

Each "failed" or "passed" means did it 3 times of 3.

Test source location:
=====================
/net/jdk/export/jpse04/Regression/1.4.2/test/CTE_REGTEST/Generic/4701980/b4701980.java

jtr file location:
==================
/net/jtgb4u4c.sfbay/export/sail15/results/mantis/b12/regtest/x86/s8_-client_linux-10/workDir/cte/CTE_REGTEST/Generic/4701980/b4701980.jtr

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

RESULT_DIR=`pwd`
WORK_DIR=$RESULT_DIR/workDir/test
REPORT_DIR=$RESULT_DIR/reportDir
JT_HOME="/net/linux-15/export/home/java/jct"
JAVA_HOME="/net/linux-15/export/home/java/jdk1.4.2/x86"
TEST_BASE_PATH="/net/linux-15/export/home/java/regtest/cte"

TESTWITH=$JAVA_HOME
TESTJAVA=$JAVA_HOME

JTOPTS="-client"
TESTVMOPTS="-client"

CLASSPATH="$JT_HOME/classes:$JT_HOME/lib/javatest.jar:$JT_HOME/lib/jtreg.jar"

export JAVA_HOME
export JT_HOME
export TESTWITH
export CLASSPATH

mkdir -p $WORK_DIR/scratch 2>&1
mkdir -p $WORK_DIR/jtData 2>&1
mkdir -p $REPORT_DIR 2>&1

#rm $WORK_DIR/jtData/ResultCache.jtw 2>&1

cd $WORK_DIR/scratch

$JAVA_HOME/bin/java -cp $CLASSPATH $JTOPTS -DenvVars=TESTJAVAHOME=$JAVA_HOME,TESTVMOPTS=$TESTVMOPTS,DISPLAY=:0,HOME=$HOME/.regtest,PATH=/bin:/usr/bin,TZ=,LC_ALL=en_US,LC_CTYPE=en_US,LANG=en_US,LPDEST= -DDISPLAY=:0 -DlocalHost="linux-10" -Dprogram=jtreg com.sun.javatest.regtest.Main -a -v default -batch -params -w "$WORK_DIR" -r "$REPORT_DIR" -t "$TEST_BASE_PATH" "$TEST_BASE_PATH/CTE_REGTEST/Generic/4701980/b4701980.java"

--- script end ---

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

Test output (jtr part):
=======================
----------System.err:(0/0)----------
result: Passed. Compilation successful

#section:shell
----------messages:(3/130)----------
command: shell Test4701980.sh 
reason: User specified action: run shell/timeout=600 Test4701980.sh 
elapsed time (seconds): 3.576
----------System.out:(8/261)----------
  created: META-INF/
extracted: META-INF/MANIFEST.MF
extracted: i386libb4701980.so
extracted: linuxlibb4701980.so
extracted: sparclibb4701980.so
b4701980: starting test.
Allocated 59MB before getting OutOfMemoryError.
Remainder of test will run for 30 seconds.
----------System.err:(8/428)----------
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b12)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b12, mixed mode)
Working block size could not be found.
Unexpected exception: java.lang.Exception: b4701980: test FAILed.
Exception in thread "main" java.lang.Exception: b4701980: test FAILed.
	at b4701980.main(b4701980.java:24)
Dumping CPU usage by sampling running threads ... done.
result: Failed. Execution failed: exit code 1


test result: Failed. Execution failed: exit code 1


Specific machine info:
======================
Hostname: linux-10
OS: Solaris 8 (x86)

Hostname: linux-6
OS: Solaris 9 (x86)


======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger VERIFIED IN: tiger
14-06-2004
SUGGESTED FIX ###@###.### 2003-09-09 Here are the context diffs for the proposed fix to the test: ------- b4701980.java ------- *** /tmp/sccs.gHa4Oo Tue Sep 9 08:13:55 2003 --- b4701980.java Tue Sep 9 08:01:32 2003 *************** *** 49,65 **** // Phase 2: // This phase of the test tries to find a block size less than // 1MB that will work for the third section of the test. We ! // decrease the size by 128K for each allocation attempt. // int trySize = 1024 * 1024; while (true) { try { trySize -= (128 * 1024); if (trySize == 0) { ! System.err.println("Working block size could not be found."); throw new Exception("b4701980: test FAILed."); } byte[] junk = new byte[trySize]; junk = null; } catch (OutOfMemoryError e) { --- 49,84 ---- // Phase 2: // This phase of the test tries to find a block size less than // 1MB that will work for the third section of the test. We ! // decrease the size by 128K for each allocation attempt. If ! // we reach 0, then the 128K allocation didn't work and we ! // need to switch techniques. We reset trySize to 64K for the ! // next allocation attempt and we divide by 2 to decrease the ! // size for subsequent allocation attempts. If we drop below ! // 1K, then the algorithm will need to be tweaked again. // + int tryPhase = 1; int trySize = 1024 * 1024; while (true) { try { + if (tryPhase == 1) { trySize -= (128 * 1024); if (trySize == 0) { ! tryPhase++; ! trySize = (64 * 1024); ! } ! } else if (tryPhase == 2) { ! trySize /= 2; ! if (trySize < 1024) { ! System.err.println("Internal Test Error:" ! + " working block size could not be found."); throw new Exception("b4701980: test FAILed."); } + } else { + System.err.println("Internal Test Error: '" + + tryPhase + "': unknown test phase"); + throw new Exception("b4701980: test FAILed."); + } byte[] junk = new byte[trySize]; junk = null; } catch (OutOfMemoryError e) {
11-06-2004
EVALUATION It's a regression. ###@###.### 2003-09-08 Actually it's a broken test and I can say that since I wrote it. I'll have a better version of the test in the morning. ###@###.### 2003-09-09 The original algorithm is: - force a GC - allocate (and chain) 1MB chunks until no more are available - force a GC - set trySize = 1MB - do - trySize -= 128K - allocate trySize bytes - if allocation succeeds - null memory referene - break out of loop while allocation fails && trySize != 0 - force a GC - for 30 seconds - allocate trySize bytes - null memory reference - force a GC - verify that heap still has less than 1MB left The test was designed to exercise low memory allocations. The test originally revealed a problem where the following sequence failed: - allocate N-byte block - free block - allocate N-byte block again The second allocation failed even though the same size block was just freed. Memory was otherwise quiescent. The problem was tracked down to the "compaction phase" of GC only being executed every 4th GC. Enough with history. The problem with the algorithm is that trySize never gets smaller than 128K before giving up. This means if the last available memory block is smaller than 128K, then we will never find it. -------- As Danienl suggested, I've modified the testcase. Should pass now. ###@###.### 2003-09-09
09-09-2003