RFR(xxs): 8249748: gtest silently ignores bad jvm arguments
thomas.stuefe at gmail.com
Mon Jul 20 14:17:39 UTC 2020
On Mon, Jul 20, 2020 at 2:54 PM David Holmes <david.holmes at oracle.com>
> 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
> > 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.
> 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?
> 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.
Gtestlauncher is called as part of the jtreg tests by the GtestWrapper, but
that does not pass any options to it.
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
> > issue: https://bugs.openjdk.java.net/browse/JDK-8249748
> > webrev:
> > Thanks, Thomas
More information about the hotspot-runtime-dev