RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12

[Baesken, Matthias]

Hi  Bob,  I tried your suggestion  .

It leads to 

java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187)
	at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120)
	at TestMemoryAwareness.main(TestMemoryAwareness.java:63)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:830)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from stdout/stderr


In the docker call we have now both

-Xmx133m   and   -Xmx768m

See :

docker run --tty=true --rm --volume /net/usr.work/d040975/mytmp/jtreg-workdir/classes/containers/docker/TestMemoryAwareness.d:/test-classes/ --memory 256m --memory-swappiness 0 --memory-swap 256m jdk-internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test-classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM 266


Best regards, Matthias



> -----Original Message-----
> From: Bob Vandette <bob.vandette at oracle.com>
> Sent: Freitag, 16. August 2019 14:36
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Severin Gehwolf <sgehwolf at redhat.com>; Langer, Christoph
> <christoph.langer at sap.com>; hotspot-dev at openjdk.java.net; Zeller, Arno
> <arno.zeller at sap.com>
> Subject: Re: RFR [XS] : 8229182:
> runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12
> 
> Instead of adding this: opts.appendTestJavaOptions = false;
> 
> 
> Try adding these lines:
> 
> String javaHeapSize = new String(sizeToAllocInMb/2) + “m”;
> 
> opts.addJavaOpts("-Xmx" + javaHeapSize);
> 
> This will set the max Java Heap to 1/2 of the size that we will attempt to
> allocate.
> This should reliably cause an OOM exception.
> 
> Bob.
> 
> 
> > On Aug 16, 2019, at 4:14 AM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> >> Can we not set -Xmx explicitly after any test options have been
> >> appended so that it takes precedence?
> >
> > Hi Bob,   do you have a good estimate for an Xmx to set ?
> >
> >> It seems fragile to disable
> >> appinding all test options altogether. Clearly, this test is
> >> susceptible to passed -Xmx options.
> >
> > We  have here a java - execution  taking place in the docker container, not
> the test machine itself .
> > I am not sure , are the "regular"   test options so good for this special
> execution ? Some maybe are , some aren’t ...
> >
> > E.g.  we ended up  with
> >
> > -Xmx768m -Djava.awt.headless=true
> >
> >  and more strange settings  in the  "docker run"   call because of this   ...
> >
> > Best regards, Matthias
> >
> >
> >
> >> Hi Matthias,
> >>
> >> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote:
> >>>> Unfortunately  we do not see the expected
> >> "java.lang.OutOfMemoryError"
> >>>> in the nightly test runs .
> >>>>
> >>>> When I execute  the  jtreg test locally  on the same (!)  ppc64le
> machine ,
> >>>> under the same user  but not from  the test framework we use nightly
> >>>> the  "java.lang.OutOfMemoryError"      shows up.
> >>>
> >>> Hello, after looking a bit more into it,   we observed   that  the  nightly
> runs
> >> set a higher -Xmx  = 768m  value  that gets inherited  into the
> >> DockerRunOptions
> >>> And made the  central  test  fail .
> >>> So I had to remove this  :
> >>>
> >>> 105         // make sure we avoid Xmx settings from the jtreg vmoptions
> >>> 106         opts.appendTestJavaOptions = false;
> >>
> >> Can we not set -Xmx explicitly after any test options have been
> >> appended so that it takes precedence? It seems fragile to disable
> >> appinding all test options altogether. Clearly, this test is
> >> susceptible to passed -Xmx options.
> >>
> >> Failing that, could we just omit the -Xmx option?
> >>
> >> Thanks,
> >> Severin
> >>
> >>> New webrev :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>> Hi Christoph,
> >>>>
> >>>>> Hi Matthias,
> >>>>>
> >>>>> looks good to me in general.
> >>>>>
> >>>>> However, I'm not convinced that line 114
> >>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a
> >> test
> >>>>> error in case the child process was killed by the container, e.g. exited
> >> with
> >>>>> exit code 137. We should at least run this patch for several days in our
> >>>> system
> >>>>> to see if it catches all variations of the problem.
> >>>>>
> >>>>
> >>>> Unfortunately  we do not see the expected
> >> "java.lang.OutOfMemoryError"
> >>>> in the nightly test runs .
> >>>>
> >>>> When I execute  the  jtreg test locally  on the same (!)  ppc64le
> machine ,
> >>>> under the same user  but not from  the test framework we use nightly
> >>>> the  "java.lang.OutOfMemoryError"      shows up.
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >