RFR(xxs): 8249748: gtest silently ignores bad jvm arguments
david.holmes at oracle.com
Mon Jul 20 22:06:05 UTC 2020
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.
> Thanks, Thomas
> > issue: https://bugs.openjdk.java.net/browse/JDK-8249748
> > webrev:
> > Thanks, Thomas
More information about the hotspot-runtime-dev