You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Gregory Shimansky <gs...@gmail.com> on 2006/11/15 02:01:27 UTC
[drlvm] New regression: java.lang.ClassGenericsTest4
Hello
Today a kernel tests which used to pass a day ago started to fail. It is
java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM
and classlib (since some important classes like URLClassLoader, Hashtable and
TreeMap were changed recently) patches but no reversion helped. It may be a
cumulative effect of the patches now makes the test fail.
It fails somewhere deep inside of signature parser. The problem is also that
class format parses uses antlr which makes the whole parsing quite complex.
The failure happens on a BadSignatureTemplate class which is constructed from
bytes, parsed and its method is invoked. Apparently it has a wrong signature
(surprise :) ).
The whole purpose of the test is not clear to me more surprising is that it
works on RI (not on BEA). If someone could point to what may be wrong now
with this test I would be very grateful.
I also wonder why there is no InvocationTargetException which should be
chained with the down the stack Exception. The test_3 method uses reflection
to invoke a method BadSignatureTemplate.test_1 which in its turn threw an
Exception in parser. Shouldn't there be an InvocationTargetException as the
result of Method.invoke?
Where can I look at BadSignatureTemplate.java, specifically line 13 which
according to the stack called Class.getTypeParameters?
[1]
[gregory@localhost:
10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
junit.textui.TestRunner java.lang.ClassGenericsTest4
..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
java.lang.Exception
at
org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
at
org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
at java.lang.Class.getTypeParameters(Class.java:1020)
at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
(BadSignatureTemplate.java:13)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at java.lang.reflect.Method.invoke(Method.java:381)
at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at java.lang.reflect.Method.invoke(Method.java:381)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.textui.TestRunner.doRun(TestRunner.java:116)
at junit.textui.TestRunner.start(TestRunner.java:172)
at junit.textui.TestRunner.main(TestRunner.java:138)
===nextToken===: java.lang.Exception
antlr.TokenStreamException
at
org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
at antlr.TokenBuffer.fill(TokenBuffer.java:69)
at antlr.TokenBuffer.LA(TokenBuffer.java:80)
at antlr.LLkParser.LA(LLkParser.java:52)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
at
org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
at
org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
at java.lang.Class.getTypeParameters(Class.java:1020)
at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
(BadSignatureTemplate.java:13)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at java.lang.reflect.Method.invoke(Method.java:381)
at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
at java.lang.reflect.Method.invoke(Method.java:381)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.textui.TestRunner.doRun(TestRunner.java:116)
at junit.textui.TestRunner.start(TestRunner.java:172)
at junit.textui.TestRunner.main(TestRunner.java:138)
TokenStreamException: antlr.TokenStreamException
E
Time: 71.596
There was 1 error:
1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
--
Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][testing] Showing test failures
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> 2006/11/16, Tim Ellison <t....@gmail.com>:
>> One confusing aspect is that the classlib ant build fails if you run the
>> tests 'globally', but passes if you run the tests in a single module.
>
> Yes, this was a nasty surprise for me when I saw exactly this
> sutiation few days ago; I just had no time to speak up. We definitely
> should fix this.
I fixed it in r475714.
Now whether you are running a single module's tests or the 'global'
classlib test target there will be a build failure shown if any JUnit
tests failed.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][testing] Showing test failures (Re: [drlvm] New regression: java.lang.ClassGenericsTest4)
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/16, Tim Ellison <t....@gmail.com>:
> Rana Dasgupta wrote:
> > I think that a problem with the junit tests is that some failures spit out
> > to the console, but show up in the test run results as passed. I find this
> > very confusing. So unless you are watching all the time, you can miss them.
>
> Hmm, this doesn't sound right. I've not seen classlib tests fail but be
> reported in the html report as passed. Is that what you meant? (I
> realize your mail subject was [drlvm] but just checking.)
>
> One confusing aspect is that the classlib ant build fails if you run the
> tests 'globally', but passes if you run the tests in a single module.
Yes, this was a nasty surprise for me when I saw exactly this
sutiation few days ago; I just had no time to speak up. We definitely
should fix this.
>
> We could fix that by making the current test sequence an internal target
> (for the 'global' test), and checking for failures after a 'modular' test.
>
> e.g.
>
> Index: build.xml
> ===================================================================
> --- build.xml (revision 474801)
> +++ build.xml (working copy)
> @@ -41,8 +41,19 @@
>
> <target name="build" depends="compile-java, copy-resources,
> build-jar" />
>
> - <target name="test" depends="build, compile-tests, run-tests" />
> + <target name="test" depends="-test">
> + <fail message="Some tests failed">
> + <condition>
> + <or>
> + <isset property="test.failures" />
> + <isset property="test.errors" />
> + </or>
> + </condition>
> + </fail>
> + </target>
>
> + <target name="-test" depends="build, compile-tests, run-tests" />
> +
> <target name="clean">
> <delete file="${hy.jdk}/jre/lib/boot/beans.jar" />
> <delete file="${hy.jdk}/jre/lib/boot/beans-src.jar" />
>
>
> That would be more intuitive to me, so unless anyone objects I'll do it.
Absolutely reasonable solution, please do. Thank you so much!
--
Alexey
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
[classlib][testing] Showing test failures (Re: [drlvm] New regression:
java.lang.ClassGenericsTest4)
Posted by Tim Ellison <t....@gmail.com>.
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.
Hmm, this doesn't sound right. I've not seen classlib tests fail but be
reported in the html report as passed. Is that what you meant? (I
realize your mail subject was [drlvm] but just checking.)
One confusing aspect is that the classlib ant build fails if you run the
tests 'globally', but passes if you run the tests in a single module.
We could fix that by making the current test sequence an internal target
(for the 'global' test), and checking for failures after a 'modular' test.
e.g.
Index: build.xml
===================================================================
--- build.xml (revision 474801)
+++ build.xml (working copy)
@@ -41,8 +41,19 @@
<target name="build" depends="compile-java, copy-resources,
build-jar" />
- <target name="test" depends="build, compile-tests, run-tests" />
+ <target name="test" depends="-test">
+ <fail message="Some tests failed">
+ <condition>
+ <or>
+ <isset property="test.failures" />
+ <isset property="test.errors" />
+ </or>
+ </condition>
+ </fail>
+ </target>
+ <target name="-test" depends="build, compile-tests, run-tests" />
+
<target name="clean">
<delete file="${hy.jdk}/jre/lib/boot/beans.jar" />
<delete file="${hy.jdk}/jre/lib/boot/beans-src.jar" />
That would be more intuitive to me, so unless anyone objects I'll do it.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Rana Dasgupta <rd...@gmail.com>.
There is something that I am missing here. For example on my Linux build,
running kernel tests with .jet, I see some java.lang tests failures eg.,
SystemExtensionTest fails for me, and in the console summary report I get
"Kernel tests failed using Jitrino.Jet blah blah", but when I go browse
reports/jitrino.jet/html/index.html, there are no errors!
On 11/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Rana Dasgupta wrote:
> > I think that a problem with the junit tests is that some failures spit
> out
> > to the console, but show up in the test run results as passed. I find
> this
> > very confusing. So unless you are watching all the time, you can miss
> them.
>
> We can't depend on this - they have to mechanically resolve as passed or
> failed.
>
> Can you give me an example of a test?
>
>
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.
We can't depend on this - they have to mechanically resolve as passed or
failed.
Can you give me an example of a test?
>
> On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>>
>> Guys,
>>
>> This is a good discussion, and let me praise Alexey for the wonderful
>> fix.
>>
>> I'm a bit concerned about our accepptance checks. How this could be
>> that regression was missed by a committer and an engineer durring
>> acceptance test runs?
>>
>> Bug comments showed that Gregory ran the tests before a commit. Do
>> tests report such problems clearly?
>>
>> Thanks!
>>
>>
>>
>> On 11/15/06, Pavel Afremov <pa...@gmail.com> wrote:
>> > Oh. It's cool fix for my stupid bug.
>> >
>> >
>> >
>> > Thanks for Alexey very much.
>> >
>> > Pavel Afremov.
>> >
>> >
>> > On 11/15/06, Alexey Varlamov <al...@gmail.com> wrote:
>> > >
>> > > Pardon for my English - a bit sleepy already...
>> > >
>> > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> > > > Err, what I found is really trivial bug. But it took quite a few
>> time
>> > > > to discover - seems today was not my day :(
>> > > >
>> > > > Index: vm/vmcore/src/exception/exceptions_impl.cpp
>> > > > ===============================================================
>> > > > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
>> > > > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
>> > > > @@ -281,7 +281,7 @@
>> > > >
>> > > > if (NULL != exception->exc_cause) {
>> > > > tmn_suspend_disable_recursive();
>> > > > - jthrowable exc_cause = oh_allocate_local_handle();
>> > > > + exc_cause = oh_allocate_local_handle();
>> > > > exc_cause->object = exception->exc_cause;
>> > > > tmn_suspend_enable_recursive();
>> > > > }
>> > > >
>> > > >
>> > > > OK, we definitely need a regression test for this.
>> > > >
>> > > > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> > > > > Alexey Varlamov wrote:
>> > > > > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> > > > > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> > > > > >> > Alexey Varlamov wrote:
>> > > > > >> > > The guilty change is the following, which effectively
>> turns
>> on
>> > > > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> > > > > >> >
>> > > > > >> > Well this is a patch from HARMONY-2018 which doesn't hide
>> the
>> > > fact that
>> > > > > >> > it enables lazy exceptions. Why shouldn't we enable them?
>> > > > > >
>> > > > > > Gregory,
>> > > > > >
>> > > > > > I've just re-read my posts and couldn't find anything critique
>> or
>> > > > > > offending - please don't take regressions too personal. I'm
>> sure
>> we
>> > > > > > will be able to fix this one quite soon.
>> > > > >
>> > > > > I wasn't offended in any way. I was just thinking that you know
>> some
>> > > > > secret knowledge that lazy exceptions do not work and thus
>> enabling
>> > > them
>> > > > > is wrong.
>> > > > >
>> > > > > --
>> > > > > Gregory
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> >
>>
>>
>> --
>> Thank you,
>> Alexei
>>
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Rana Dasgupta <rd...@gmail.com>.
I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.
On 11/15/06, Alexei Fedotov <al...@gmail.com> wrote:
>
> Guys,
>
> This is a good discussion, and let me praise Alexey for the wonderful fix.
>
> I'm a bit concerned about our accepptance checks. How this could be
> that regression was missed by a committer and an engineer durring
> acceptance test runs?
>
> Bug comments showed that Gregory ran the tests before a commit. Do
> tests report such problems clearly?
>
> Thanks!
>
>
>
> On 11/15/06, Pavel Afremov <pa...@gmail.com> wrote:
> > Oh. It's cool fix for my stupid bug.
> >
> >
> >
> > Thanks for Alexey very much.
> >
> > Pavel Afremov.
> >
> >
> > On 11/15/06, Alexey Varlamov <al...@gmail.com> wrote:
> > >
> > > Pardon for my English - a bit sleepy already...
> > >
> > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > > > Err, what I found is really trivial bug. But it took quite a few
> time
> > > > to discover - seems today was not my day :(
> > > >
> > > > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > > > ===============================================================
> > > > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > > > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > > > @@ -281,7 +281,7 @@
> > > >
> > > > if (NULL != exception->exc_cause) {
> > > > tmn_suspend_disable_recursive();
> > > > - jthrowable exc_cause = oh_allocate_local_handle();
> > > > + exc_cause = oh_allocate_local_handle();
> > > > exc_cause->object = exception->exc_cause;
> > > > tmn_suspend_enable_recursive();
> > > > }
> > > >
> > > >
> > > > OK, we definitely need a regression test for this.
> > > >
> > > > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > > > Alexey Varlamov wrote:
> > > > > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > > > > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > > > >> > Alexey Varlamov wrote:
> > > > > >> > > The guilty change is the following, which effectively turns
> on
> > > > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > > > >> >
> > > > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> > > fact that
> > > > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > > > >
> > > > > > Gregory,
> > > > > >
> > > > > > I've just re-read my posts and couldn't find anything critique
> or
> > > > > > offending - please don't take regressions too personal. I'm sure
> we
> > > > > > will be able to fix this one quite soon.
> > > > >
> > > > > I wasn't offended in any way. I was just thinking that you know
> some
> > > > > secret knowledge that lazy exceptions do not work and thus
> enabling
> > > them
> > > > > is wrong.
> > > > >
> > > > > --
> > > > > Gregory
> > > > >
> > > > >
> > > >
> > >
> >
> >
>
>
> --
> Thank you,
> Alexei
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
Well, we all learned the lesson. Here are my own thoughts, and some
more answers are inlined:
1) Explicit separate testing for all execution engines (JET, OPT,
interpreter) is really valuable; so far we found bugs in many
components including classlib (!), especially due to interpreter. I
bet JIT guys will soon beseech for the same in classlib testing, at
least by CI :)
2) Time required to run all pre-commit tests for DRLVM is near to
inadmissible. I believe this is the main reason why patch submitters
may not exercise them truly. Another reason is poor diagnostic&debug
services of available build infrastructure.
We really need to think how we can improve it - e.g. using "sameVM"
mode as much as possible, provide more reliable and convenient results
reporting, more unified harness, etc.
3) It would be nice to invest some efforts to cleaning & sorting out
available tests, smoke and kernel first of all. I suspect there might
be some duplication in coverage, and it certainly does present between
DRLVM-kernel and classlib-luni suites. Ideally we would merge them
into common VM-kernel.
2006/11/16, Gregory Shimansky <gs...@gmail.com>:
> Alexei Fedotov wrote:
> > Guys,
> >
> > This is a good discussion, and let me praise Alexey for the wonderful fix.
> >
> > I'm a bit concerned about our accepptance checks. How this could be
> > that regression was missed by a committer and an engineer durring
> > acceptance test runs?
> >
> > Bug comments showed that Gregory ran the tests before a commit. Do
> > tests report such problems clearly?
>
> I saw that they failed on interpreter and saw an additional failure by
> ClassGeneticsTest4, but when I reverted the patch I ran the test
> individually (because running kernel tests is quite a long task). I saw
> exceptions output from ClassGeneticsTest4 with reverted patch and
> decided that it wasn't the one to blame. I tried reverting other patches
> but all of them produced the same output. Today Alexey explained to me
> that exceptions output was just a verbose test output not to related to
> test passed/failed status. So the answer to your question is "not very
> clearly" :)
Well, junit always output total status after run, just some practice
is needed to distinguish between noise and vital output :) But me too
dislikes stacktraces in output very much.
>
> After I saw that reverting the patches doesn't help very much I decided
> that regression somehow slipped earlier but wasn't noticed. The problem
> with kernel tests is that they don't pass stably. Often j.l.ThreadTest
> fails and j.l.RuntimeTest2 fails on XP. So I thought that negative
> result of kernel tests run was assumed to be ok because
> ClassGeneticsTest4 failure was not noticed since some tests which fail
> often failed.
Unfortunately yes, drlvm tests and kernel in particular gained some
mournful reputation. But in fact, they (mostly) failed justly. Now
DRLVM becomes more mature and we should adopt "zero regression" policy
soon.
>
> The output of kernel tests is not very good too. They run 3 times on
> JET, OPT and interpreter. The last output is for interpreter, and if the
> output prints PASSED it is necessary to check result for JET and OPT. I
> think the tests should either <fail/> after the first test run which
> didn't pass (similar to how smoke tests stop tests execution), or print
> a summary at the end for all 3 runs with <fail/> if case any of them
> didn't pass.
1) Fail-fast behaviour is not very informative, especially if
instability faced. It might be useful to enforce "zero regression"
rule, but I vote for "run them all" mode. BTW, this is how classlib
tests behave and this is just convenient. Yet we may want to add a
cmd-line switch ala "haltonfailure" in junit task.
2) I agree about more informative summary, will take care.
[snip]
--
Alexey
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexei Fedotov wrote:
> Guys,
>
> This is a good discussion, and let me praise Alexey for the wonderful fix.
>
> I'm a bit concerned about our accepptance checks. How this could be
> that regression was missed by a committer and an engineer durring
> acceptance test runs?
>
> Bug comments showed that Gregory ran the tests before a commit. Do
> tests report such problems clearly?
I saw that they failed on interpreter and saw an additional failure by
ClassGeneticsTest4, but when I reverted the patch I ran the test
individually (because running kernel tests is quite a long task). I saw
exceptions output from ClassGeneticsTest4 with reverted patch and
decided that it wasn't the one to blame. I tried reverting other patches
but all of them produced the same output. Today Alexey explained to me
that exceptions output was just a verbose test output not to related to
test passed/failed status. So the answer to your question is "not very
clearly" :)
After I saw that reverting the patches doesn't help very much I decided
that regression somehow slipped earlier but wasn't noticed. The problem
with kernel tests is that they don't pass stably. Often j.l.ThreadTest
fails and j.l.RuntimeTest2 fails on XP. So I thought that negative
result of kernel tests run was assumed to be ok because
ClassGeneticsTest4 failure was not noticed since some tests which fail
often failed.
The output of kernel tests is not very good too. They run 3 times on
JET, OPT and interpreter. The last output is for interpreter, and if the
output prints PASSED it is necessary to check result for JET and OPT. I
think the tests should either <fail/> after the first test run which
didn't pass (similar to how smoke tests stop tests execution), or print
a summary at the end for all 3 runs with <fail/> if case any of them
didn't pass.
> On 11/15/06, Pavel Afremov <pa...@gmail.com> wrote:
>> Oh. It's cool fix for my stupid bug.
>>
>>
>>
>> Thanks for Alexey very much.
>>
>> Pavel Afremov.
>>
>>
>> On 11/15/06, Alexey Varlamov <al...@gmail.com> wrote:
>> >
>> > Pardon for my English - a bit sleepy already...
>> >
>> > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> > > Err, what I found is really trivial bug. But it took quite a few time
>> > > to discover - seems today was not my day :(
>> > >
>> > > Index: vm/vmcore/src/exception/exceptions_impl.cpp
>> > > ===============================================================
>> > > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
>> > > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
>> > > @@ -281,7 +281,7 @@
>> > >
>> > > if (NULL != exception->exc_cause) {
>> > > tmn_suspend_disable_recursive();
>> > > - jthrowable exc_cause = oh_allocate_local_handle();
>> > > + exc_cause = oh_allocate_local_handle();
>> > > exc_cause->object = exception->exc_cause;
>> > > tmn_suspend_enable_recursive();
>> > > }
>> > >
>> > >
>> > > OK, we definitely need a regression test for this.
>> > >
>> > > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> > > > Alexey Varlamov wrote:
>> > > > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> > > > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> > > > >> > Alexey Varlamov wrote:
>> > > > >> > > The guilty change is the following, which effectively
>> turns on
>> > > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> > > > >> >
>> > > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
>> > fact that
>> > > > >> > it enables lazy exceptions. Why shouldn't we enable them?
>> > > > >
>> > > > > Gregory,
>> > > > >
>> > > > > I've just re-read my posts and couldn't find anything critique or
>> > > > > offending - please don't take regressions too personal. I'm
>> sure we
>> > > > > will be able to fix this one quite soon.
>> > > >
>> > > > I wasn't offended in any way. I was just thinking that you know
>> some
>> > > > secret knowledge that lazy exceptions do not work and thus enabling
>> > them
>> > > > is wrong.
>> > > >
>> > > > --
>> > > > Gregory
>> > > >
>> > > >
>> > >
>> >
>>
>>
>
>
--
Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexei Fedotov <al...@gmail.com>.
Guys,
This is a good discussion, and let me praise Alexey for the wonderful fix.
I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?
Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?
Thanks!
On 11/15/06, Pavel Afremov <pa...@gmail.com> wrote:
> Oh. It's cool fix for my stupid bug.
>
>
>
> Thanks for Alexey very much.
>
> Pavel Afremov.
>
>
> On 11/15/06, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > Pardon for my English - a bit sleepy already...
> >
> > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > > Err, what I found is really trivial bug. But it took quite a few time
> > > to discover - seems today was not my day :(
> > >
> > > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > > ===============================================================
> > > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > > @@ -281,7 +281,7 @@
> > >
> > > if (NULL != exception->exc_cause) {
> > > tmn_suspend_disable_recursive();
> > > - jthrowable exc_cause = oh_allocate_local_handle();
> > > + exc_cause = oh_allocate_local_handle();
> > > exc_cause->object = exception->exc_cause;
> > > tmn_suspend_enable_recursive();
> > > }
> > >
> > >
> > > OK, we definitely need a regression test for this.
> > >
> > > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > > Alexey Varlamov wrote:
> > > > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > > > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > > >> > Alexey Varlamov wrote:
> > > > >> > > The guilty change is the following, which effectively turns on
> > > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > > >> >
> > > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> > fact that
> > > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > > >
> > > > > Gregory,
> > > > >
> > > > > I've just re-read my posts and couldn't find anything critique or
> > > > > offending - please don't take regressions too personal. I'm sure we
> > > > > will be able to fix this one quite soon.
> > > >
> > > > I wasn't offended in any way. I was just thinking that you know some
> > > > secret knowledge that lazy exceptions do not work and thus enabling
> > them
> > > > is wrong.
> > > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> >
>
>
--
Thank you,
Alexei
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Pavel Afremov <pa...@gmail.com>.
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov <al...@gmail.com> wrote:
>
> Pardon for my English - a bit sleepy already...
>
> 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > Err, what I found is really trivial bug. But it took quite a few time
> > to discover - seems today was not my day :(
> >
> > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > ===============================================================
> > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > @@ -281,7 +281,7 @@
> >
> > if (NULL != exception->exc_cause) {
> > tmn_suspend_disable_recursive();
> > - jthrowable exc_cause = oh_allocate_local_handle();
> > + exc_cause = oh_allocate_local_handle();
> > exc_cause->object = exception->exc_cause;
> > tmn_suspend_enable_recursive();
> > }
> >
> >
> > OK, we definitely need a regression test for this.
> >
> > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > >> > Alexey Varlamov wrote:
> > > >> > > The guilty change is the following, which effectively turns on
> > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > >> >
> > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> fact that
> > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > >
> > > > Gregory,
> > > >
> > > > I've just re-read my posts and couldn't find anything critique or
> > > > offending - please don't take regressions too personal. I'm sure we
> > > > will be able to fix this one quite soon.
> > >
> > > I wasn't offended in any way. I was just thinking that you know some
> > > secret knowledge that lazy exceptions do not work and thus enabling
> them
> > > is wrong.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
Pardon for my English - a bit sleepy already...
2006/11/15, Alexey Varlamov <al...@gmail.com>:
> Err, what I found is really trivial bug. But it took quite a few time
> to discover - seems today was not my day :(
>
> Index: vm/vmcore/src/exception/exceptions_impl.cpp
> ===============================================================
> --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> @@ -281,7 +281,7 @@
>
> if (NULL != exception->exc_cause) {
> tmn_suspend_disable_recursive();
> - jthrowable exc_cause = oh_allocate_local_handle();
> + exc_cause = oh_allocate_local_handle();
> exc_cause->object = exception->exc_cause;
> tmn_suspend_enable_recursive();
> }
>
>
> OK, we definitely need a regression test for this.
>
> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > Alexey Varlamov wrote:
> > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > >> > Alexey Varlamov wrote:
> > >> > > The guilty change is the following, which effectively turns on
> > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > >> >
> > >> > Well this is a patch from HARMONY-2018 which doesn't hide the fact that
> > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > >
> > > Gregory,
> > >
> > > I've just re-read my posts and couldn't find anything critique or
> > > offending - please don't take regressions too personal. I'm sure we
> > > will be able to fix this one quite soon.
> >
> > I wasn't offended in any way. I was just thinking that you know some
> > secret knowledge that lazy exceptions do not work and thus enabling them
> > is wrong.
> >
> > --
> > Gregory
> >
> >
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/16, Gregory Shimansky <gs...@gmail.com>:
> Alexey Varlamov wrote:
> > Err, what I found is really trivial bug. But it took quite a few time
> > to discover - seems today was not my day :(
> >
> > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > ===============================================================
> > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > @@ -281,7 +281,7 @@
> >
> > if (NULL != exception->exc_cause) {
> > tmn_suspend_disable_recursive();
> > - jthrowable exc_cause = oh_allocate_local_handle();
> > + exc_cause = oh_allocate_local_handle();
> > exc_cause->object = exception->exc_cause;
> > tmn_suspend_enable_recursive();
> > }
>
> Cool. Could you please commit the fix?
Committed along with regression testcase at r475590.
>
> > OK, we definitely need a regression test for this.
> >
> > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> >> Alexey Varlamov wrote:
> >> > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> >> >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> >> >> > Alexey Varlamov wrote:
> >> >> > > The guilty change is the following, which effectively turns on
> >> >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> >> >> >
> >> >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> >> fact that
> >> >> > it enables lazy exceptions. Why shouldn't we enable them?
> >> >
> >> > Gregory,
> >> >
> >> > I've just re-read my posts and couldn't find anything critique or
> >> > offending - please don't take regressions too personal. I'm sure we
> >> > will be able to fix this one quite soon.
> >>
> >> I wasn't offended in any way. I was just thinking that you know some
> >> secret knowledge that lazy exceptions do not work and thus enabling them
> >> is wrong.
> >>
> >> --
> >> Gregory
> >>
> >>
> >
>
>
> --
> Gregory
>
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Varlamov wrote:
> Err, what I found is really trivial bug. But it took quite a few time
> to discover - seems today was not my day :(
>
> Index: vm/vmcore/src/exception/exceptions_impl.cpp
> ===============================================================
> --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> @@ -281,7 +281,7 @@
>
> if (NULL != exception->exc_cause) {
> tmn_suspend_disable_recursive();
> - jthrowable exc_cause = oh_allocate_local_handle();
> + exc_cause = oh_allocate_local_handle();
> exc_cause->object = exception->exc_cause;
> tmn_suspend_enable_recursive();
> }
Cool. Could you please commit the fix?
> OK, we definitely need a regression test for this.
>
> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> Alexey Varlamov wrote:
>> > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> >> > Alexey Varlamov wrote:
>> >> > > The guilty change is the following, which effectively turns on
>> >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> >> >
>> >> > Well this is a patch from HARMONY-2018 which doesn't hide the
>> fact that
>> >> > it enables lazy exceptions. Why shouldn't we enable them?
>> >
>> > Gregory,
>> >
>> > I've just re-read my posts and couldn't find anything critique or
>> > offending - please don't take regressions too personal. I'm sure we
>> > will be able to fix this one quite soon.
>>
>> I wasn't offended in any way. I was just thinking that you know some
>> secret knowledge that lazy exceptions do not work and thus enabling them
>> is wrong.
>>
>> --
>> Gregory
>>
>>
>
--
Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(
Index: vm/vmcore/src/exception/exceptions_impl.cpp
===============================================================
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@
if (NULL != exception->exc_cause) {
tmn_suspend_disable_recursive();
- jthrowable exc_cause = oh_allocate_local_handle();
+ exc_cause = oh_allocate_local_handle();
exc_cause->object = exception->exc_cause;
tmn_suspend_enable_recursive();
}
OK, we definitely need a regression test for this.
2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> Alexey Varlamov wrote:
> > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> >> > Alexey Varlamov wrote:
> >> > > The guilty change is the following, which effectively turns on
> >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> >> >
> >> > Well this is a patch from HARMONY-2018 which doesn't hide the fact that
> >> > it enables lazy exceptions. Why shouldn't we enable them?
> >
> > Gregory,
> >
> > I've just re-read my posts and couldn't find anything critique or
> > offending - please don't take regressions too personal. I'm sure we
> > will be able to fix this one quite soon.
>
> I wasn't offended in any way. I was just thinking that you know some
> secret knowledge that lazy exceptions do not work and thus enabling them
> is wrong.
>
> --
> Gregory
>
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Varlamov wrote:
> 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> > Alexey Varlamov wrote:
>> > > The guilty change is the following, which effectively turns on
>> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> >
>> > Well this is a patch from HARMONY-2018 which doesn't hide the fact that
>> > it enables lazy exceptions. Why shouldn't we enable them?
>
> Gregory,
>
> I've just re-read my posts and couldn't find anything critique or
> offending - please don't take regressions too personal. I'm sure we
> will be able to fix this one quite soon.
I wasn't offended in any way. I was just thinking that you know some
secret knowledge that lazy exceptions do not work and thus enabling them
is wrong.
--
Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/15, Alexey Varlamov <al...@gmail.com>:
> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > Alexey Varlamov wrote:
> > > The guilty change is the following, which effectively turns on
> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> >
> > Well this is a patch from HARMONY-2018 which doesn't hide the fact that
> > it enables lazy exceptions. Why shouldn't we enable them?
Gregory,
I've just re-read my posts and couldn't find anything critique or
offending - please don't take regressions too personal. I'm sure we
will be able to fix this one quite soon.
--
Peace,
Alexey
>
> The point is not that we should or should not enable them, rather the
> fact that the regression appeared due to this change. I just tried to
> localize the problem hoping it will help to resolve this regression
> soon instead of reverting.
>
> >
> > Actually if you revert the patch (I've tried) this doesn't seem to fix
> > the test. At least the exceptions are still there, not sure about test
> > PASSED status.
>
> Verbose test output is confusing but itself does no harm. I found so
> far the following:
> 1) the test fails on this assertion (ClassGenericsTest4.java:799):
> if (!(e.getCause() instanceof java.lang.reflect.GenericSignatureFormatError)) {
> fail("test_3, case 003 FAILED: GenericSignatureFormatError should
> be risen.");
> }
> because of e.getCause() returns null. That is, lazy machinery drops
> the cause of InvocationTargetException, I did not yet figured out why.
> 2) Test report provides the following diagnostics:
> java.lang.NullPointerException at
> junit.framework.TestCase.runTest(TestCase.java:168). This seems to
> point to the same problem: lost cause exception after reflection.
>
> >
> > > Modified:
> > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> > >
> > > URL:
> > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diff&rev=475029&r1=475028&r2=475029
> > >
> > > ==============================================================================
> > >
> > > ---
> > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> > >
> > > (original)
> > > +++
> > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> > >
> > > Tue Nov 14 14:45:45 2006
> > > @@ -26,6 +26,7 @@
> > > #include "Class.h"
> > > #include "classloader.h"
> > > #include "exceptions.h"
> > > +#include "exceptions_impl.h"
> > > #include "exceptions_jit.h"
> > > #include "exceptions_type.h"
> > > #include "environment.h"
> > >
> > > So the problem most probably in exn_throw_by_class_internal()
> > > function, will look closer after lunch.
> > >
> > > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > >> Heh, this regression is more interesting than it looked at first glance:
> > >> JITs give the same output with identical stack trace, but test result
> > >> is PASSED.
> > >> By lucky chance I have older debug build at hand (svn = r474646) and
> > >> it also spills this stacktrace to system err but status is PASSED for
> > >> all execution engines.
> > >> Looks like smth hase changed in exceptions processing for interpreter.
> > >>
> > >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > >> > Hello
> > >> >
> > >> > Today a kernel tests which used to pass a day ago started to fail.
> > >> It is
> > >> > java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert
> > >> some VM
> > >> > and classlib (since some important classes like URLClassLoader,
> > >> Hashtable and
> > >> > TreeMap were changed recently) patches but no reversion helped. It
> > >> may be a
> > >> > cumulative effect of the patches now makes the test fail.
> > >> >
> > >> > It fails somewhere deep inside of signature parser. The problem is
> > >> also that
> > >> > class format parses uses antlr which makes the whole parsing quite
> > >> complex.
> > >> > The failure happens on a BadSignatureTemplate class which is
> > >> constructed from
> > >> > bytes, parsed and its method is invoked. Apparently it has a wrong
> > >> signature
> > >> > (surprise :) ).
> > >> >
> > >> > The whole purpose of the test is not clear to me more surprising is
> > >> that it
> > >> > works on RI (not on BEA). If someone could point to what may be
> > >> wrong now
> > >> > with this test I would be very grateful.
> > >> >
> > >> > I also wonder why there is no InvocationTargetException which should be
> > >> > chained with the down the stack Exception. The test_3 method uses
> > >> reflection
> > >> > to invoke a method BadSignatureTemplate.test_1 which in its turn
> > >> threw an
> > >> > Exception in parser. Shouldn't there be an InvocationTargetException
> > >> as the
> > >> > result of Method.invoke?
> > >> >
> > >> > Where can I look at BadSignatureTemplate.java, specifically line 13
> > >> which
> > >> > according to the stack called Class.getTypeParameters?
> > >> >
> > >> > [1]
> > >> >
> > >> > [gregory@localhost:
> > >> > 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint
> > >> -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar
> > >> -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
> > >> > junit.textui.TestRunner java.lang.ClassGenericsTest4
> > >> >
> > >> ..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
> > >>
> > >> > java.lang.Exception
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
> > >>
> > >> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> > >> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> > >> > at antlr.LLkParser.LA(LLkParser.java:52)
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> > >>
> > >> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> > >> > at java.lang.Class.getTypeParameters(Class.java:1020)
> > >> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> > >> > (BadSignatureTemplate.java:13)
> > >> > at
> > >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > >> > at java.lang.reflect.Method.invoke(Method.java:381)
> > >> > at
> > >> java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> > >> > at
> > >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > >> > at java.lang.reflect.Method.invoke(Method.java:381)
> > >> > at junit.framework.TestCase.runTest(TestCase.java:154)
> > >> > at junit.framework.TestCase.runBare(TestCase.java:127)
> > >> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > >> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > >> > at junit.framework.TestResult.run(TestResult.java:109)
> > >> > at junit.framework.TestCase.run(TestCase.java:118)
> > >> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > >> > at junit.framework.TestSuite.run(TestSuite.java:203)
> > >> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> > >> > at junit.textui.TestRunner.start(TestRunner.java:172)
> > >> > at junit.textui.TestRunner.main(TestRunner.java:138)
> > >> > ===nextToken===: java.lang.Exception
> > >> > antlr.TokenStreamException
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
> > >>
> > >> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> > >> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> > >> > at antlr.LLkParser.LA(LLkParser.java:52)
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> > >>
> > >> > at
> > >> >
> > >> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> > >>
> > >> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> > >> > at java.lang.Class.getTypeParameters(Class.java:1020)
> > >> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> > >> > (BadSignatureTemplate.java:13)
> > >> > at
> > >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > >> > at java.lang.reflect.Method.invoke(Method.java:381)
> > >> > at
> > >> java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> > >> > at
> > >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > >> > at java.lang.reflect.Method.invoke(Method.java:381)
> > >> > at junit.framework.TestCase.runTest(TestCase.java:154)
> > >> > at junit.framework.TestCase.runBare(TestCase.java:127)
> > >> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > >> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > >> > at junit.framework.TestResult.run(TestResult.java:109)
> > >> > at junit.framework.TestCase.run(TestCase.java:118)
> > >> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > >> > at junit.framework.TestSuite.run(TestSuite.java:203)
> > >> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> > >> > at junit.textui.TestRunner.start(TestRunner.java:172)
> > >> > at junit.textui.TestRunner.main(TestRunner.java:138)
> > >> > TokenStreamException: antlr.TokenStreamException
> > >> > E
> > >> > Time: 71.596
> > >> > There was 1 error:
> > >> > 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
> > >> >
> > >> >
> > >> > --
> > >> > Gregory Shimansky, Intel Middleware Products Division
> > >> >
> > >>
> > >
> >
> >
> > --
> > Gregory
> >
> >
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> Alexey Varlamov wrote:
> > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> >> Alexey Varlamov wrote:
> >> > The guilty change is the following, which effectively turns on
> >> > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> >>
> >> Well this is a patch from HARMONY-2018 which doesn't hide the fact that
> >> it enables lazy exceptions. Why shouldn't we enable them?
> >
> > The point is not that we should or should not enable them, rather the
> > fact that the regression appeared due to this change. I just tried to
> > localize the problem hoping it will help to resolve this regression
> > soon instead of reverting.
> >
> >>
> >> Actually if you revert the patch (I've tried) this doesn't seem to fix
> >> the test. At least the exceptions are still there, not sure about test
> >> PASSED status.
> >
> > Verbose test output is confusing but itself does no harm. I found so
>
> Ah this explains it. When I tried to investigate the regression I've
> reverted the patch and tried the test alone. I saw exceptions and
> thought that the test failed. I didn't realize that it is just an output.
>
> > far the following:
> > 1) the test fails on this assertion (ClassGenericsTest4.java:799):
> > if (!(e.getCause() instanceof
> > java.lang.reflect.GenericSignatureFormatError)) {
> > fail("test_3, case 003 FAILED: GenericSignatureFormatError should
> > be risen.");
> > }
> > because of e.getCause() returns null. That is, lazy machinery drops
> > the cause of InvocationTargetException, I did not yet figured out why.
>
> I see. If the problem appears to be hard to solve we should revert the
> HARMONY-2018 patch.
What really confuses me, why this failure is interpreter specific?
AFAIU functions for creating exceptions are common, so the root cause
may be in stale exceptions due to improper cleanup somewhere...
>
> > 2) Test report provides the following diagnostics:
> > java.lang.NullPointerException at
> > junit.framework.TestCase.runTest(TestCase.java:168). This seems to
> > point to the same problem: lost cause exception after reflection.
>
> --
> Gregory
>
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Varlamov wrote:
> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> Alexey Varlamov wrote:
>> > The guilty change is the following, which effectively turns on
>> > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>>
>> Well this is a patch from HARMONY-2018 which doesn't hide the fact that
>> it enables lazy exceptions. Why shouldn't we enable them?
>
> The point is not that we should or should not enable them, rather the
> fact that the regression appeared due to this change. I just tried to
> localize the problem hoping it will help to resolve this regression
> soon instead of reverting.
>
>>
>> Actually if you revert the patch (I've tried) this doesn't seem to fix
>> the test. At least the exceptions are still there, not sure about test
>> PASSED status.
>
> Verbose test output is confusing but itself does no harm. I found so
Ah this explains it. When I tried to investigate the regression I've
reverted the patch and tried the test alone. I saw exceptions and
thought that the test failed. I didn't realize that it is just an output.
> far the following:
> 1) the test fails on this assertion (ClassGenericsTest4.java:799):
> if (!(e.getCause() instanceof
> java.lang.reflect.GenericSignatureFormatError)) {
> fail("test_3, case 003 FAILED: GenericSignatureFormatError should
> be risen.");
> }
> because of e.getCause() returns null. That is, lazy machinery drops
> the cause of InvocationTargetException, I did not yet figured out why.
I see. If the problem appears to be hard to solve we should revert the
HARMONY-2018 patch.
> 2) Test report provides the following diagnostics:
> java.lang.NullPointerException at
> junit.framework.TestCase.runTest(TestCase.java:168). This seems to
> point to the same problem: lost cause exception after reflection.
--
Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> Alexey Varlamov wrote:
> > The guilty change is the following, which effectively turns on
> > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>
> Well this is a patch from HARMONY-2018 which doesn't hide the fact that
> it enables lazy exceptions. Why shouldn't we enable them?
The point is not that we should or should not enable them, rather the
fact that the regression appeared due to this change. I just tried to
localize the problem hoping it will help to resolve this regression
soon instead of reverting.
>
> Actually if you revert the patch (I've tried) this doesn't seem to fix
> the test. At least the exceptions are still there, not sure about test
> PASSED status.
Verbose test output is confusing but itself does no harm. I found so
far the following:
1) the test fails on this assertion (ClassGenericsTest4.java:799):
if (!(e.getCause() instanceof java.lang.reflect.GenericSignatureFormatError)) {
fail("test_3, case 003 FAILED: GenericSignatureFormatError should
be risen.");
}
because of e.getCause() returns null. That is, lazy machinery drops
the cause of InvocationTargetException, I did not yet figured out why.
2) Test report provides the following diagnostics:
java.lang.NullPointerException at
junit.framework.TestCase.runTest(TestCase.java:168). This seems to
point to the same problem: lost cause exception after reflection.
>
> > Modified:
> > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> >
> > URL:
> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diff&rev=475029&r1=475028&r2=475029
> >
> > ==============================================================================
> >
> > ---
> > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> >
> > (original)
> > +++
> > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> >
> > Tue Nov 14 14:45:45 2006
> > @@ -26,6 +26,7 @@
> > #include "Class.h"
> > #include "classloader.h"
> > #include "exceptions.h"
> > +#include "exceptions_impl.h"
> > #include "exceptions_jit.h"
> > #include "exceptions_type.h"
> > #include "environment.h"
> >
> > So the problem most probably in exn_throw_by_class_internal()
> > function, will look closer after lunch.
> >
> > 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> >> Heh, this regression is more interesting than it looked at first glance:
> >> JITs give the same output with identical stack trace, but test result
> >> is PASSED.
> >> By lucky chance I have older debug build at hand (svn = r474646) and
> >> it also spills this stacktrace to system err but status is PASSED for
> >> all execution engines.
> >> Looks like smth hase changed in exceptions processing for interpreter.
> >>
> >> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> >> > Hello
> >> >
> >> > Today a kernel tests which used to pass a day ago started to fail.
> >> It is
> >> > java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert
> >> some VM
> >> > and classlib (since some important classes like URLClassLoader,
> >> Hashtable and
> >> > TreeMap were changed recently) patches but no reversion helped. It
> >> may be a
> >> > cumulative effect of the patches now makes the test fail.
> >> >
> >> > It fails somewhere deep inside of signature parser. The problem is
> >> also that
> >> > class format parses uses antlr which makes the whole parsing quite
> >> complex.
> >> > The failure happens on a BadSignatureTemplate class which is
> >> constructed from
> >> > bytes, parsed and its method is invoked. Apparently it has a wrong
> >> signature
> >> > (surprise :) ).
> >> >
> >> > The whole purpose of the test is not clear to me more surprising is
> >> that it
> >> > works on RI (not on BEA). If someone could point to what may be
> >> wrong now
> >> > with this test I would be very grateful.
> >> >
> >> > I also wonder why there is no InvocationTargetException which should be
> >> > chained with the down the stack Exception. The test_3 method uses
> >> reflection
> >> > to invoke a method BadSignatureTemplate.test_1 which in its turn
> >> threw an
> >> > Exception in parser. Shouldn't there be an InvocationTargetException
> >> as the
> >> > result of Method.invoke?
> >> >
> >> > Where can I look at BadSignatureTemplate.java, specifically line 13
> >> which
> >> > according to the stack called Class.getTypeParameters?
> >> >
> >> > [1]
> >> >
> >> > [gregory@localhost:
> >> > 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint
> >> -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar
> >> -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
> >> > junit.textui.TestRunner java.lang.ClassGenericsTest4
> >> >
> >> ..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
> >>
> >> > java.lang.Exception
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
> >>
> >> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> >> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> >> > at antlr.LLkParser.LA(LLkParser.java:52)
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> >>
> >> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> >> > at java.lang.Class.getTypeParameters(Class.java:1020)
> >> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> >> > (BadSignatureTemplate.java:13)
> >> > at
> >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> >> > at java.lang.reflect.Method.invoke(Method.java:381)
> >> > at
> >> java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> >> > at
> >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> >> > at java.lang.reflect.Method.invoke(Method.java:381)
> >> > at junit.framework.TestCase.runTest(TestCase.java:154)
> >> > at junit.framework.TestCase.runBare(TestCase.java:127)
> >> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> >> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> >> > at junit.framework.TestResult.run(TestResult.java:109)
> >> > at junit.framework.TestCase.run(TestCase.java:118)
> >> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> >> > at junit.framework.TestSuite.run(TestSuite.java:203)
> >> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> >> > at junit.textui.TestRunner.start(TestRunner.java:172)
> >> > at junit.textui.TestRunner.main(TestRunner.java:138)
> >> > ===nextToken===: java.lang.Exception
> >> > antlr.TokenStreamException
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
> >>
> >> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> >> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> >> > at antlr.LLkParser.LA(LLkParser.java:52)
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> >>
> >> > at
> >> >
> >> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> >>
> >> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> >> > at java.lang.Class.getTypeParameters(Class.java:1020)
> >> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> >> > (BadSignatureTemplate.java:13)
> >> > at
> >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> >> > at java.lang.reflect.Method.invoke(Method.java:381)
> >> > at
> >> java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> >> > at
> >> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> >> > at java.lang.reflect.Method.invoke(Method.java:381)
> >> > at junit.framework.TestCase.runTest(TestCase.java:154)
> >> > at junit.framework.TestCase.runBare(TestCase.java:127)
> >> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> >> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> >> > at junit.framework.TestResult.run(TestResult.java:109)
> >> > at junit.framework.TestCase.run(TestCase.java:118)
> >> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> >> > at junit.framework.TestSuite.run(TestSuite.java:203)
> >> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> >> > at junit.textui.TestRunner.start(TestRunner.java:172)
> >> > at junit.textui.TestRunner.main(TestRunner.java:138)
> >> > TokenStreamException: antlr.TokenStreamException
> >> > E
> >> > Time: 71.596
> >> > There was 1 error:
> >> > 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
> >> >
> >> >
> >> > --
> >> > Gregory Shimansky, Intel Middleware Products Division
> >> >
> >>
> >
>
>
> --
> Gregory
>
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Varlamov wrote:
> The guilty change is the following, which effectively turns on
> VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
Well this is a patch from HARMONY-2018 which doesn't hide the fact that
it enables lazy exceptions. Why shouldn't we enable them?
Actually if you revert the patch (I've tried) this doesn't seem to fix
the test. At least the exceptions are still there, not sure about test
PASSED status.
> Modified:
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
>
> URL:
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diff&rev=475029&r1=475028&r2=475029
>
> ==============================================================================
>
> ---
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
>
> (original)
> +++
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
>
> Tue Nov 14 14:45:45 2006
> @@ -26,6 +26,7 @@
> #include "Class.h"
> #include "classloader.h"
> #include "exceptions.h"
> +#include "exceptions_impl.h"
> #include "exceptions_jit.h"
> #include "exceptions_type.h"
> #include "environment.h"
>
> So the problem most probably in exn_throw_by_class_internal()
> function, will look closer after lunch.
>
> 2006/11/15, Alexey Varlamov <al...@gmail.com>:
>> Heh, this regression is more interesting than it looked at first glance:
>> JITs give the same output with identical stack trace, but test result
>> is PASSED.
>> By lucky chance I have older debug build at hand (svn = r474646) and
>> it also spills this stacktrace to system err but status is PASSED for
>> all execution engines.
>> Looks like smth hase changed in exceptions processing for interpreter.
>>
>> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
>> > Hello
>> >
>> > Today a kernel tests which used to pass a day ago started to fail.
>> It is
>> > java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert
>> some VM
>> > and classlib (since some important classes like URLClassLoader,
>> Hashtable and
>> > TreeMap were changed recently) patches but no reversion helped. It
>> may be a
>> > cumulative effect of the patches now makes the test fail.
>> >
>> > It fails somewhere deep inside of signature parser. The problem is
>> also that
>> > class format parses uses antlr which makes the whole parsing quite
>> complex.
>> > The failure happens on a BadSignatureTemplate class which is
>> constructed from
>> > bytes, parsed and its method is invoked. Apparently it has a wrong
>> signature
>> > (surprise :) ).
>> >
>> > The whole purpose of the test is not clear to me more surprising is
>> that it
>> > works on RI (not on BEA). If someone could point to what may be
>> wrong now
>> > with this test I would be very grateful.
>> >
>> > I also wonder why there is no InvocationTargetException which should be
>> > chained with the down the stack Exception. The test_3 method uses
>> reflection
>> > to invoke a method BadSignatureTemplate.test_1 which in its turn
>> threw an
>> > Exception in parser. Shouldn't there be an InvocationTargetException
>> as the
>> > result of Method.invoke?
>> >
>> > Where can I look at BadSignatureTemplate.java, specifically line 13
>> which
>> > according to the stack called Class.getTypeParameters?
>> >
>> > [1]
>> >
>> > [gregory@localhost:
>> > 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint
>> -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar
>> -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
>> > junit.textui.TestRunner java.lang.ClassGenericsTest4
>> >
>> ..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
>>
>> > java.lang.Exception
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
>>
>> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
>> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
>> > at antlr.LLkParser.LA(LLkParser.java:52)
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
>>
>> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
>> > at java.lang.Class.getTypeParameters(Class.java:1020)
>> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
>> > (BadSignatureTemplate.java:13)
>> > at
>> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> > at java.lang.reflect.Method.invoke(Method.java:381)
>> > at
>> java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
>> > at
>> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> > at java.lang.reflect.Method.invoke(Method.java:381)
>> > at junit.framework.TestCase.runTest(TestCase.java:154)
>> > at junit.framework.TestCase.runBare(TestCase.java:127)
>> > at junit.framework.TestResult$1.protect(TestResult.java:106)
>> > at junit.framework.TestResult.runProtected(TestResult.java:124)
>> > at junit.framework.TestResult.run(TestResult.java:109)
>> > at junit.framework.TestCase.run(TestCase.java:118)
>> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
>> > at junit.framework.TestSuite.run(TestSuite.java:203)
>> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
>> > at junit.textui.TestRunner.start(TestRunner.java:172)
>> > at junit.textui.TestRunner.main(TestRunner.java:138)
>> > ===nextToken===: java.lang.Exception
>> > antlr.TokenStreamException
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
>>
>> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
>> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
>> > at antlr.LLkParser.LA(LLkParser.java:52)
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
>>
>> > at
>> >
>> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
>>
>> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
>> > at java.lang.Class.getTypeParameters(Class.java:1020)
>> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
>> > (BadSignatureTemplate.java:13)
>> > at
>> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> > at java.lang.reflect.Method.invoke(Method.java:381)
>> > at
>> java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
>> > at
>> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> > at java.lang.reflect.Method.invoke(Method.java:381)
>> > at junit.framework.TestCase.runTest(TestCase.java:154)
>> > at junit.framework.TestCase.runBare(TestCase.java:127)
>> > at junit.framework.TestResult$1.protect(TestResult.java:106)
>> > at junit.framework.TestResult.runProtected(TestResult.java:124)
>> > at junit.framework.TestResult.run(TestResult.java:109)
>> > at junit.framework.TestCase.run(TestCase.java:118)
>> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
>> > at junit.framework.TestSuite.run(TestSuite.java:203)
>> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
>> > at junit.textui.TestRunner.start(TestRunner.java:172)
>> > at junit.textui.TestRunner.main(TestRunner.java:138)
>> > TokenStreamException: antlr.TokenStreamException
>> > E
>> > Time: 71.596
>> > There was 1 error:
>> > 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
>> >
>> >
>> > --
>> > Gregory Shimansky, Intel Middleware Products Division
>> >
>>
>
--
Gregory
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexei Fedotov <al...@gmail.com>.
All,
I wonder if we should apply "zero regression" policy to this change.
Speaking simply, should this patch be reverted and kept for additional
investigation?
On 11/15/06, Alexey Varlamov <al...@gmail.com> wrote:
> The guilty change is the following, which effectively turns on
> VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>
> Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diff&rev=475029&r1=475028&r2=475029
> ==============================================================================
> --- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> (original)
> +++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
> Tue Nov 14 14:45:45 2006
> @@ -26,6 +26,7 @@
> #include "Class.h"
> #include "classloader.h"
> #include "exceptions.h"
> +#include "exceptions_impl.h"
> #include "exceptions_jit.h"
> #include "exceptions_type.h"
> #include "environment.h"
>
> So the problem most probably in exn_throw_by_class_internal()
> function, will look closer after lunch.
>
> 2006/11/15, Alexey Varlamov <al...@gmail.com>:
> > Heh, this regression is more interesting than it looked at first glance:
> > JITs give the same output with identical stack trace, but test result is PASSED.
> > By lucky chance I have older debug build at hand (svn = r474646) and
> > it also spills this stacktrace to system err but status is PASSED for
> > all execution engines.
> > Looks like smth hase changed in exceptions processing for interpreter.
> >
> > 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > > Hello
> > >
> > > Today a kernel tests which used to pass a day ago started to fail. It is
> > > java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM
> > > and classlib (since some important classes like URLClassLoader, Hashtable and
> > > TreeMap were changed recently) patches but no reversion helped. It may be a
> > > cumulative effect of the patches now makes the test fail.
> > >
> > > It fails somewhere deep inside of signature parser. The problem is also that
> > > class format parses uses antlr which makes the whole parsing quite complex.
> > > The failure happens on a BadSignatureTemplate class which is constructed from
> > > bytes, parsed and its method is invoked. Apparently it has a wrong signature
> > > (surprise :) ).
> > >
> > > The whole purpose of the test is not clear to me more surprising is that it
> > > works on RI (not on BEA). If someone could point to what may be wrong now
> > > with this test I would be very grateful.
> > >
> > > I also wonder why there is no InvocationTargetException which should be
> > > chained with the down the stack Exception. The test_3 method uses reflection
> > > to invoke a method BadSignatureTemplate.test_1 which in its turn threw an
> > > Exception in parser. Shouldn't there be an InvocationTargetException as the
> > > result of Method.invoke?
> > >
> > > Where can I look at BadSignatureTemplate.java, specifically line 13 which
> > > according to the stack called Class.getTypeParameters?
> > >
> > > [1]
> > >
> > > [gregory@localhost:
> > > 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
> > > junit.textui.TestRunner java.lang.ClassGenericsTest4
> > > ..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
> > > java.lang.Exception
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
> > > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> > > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> > > at antlr.LLkParser.LA(LLkParser.java:52)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> > > at
> > > org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> > > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> > > at java.lang.Class.getTypeParameters(Class.java:1020)
> > > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> > > (BadSignatureTemplate.java:13)
> > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > at java.lang.reflect.Method.invoke(Method.java:381)
> > > at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > at java.lang.reflect.Method.invoke(Method.java:381)
> > > at junit.framework.TestCase.runTest(TestCase.java:154)
> > > at junit.framework.TestCase.runBare(TestCase.java:127)
> > > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > > at junit.framework.TestResult.run(TestResult.java:109)
> > > at junit.framework.TestCase.run(TestCase.java:118)
> > > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > > at junit.framework.TestSuite.run(TestSuite.java:203)
> > > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> > > at junit.textui.TestRunner.start(TestRunner.java:172)
> > > at junit.textui.TestRunner.main(TestRunner.java:138)
> > > ===nextToken===: java.lang.Exception
> > > antlr.TokenStreamException
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
> > > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> > > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> > > at antlr.LLkParser.LA(LLkParser.java:52)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> > > at
> > > org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> > > at
> > > org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> > > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> > > at java.lang.Class.getTypeParameters(Class.java:1020)
> > > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> > > (BadSignatureTemplate.java:13)
> > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > at java.lang.reflect.Method.invoke(Method.java:381)
> > > at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > at java.lang.reflect.Method.invoke(Method.java:381)
> > > at junit.framework.TestCase.runTest(TestCase.java:154)
> > > at junit.framework.TestCase.runBare(TestCase.java:127)
> > > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > > at junit.framework.TestResult.run(TestResult.java:109)
> > > at junit.framework.TestCase.run(TestCase.java:118)
> > > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > > at junit.framework.TestSuite.run(TestSuite.java:203)
> > > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> > > at junit.textui.TestRunner.start(TestRunner.java:172)
> > > at junit.textui.TestRunner.main(TestRunner.java:138)
> > > TokenStreamException: antlr.TokenStreamException
> > > E
> > > Time: 71.596
> > > There was 1 error:
> > > 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
> > >
> > >
> > > --
> > > Gregory Shimansky, Intel Middleware Products Division
> > >
> >
>
--
Thank you,
Alexei
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
The guilty change is the following, which effectively turns on
VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
Modified: incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp?view=diff&rev=475029&r1=475028&r2=475029
==============================================================================
--- incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
(original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/exception/exceptions_impl.cpp
Tue Nov 14 14:45:45 2006
@@ -26,6 +26,7 @@
#include "Class.h"
#include "classloader.h"
#include "exceptions.h"
+#include "exceptions_impl.h"
#include "exceptions_jit.h"
#include "exceptions_type.h"
#include "environment.h"
So the problem most probably in exn_throw_by_class_internal()
function, will look closer after lunch.
2006/11/15, Alexey Varlamov <al...@gmail.com>:
> Heh, this regression is more interesting than it looked at first glance:
> JITs give the same output with identical stack trace, but test result is PASSED.
> By lucky chance I have older debug build at hand (svn = r474646) and
> it also spills this stacktrace to system err but status is PASSED for
> all execution engines.
> Looks like smth hase changed in exceptions processing for interpreter.
>
> 2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> > Hello
> >
> > Today a kernel tests which used to pass a day ago started to fail. It is
> > java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM
> > and classlib (since some important classes like URLClassLoader, Hashtable and
> > TreeMap were changed recently) patches but no reversion helped. It may be a
> > cumulative effect of the patches now makes the test fail.
> >
> > It fails somewhere deep inside of signature parser. The problem is also that
> > class format parses uses antlr which makes the whole parsing quite complex.
> > The failure happens on a BadSignatureTemplate class which is constructed from
> > bytes, parsed and its method is invoked. Apparently it has a wrong signature
> > (surprise :) ).
> >
> > The whole purpose of the test is not clear to me more surprising is that it
> > works on RI (not on BEA). If someone could point to what may be wrong now
> > with this test I would be very grateful.
> >
> > I also wonder why there is no InvocationTargetException which should be
> > chained with the down the stack Exception. The test_3 method uses reflection
> > to invoke a method BadSignatureTemplate.test_1 which in its turn threw an
> > Exception in parser. Shouldn't there be an InvocationTargetException as the
> > result of Method.invoke?
> >
> > Where can I look at BadSignatureTemplate.java, specifically line 13 which
> > according to the stack called Class.getTypeParameters?
> >
> > [1]
> >
> > [gregory@localhost:
> > 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
> > junit.textui.TestRunner java.lang.ClassGenericsTest4
> > ..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
> > java.lang.Exception
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> > at antlr.LLkParser.LA(LLkParser.java:52)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> > at
> > org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> > at java.lang.Class.getTypeParameters(Class.java:1020)
> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> > (BadSignatureTemplate.java:13)
> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > at java.lang.reflect.Method.invoke(Method.java:381)
> > at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > at java.lang.reflect.Method.invoke(Method.java:381)
> > at junit.framework.TestCase.runTest(TestCase.java:154)
> > at junit.framework.TestCase.runBare(TestCase.java:127)
> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > at junit.framework.TestResult.run(TestResult.java:109)
> > at junit.framework.TestCase.run(TestCase.java:118)
> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > at junit.framework.TestSuite.run(TestSuite.java:203)
> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> > at junit.textui.TestRunner.start(TestRunner.java:172)
> > at junit.textui.TestRunner.main(TestRunner.java:138)
> > ===nextToken===: java.lang.Exception
> > antlr.TokenStreamException
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
> > at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> > at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> > at antlr.LLkParser.LA(LLkParser.java:52)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> > at
> > org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> > at
> > org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> > at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> > at java.lang.Class.getTypeParameters(Class.java:1020)
> > at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> > (BadSignatureTemplate.java:13)
> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > at java.lang.reflect.Method.invoke(Method.java:381)
> > at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > at java.lang.reflect.Method.invoke(Method.java:381)
> > at junit.framework.TestCase.runTest(TestCase.java:154)
> > at junit.framework.TestCase.runBare(TestCase.java:127)
> > at junit.framework.TestResult$1.protect(TestResult.java:106)
> > at junit.framework.TestResult.runProtected(TestResult.java:124)
> > at junit.framework.TestResult.run(TestResult.java:109)
> > at junit.framework.TestCase.run(TestCase.java:118)
> > at junit.framework.TestSuite.runTest(TestSuite.java:208)
> > at junit.framework.TestSuite.run(TestSuite.java:203)
> > at junit.textui.TestRunner.doRun(TestRunner.java:116)
> > at junit.textui.TestRunner.start(TestRunner.java:172)
> > at junit.textui.TestRunner.main(TestRunner.java:138)
> > TokenStreamException: antlr.TokenStreamException
> > E
> > Time: 71.596
> > There was 1 error:
> > 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
> >
> >
> > --
> > Gregory Shimansky, Intel Middleware Products Division
> >
>
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Posted by Alexey Varlamov <al...@gmail.com>.
Heh, this regression is more interesting than it looked at first glance:
JITs give the same output with identical stack trace, but test result is PASSED.
By lucky chance I have older debug build at hand (svn = r474646) and
it also spills this stacktrace to system err but status is PASSED for
all execution engines.
Looks like smth hase changed in exceptions processing for interpreter.
2006/11/15, Gregory Shimansky <gs...@gmail.com>:
> Hello
>
> Today a kernel tests which used to pass a day ago started to fail. It is
> java.lang.ClassGenericsTest4 (subtest test_3) [1]. I tried to revert some VM
> and classlib (since some important classes like URLClassLoader, Hashtable and
> TreeMap were changed recently) patches but no reversion helped. It may be a
> cumulative effect of the patches now makes the test fail.
>
> It fails somewhere deep inside of signature parser. The problem is also that
> class format parses uses antlr which makes the whole parsing quite complex.
> The failure happens on a BadSignatureTemplate class which is constructed from
> bytes, parsed and its method is invoked. Apparently it has a wrong signature
> (surprise :) ).
>
> The whole purpose of the test is not clear to me more surprising is that it
> works on RI (not on BEA). If someone could point to what may be wrong now
> with this test I would be very grateful.
>
> I also wonder why there is no InvocationTargetException which should be
> chained with the down the stack Exception. The test_3 method uses reflection
> to invoke a method BadSignatureTemplate.test_1 which in its turn threw an
> Exception in parser. Shouldn't there be an InvocationTargetException as the
> result of Method.invoke?
>
> Where can I look at BadSignatureTemplate.java, specifically line 13 which
> according to the stack called Class.getTypeParameters?
>
> [1]
>
> [gregory@localhost:
> 10113$] ./lnx_ia32_gcc_debug/deploy/jre/bin/java -Xint -Xbootclasspath/a:./lnx_ia32_gcc_debug/semis/kernel.tests/classes:./make/tmp/junit.jar -Dtest.resource.path=./lnx_ia32_gcc_debug/semis/kernel.tests/resources
> junit.textui.TestRunner java.lang.ClassGenericsTest4
> ..../lnx_ia32_gcc_debug/semis/kernel.tests/resources/org/apache/harmony/lang/generics/BadSignatureTemplate.class
> java.lang.Exception
> at
> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:420)
> at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> at antlr.LLkParser.LA(LLkParser.java:52)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> at
> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> at java.lang.Class.getTypeParameters(Class.java:1020)
> at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> (BadSignatureTemplate.java:13)
> at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> at java.lang.reflect.Method.invoke(Method.java:381)
> at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> at java.lang.reflect.Method.invoke(Method.java:381)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at junit.textui.TestRunner.doRun(TestRunner.java:116)
> at junit.textui.TestRunner.start(TestRunner.java:172)
> at junit.textui.TestRunner.main(TestRunner.java:138)
> ===nextToken===: java.lang.Exception
> antlr.TokenStreamException
> at
> org.apache.harmony.lang.reflect.parser.SignatureLexer2.nextToken(SignatureLexer2.java:434)
> at antlr.TokenBuffer.fill(TokenBuffer.java:69)
> at antlr.TokenBuffer.LA(TokenBuffer.java:80)
> at antlr.LLkParser.LA(LLkParser.java:52)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__SIMPLE_CLASS_TYPE_SIGNATURE(SignatureParser.java:1457)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE_SUFFIXES(SignatureParser.java:1736)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__REFERENCE(SignatureParser.java:1408)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_TYPE_SIGNATURE(SignatureParser.java:980)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FIELD_TYPE_SIGNATURE(SignatureParser.java:844)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__BOUND(SignatureParser.java:1311)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_OR_INTERFACE_BOUNDS(SignatureParser.java:1278)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETER(SignatureParser.java:1183)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS(SignatureParser.java:1152)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__FORMAL_TYPE_PARAMETERS_DECL(SignatureParser.java:951)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__CLASS_DECL(SignatureParser.java:535)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.pr__DECL(SignatureParser.java:480)
> at
> org.apache.harmony.lang.reflect.parser.SignatureParser.parseSignature(SignatureParser.java:378)
> at
> org.apache.harmony.lang.reflect.parser.Parser.parseSignature(Parser.java:38)
> at java.lang.Class$GACache.getTypeParameters(Class.java:1551)
> at java.lang.Class.getTypeParameters(Class.java:1020)
> at org.apache.harmony.lang.generics.BadSignatureTemplate.test_1
> (BadSignatureTemplate.java:13)
> at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> at java.lang.reflect.Method.invoke(Method.java:381)
> at java.lang.ClassGenericsTest4.test_3(ClassGenericsTest4.java:793)
> at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> at java.lang.reflect.Method.invoke(Method.java:381)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at junit.textui.TestRunner.doRun(TestRunner.java:116)
> at junit.textui.TestRunner.start(TestRunner.java:172)
> at junit.textui.TestRunner.main(TestRunner.java:138)
> TokenStreamException: antlr.TokenStreamException
> E
> Time: 71.596
> There was 1 error:
> 1) test_3(java.lang.ClassGenericsTest4)java.lang.NullPointerException
>
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>