Re: [drlvm] New regression: java.lang.ClassGenericsTest4
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 [EMAIL PROTECTED] 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=diffrev=475029r1=475028r2=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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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] [EMAIL PROTECTED]: 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
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
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=diffrev=475029r1=475028r2=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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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] [EMAIL PROTECTED]: 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
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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=diffrev=475029r1=475028r2=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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
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]
[EMAIL PROTECTED]:
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)
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexey Varlamov wrote:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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=diffrev=475029r1=475028r2=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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
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]
[EMAIL PROTECTED]:
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
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
Alexey Varlamov wrote: 2006/11/15, Alexey Varlamov [EMAIL PROTECTED]: 2006/11/15, Gregory Shimansky [EMAIL PROTECTED]: 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
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
Pardon for my English - a bit sleepy already...
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Pardon for my English - a bit sleepy already...
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
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 [EMAIL PROTECTED] wrote:
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Pardon for my English - a bit sleepy already...
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
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 [EMAIL PROTECTED] wrote:
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Pardon for my English - a bit sleepy already...
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
Oh. It's cool fix for my stupid bug.
Thanks for Alexey very much.
Pavel Afremov.
On 11/15/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Pardon for my English - a bit sleepy already...
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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
[classlib][testing] Showing test failures (Re: [drlvm] New regression: java.lang.ClassGenericsTest4)
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 ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
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. [EMAIL PROTECTED] 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
2006/11/16, Gregory Shimansky [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]:
Alexey Varlamov wrote:
2006/11/15, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/15, Gregory Shimansky [EMAIL PROTECTED]:
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: [classlib][testing] Showing test failures (Re: [drlvm] New regression: java.lang.ClassGenericsTest4)
2006/11/16, Tim Ellison [EMAIL PROTECTED]:
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 ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [drlvm] New regression: java.lang.ClassGenericsTest4
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 diagnosticdebug 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 [EMAIL PROTECTED]: 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
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 [EMAIL PROTECTED]: 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] [EMAIL PROTECTED]: 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
