RFR(xxs): 8249748: gtest silently ignores bad jvm arguments

[David Holmes]

Hi Thomas,

On 21/07/2020 12:17 am, Thomas Stüfe wrote:
> Hi David,
> 
> 
> On Mon, Jul 20, 2020 at 2:54 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     On 20/07/2020 8:59 pm, Thomas Stüfe wrote:
>      > Hi,
>      >
>      > could I please have reviews for this very trivial patch?
>      >
>      > I found that gtest ignores invalid jvm options randomly since it
>     relies on
>      > an uninitialized variable.
> 
>     Is it really random? I would have expected it to be basically always
>     non-zero and hence always ignore unknown options. 
> 
> 
> I remember seeing cmdline option errors from gtest, and since this 
> coding is very old, this must be either my failing memory or the random 
> content of the underlying uninitialized stack memory.

Yes but there is only one value of that uninitialized memory (zero) that 
would cause unrecognised options to not be ignored.

>     I'm not at all clear
>     if running of the gtests might rely on always ignoring
>     unexpected/unknown flags - 
> 
> 
> It does not. googletest fishes its own arguments from the initial 
> argument vector and passes the rest off to the JVM. So the JVM ignoring 
> or not ignoring arguments will not change anything.
> 
>     does it have the capability to distinguish
>     product and non-product test runs?
> 
> 
> Gtests are hotspot coding and there are sections running with #ifdef 
> ASSERT, though I am not sure why that would matter?

For the same reason we sometimes need to @require that a VM is a debug 
VM with a jtreg test - because the flag passed in is a non-product flag. 
Also when we run test suites we often pass 
-XX:+IgnoreUnrecognisedVMOptions, again so that non-product flags don't 
cause a failure with release bits.

> 
>     I think this needs wider review from people familiar with how our gtest
>     tests are run. (I have no idea - I never use it.)
> 
> 
> I am quite familiar with it since I use it almost daily. I really depend 
> on it being able to interpret JVM options.
> 
> In fact I am a bit dismayed by this bug since I write tons of tests for 
> JEP387 and was feeling very smug about the tests running through in all 
> my test scenarios, only to find that since days I keep running the same 
> - default - scenario over and over again :( No, that should be really fixed.

I don't understand what you mean. This setting should only affect what 
happens with unrecognised "bad" arguments (as per your subject).

> Gtestlauncher is called as part of the jtreg tests by the GtestWrapper, 
> but that does not pass any options to it.

Pardon my ignorance but how does one specify options for a gtest then?

> But seriously, if there are tests which pass options to it, they 
> probably want those options to do something in the jvm, so ignoring them 
> silently is not good.

Again only "bad" options are ignored - which should only impact use of 
non-product flags with product bits.

David
-----

> Thanks, Thomas
> 
> 
>     Thanks,
>     David
> 
>      > issue: https://bugs.openjdk.java.net/browse/JDK-8249748
>      > webrev:
>      >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8249748-gtest-silently-ignores-bad-jvm-arguments/webrev.00/webrev/
>      >
>      > Thanks, Thomas
>      >
>