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