RFR(S): 8079590 - [TESTBUG] Test4524377 can't find dependent libraries

Christian Tornqvist christian.tornqvist at oracle.com
Tue Jun 2 21:26:48 UTC 2015


Hi David,

> I understand you probably didn't write most of this code

Yes, since there are no comments on what the individual test cases are doing
I concur that it's very difficult to tell what the code is expected to do. 

I don't have the time to go through and figure out all the test cases at
this point, so I'm withdrawing this change. The test has been excluded and
won't cause any more issues for the moment and someone can revisit this
issue at some point.

Thanks,
Christian

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Monday, June 1, 2015 3:36 AM
To: Christian Tornqvist; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(S): 8079590 - [TESTBUG] Test4524377 can't find dependent
libraries

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