RFR(S): 8079590 - [TESTBUG] Test4524377 can't find dependent libraries
David Holmes
david.holmes at oracle.com
Mon Jun 1 07:35:43 UTC 2015
Hi Christian,
On 30/05/2015 7:19 AM, Christian Tornqvist wrote:
> Hi everyone,
>
> Please review this change that moves a previously closed test to the open
> test repository. Changed the test to use the new jtreg native make files
> instead of depending on pre-built binaries.
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8079590/webrev.00/
I understand you probably didn't write most of this code, but simply
copied it across, but now that it is here ... I found it very difficult
to tell what code is expected to work and what is expected to fail. For
example in the C code, it appears we are setting up a bad call for each
test case and so expect a failure, but in doing the setup we also omit
error checking eg:
c1 = (*env)->FindClass(env, "C1");
We expect to find c1 but don't check if it succeeds. Similarly:
152 c = (*env)->FindClass(env, "C1");
153 m = (*env)->GetMethodID(env, c, "<init>", "()V");
154 o = (*env)->NewObject(env, c, m);
we expect the sequence to succeed but don't verify that. And in
continuing even if an exception is pending we might even trigger a JNI
check fatal error different to that the test is really trying to trigger.
In the Java code we have:
58 try {
59 f = C1.class.getField("C1_int");
60 c = f.getType();
61 } catch (Exception e) {}
Is swallowing the exceptions part of the test or are we assuming they
will never be thrown? If the latter then they should just be allowed to
propagate.
108 // We should never get here
109 System.out.println(argv[0] + " failed");
110 }
Test failures are indicated by throwing exceptions.
Thanks,
David
>
>
> Bug (unfortunately not public):
>
> https://bugs.openjdk.java.net/browse/JDK-8079590
>
>
>
> Thanks,
>
> Christian
>
More information about the hotspot-runtime-dev
mailing list