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 soAh 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
