Gary
Just want to add that following code
68 } catch (OutOfMemoryError me) {
69 me.printStackTrace();
70 }
might throw another OOME in printStackTrace().
If you want to do something after OOME it is needed to free some before trying
to allocate.
Leonid
> On Mar 25, 2019, at 12:46 PM, Chris Plummer <chris.plum...@oracle.com> wrote:
>
> Hi Gary,
>
> In resexhausted004.java, the indentation needs to be fixed. Also, what
> happens if one of the caught exceptions is thrown? Does the test fail or
> pass? I'm not sure what the default behavior is if you just return from
> main().
>
> Otherwise looks good.
>
> thanks,
>
> Chris
>
> On 3/25/19 11:18 AM, Gary Adams wrote:
>> During testing I found that there is still good reasons to leave 003 and 004
>> tests on the ProblemList. I believe there is still work to be done to ensure
>> JDK-7013634 and JDK-6606767 are covered.
>>
>> This pass attempts to solve the primary issue in this bug which is improper
>> paths on the
>> test command lines. Cleanup is limited to the 003 and 004 tests. The tests
>> will
>> remain on the ProblemList.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128
>> <https://bugs.openjdk.java.net/browse/JDK-8218128>
>> Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html
>> <http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html>
>>
>> On 3/8/19, 3:39 PM, Chris Plummer wrote:
>>>
>>> Ok, I didn't realize the @ignore was removed also. I guess this is what
>>> "exclude" was converted into. So the question now is should the @ignore
>>> (and the exclude comment) remain. The @ignore bug (JDK-7013634) was closed
>>> as CNR. I'm actually the one that closed it a while back, and that may have
>>> been a mistake since I didn't realize that some of the tests had been
>>> completely excluded from testing, even quarantine testing. After reading
>>> through some of the comments in JDK-7013634, I'm not trusting these tests
>>> to run reliably. That's often the case with tests that try to exhaust
>>> resources.
>>>
>>> Chris
>>>
>>> On 3/8/19 9:41 AM, Gary Adams wrote:
>>>> On 3/8/19, 12:10 PM, Chris Plummer wrote:
>>>>>
>>>>> You can remove the quarantine and exclude keywords. I think that's
>>>>> appropriate if the test is off the problemlist and working. It was just
>>>>> nonconcurrent removal that I was against.
>>>> Done
>>>>>
>>>>> As for the resexhausted001 failure you are still seeing, how could jtreg
>>>>> exclude it if it was not on the problemlist. I didn't think there was any
>>>>> other mechanism. I don't believe jtreg looks at the tonga keywords.
>>>>
>>>> I believe the @ignore is a jtreg keyword.
>>>> With the -ignore command line flag jtreg can be directed to
>>>> quietly ignore a test, or force an error, or attempt to run the test
>>>> even though the @ignore directive is there.
>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>> On 3/8/19 5:07 AM, Gary Adams wrote:
>>>>>> I'll revert the comments that were left in during the tonga conversion.
>>>>>>
>>>>>> I did come across an interesting test failure in resexhausted001
>>>>>> which had an
>>>>>> @ignore 7013634
>>>>>>
>>>>>> JDK-7013634: jvmti resexhausted001 can timeout or fail due to
>>>>>> excessive thread creation
>>>>>>
>>>>>> The test was closed because it was not reproducible.
>>>>>> Even though the test was not on the ProblemList, I believe
>>>>>> jtreg was excluding the test from running.
>>>>>>
>>>>>> The original problem reported an "out of swap" condition.
>>>>>>
>>>>>> The current failure reports:
>>>>>> ----------System.out:(3/217)----------
>>>>>> Creating threads...
>>>>>> Timeout refired 480 times
>>>>>> [730.871s][warning][os,thread] Failed to start thread - _beginthreadex
>>>>>> failed (EACCES) for attributes: stacksize: default, flags:
>>>>>> CREATE_SUSPENDED STACK_SIZE_PARAM_IS.
>>>>>>
>>>>>>
>>>>>> On 3/7/19, 4:02 PM, Chris Plummer wrote:
>>>>>>>
>>>>>>> Hi Gary,
>>>>>>>
>>>>>>> Why did you remove the "nonconcurrent" keyword. I know these are just
>>>>>>> comments for reference that were added when the test was ported from
>>>>>>> tonga, but as a comment it is still applicable. The test should not be
>>>>>>> run concurrent with others (which you have also fixed with the addition
>>>>>>> of the "exclusiveAccess.dirs=.").
>>>>>>>
>>>>>>> Otherwise changes look good.
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On 3/7/19 10:57 AM, Gary Adams wrote:
>>>>>>>> This proposed fix will restore the ResourceExhausted tests.
>>>>>>>>
>>>>>>>> Test 3 and 4 were on the ProblemList because of the potential
>>>>>>>> path issues in finding the correct classes. This change searches the
>>>>>>>> test.class.path for the appropriate vmTestbase classes rather than
>>>>>>>> using
>>>>>>>> incorrect settings on the command line.
>>>>>>>>
>>>>>>>> Some clean up has been done to remove quarantine keyword
>>>>>>>> and @ignore directives. Should additional clean up be done to remove
>>>>>>>> bug numbers, etc.?
>>>>>>>>
>>>>>>>> TEST.PROPERTIES were added so test 3 so it is consistent with the
>>>>>>>> other tests
>>>>>>>> in the group.
>>>>>>>>
>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8218128>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html
>>>>>>>> <http://cr.openjdk.java.net/%7Egadams/8218128/webrev.00/index.html>
>>>>>>>>
>>>>>>>> Local testing has been successful on a linux-x64-debug build.
>>>>>>>> Testing on mach5 for other platforms next.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
