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

[Bob Vandette]

Can you send out the updated webrev?

Are you sure you retained this change?

   opts.appendTestJavaOptions = false;

We’ll need to figure out why this isn’t inhibiting the jtreg options.

Bob.;



> On Aug 27, 2019, at 8:35 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> 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
>>>>>> 
>>>>>> 
>>> 
>