jtreg throws StackOverflowError when writing xml report

[Omair Majid]

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

[Jonathan Gibbons]

Omair,

Since you're using IcedTea to run jtreg, I would suggest you investigate the
possibility that this is an IcedTea issue.

The bug would appear to be in
com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding
so it does not look like a jtreg or jtharness issue.

Can I suggest you try and use Sun's JDK to run jtreg, while still using the
JDK of your choice to execute the tests.

-- Jon


Omair Majid 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
>

[Omair Majid]

Hi Jon,

Jonathan Gibbons wrote:

> Since you're using IcedTea to run jtreg, I would suggest you investigate
> the
> possibility that this is an IcedTea issue.
>
> The bug would appear to be in
> com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding
>
> so it does not look like a jtreg or jtharness issue.
>
> Can I suggest you try and use Sun's JDK to run jtreg, while still using the
> JDK of your choice to execute the tests.

I get the exact same behaviour when using Sun's JDK (build 1.6.0_12-b04)
to run jtreg.

Omair

[Omair Majid]

Hi Jon,

Jonathan Gibbons wrote:

> Since you're using IcedTea to run jtreg, I would suggest you investigate
> the
> possibility that this is an IcedTea issue.
>
> The bug would appear to be in
> com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding
>
> so it does not look like a jtreg or jtharness issue.
>
> Can I suggest you try and use Sun's JDK to run jtreg, while still using the
> JDK of your choice to execute the tests.

I was wondering if you have run the entire jdk suite using jtreg with
the -Djavatest.report.kinds="xml text html" option. It is only when
using this option that the jtreg crashes.

Thanks,
Omair

[Jonathan Gibbons]

Omair,

I suspect there is some specific test or tests in the test suite  
causing output that it provoking this error  in the xml encoder.
I doubt that it is the quantity of tests in the entire jdk suite that  
is causing the issue.

Would it be possible for you to try and narrow it down by running  
jtreg on (just) each of the top level subdirectories of test/
and then if one shows the fault, on the each of the subdirectories of  
that, and so on?

-- Jon



On Feb 12, 2009, at 7:33 AM, Omair Majid wrote:

> Hi Jon,
>
> Jonathan Gibbons wrote:
>> Since you're using IcedTea to run jtreg, I would suggest you  
>> investigate the
>> possibility that this is an IcedTea issue.
>> The bug would appear to be in
>> com.sun.org.apache.xml.internal.serializer.EncodingInfo
>> $EncodingImpl.isInEncoding so it does not look like a jtreg or  
>> jtharness issue.
>> Can I suggest you try and use Sun's JDK to run jtreg, while still  
>> using the
>> JDK of your choice to execute the tests.
>
> I was wondering if you have run the entire jdk suite using jtreg  
> with the -Djavatest.report.kinds="xml text html" option. It is only  
> when using this option that the jtreg crashes.
>
> Thanks,
> Omair

[Omair Majid]

Hi Jon,

Jonathan Gibbons wrote:
> I suspect there is some specific test or tests in the test suite causing
> output that it provoking this error  in the xml encoder.
> I doubt that it is the quantity of tests in the entire jdk suite that is
> causing the issue.
>
> Would it be possible for you to try and narrow it down by running jtreg
> on (just) each of the top level subdirectories of test/
> and then if one shows the fault, on the each of the subdirectories of
> that, and so on?

Thanks for that bit of advice. The problem seems to be in
test/java/beans/PropertyEditor/TestStringClassJava.java. Mark Wielaard
pointed out that the test generates a string with characters 0x1000 to
0x1 and prints it to stdout. It appears the xml parser trips over that.
Removing the output fixes the problem.

Cheers,
Omair

[Jonathan Gibbons]

Thanks for the update; I was expecting something around
java.lang.Character myself,
but definitely that sort of problem. Do you want to file a bug against
the XML encoder?

-- Jon

Omair Majid wrote:

> Hi Jon,
>
> Jonathan Gibbons wrote:
>> I suspect there is some specific test or tests in the test suite
>> causing output that it provoking this error  in the xml encoder.
>> I doubt that it is the quantity of tests in the entire jdk suite that
>> is causing the issue.
>>
>> Would it be possible for you to try and narrow it down by running
>> jtreg on (just) each of the top level subdirectories of test/
>> and then if one shows the fault, on the each of the subdirectories of
>> that, and so on?
>
> Thanks for that bit of advice. The problem seems to be in
> test/java/beans/PropertyEditor/TestStringClassJava.java. Mark Wielaard
> pointed out that the test generates a string with characters 0x1000 to
> 0x1 and prints it to stdout. It appears the xml parser trips over
> that. Removing the output fixes the problem.
>
> Cheers,
> Omair

[martinrb]

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@...> 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
>
>

[Jonathan Gibbons]

Martin,

Given the [SNIP] in the middle of the trace, I would think we are seeing
>> com.sun.org.apache.xml.internal.serializer.EncodingInfo
>> $EncodingImpl.isInEncoding(EncodingInfo.java:181)
invoking itself recursively.

-- Jon

On Feb 15, 2009, at 4:46 PM, Martin Buchholz wrote:

> 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@...> 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
>>
>>

[Omair Majid]

Hi Jon,

Jonathan Gibbons wrote:
> Thanks for the update; I was expecting something around
> java.lang.Character myself,
> but definitely that sort of problem. Do you want to file a bug against
> the XML encoder?

I have filed a bug and proposed a patch at
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=295. This fixes the
test/java/beans/PropertyEditor/TestStringClassJava.java issue, but I
haven't tested it thoroughly.

Cheers,
Omair