jtreg throws StackOverflowError when writing xml report

Martin Buchholz martinrb at google.com
Mon Feb 16 00:46:35 UTC 2009


There have been recent changes to the
UTF_8 encoder in OpenJDK that might be responsible.
You can try to isolate the exact change to UTF_8 that
could cause this difference, and then create a proper test case.

changeset:   497:3dcc69147ff9
user:        sherman
date:        Fri Aug 22 14:37:46 2008 -0700
summary:     4486841: UTF-8 decoder should adhere to corrigendum to
Unicode 3.0.1

It is surprising that one can get StackOverflowError without
a very long stack trace of methods invoking themselves recursively,
which is not what we're seeing.

Martin

On Wed, Feb 11, 2009 at 10:38, Omair Majid <omajid at redhat.com> wrote:
> Hi all,
>
> I am trying to generate xml reports from jtreg. The problem is that jtreg
> throws a StackOverflowError when writing the output xml file when running
> the jdk tests. The xml report works fine for the 16 compiler tests and 1351
> langtools tests.
>
> I am using Icedtea6 to run the tests. These are the commands it executes:
>
> $ mkdir -p test/jdk/JTwork test/jdk/JTreport
> $ /notnfs/omajid/icedtea6/bootstrap/jdk1.6.0/bin/java \
>        -Djavatest.report.kinds="xml text html" \
>        -jar test/jtreg.jar -v1 -a -ignore:quiet \
>        -w:test/jdk/JTwork -r:test/jdk/JTreport \
>        -s -jdk:`pwd`/openjdk/control/build/linux-i586/j2sdk-image \
>        `pwd`/openjdk/jdk/test \
>        | tee test/check-jdk.log
>
> The error appears after the jtreg run completes:
>
> [ lots of output ]
> Passed: vm/verifier/VerifyProtectedConstructor.java
> Passed: vm/verifier/VerifyStackForExceptionHandlers.java
> Test results: passed: 3,306; failed: 73; error: 5
> Exception in thread "main" java.lang.StackOverflowError
>    at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:76)
>    at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:411)
>    at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:466)
>    at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561)
>    at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:258)
>    at java.lang.StringCoding.encode(StringCoding.java:290)
>    at java.lang.String.getBytes(String.java:954)
>    at
> com.sun.org.apache.xml.internal.serializer.EncodingInfo.inEncoding(EncodingInfo.java:413)
>    at
> com.sun.org.apache.xml.internal.serializer.EncodingInfo.access$100(EncodingInfo.java:62)
>    at
> com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:205)
>    at
> com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:181)
>    at
> com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:181)
>    [...SNIP...]
>    at
> com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:181)
>
>
> Has anyone ever seen this before?
>
> Thanks,
> Omair
>
>



More information about the core-libs-dev mailing list