Fwd: RFR (M) : JDK-7149464 : [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test

[David Holmes]

On 12/09/2013 10:59 AM, David Holmes wrote:
> Hi Misha,
>
> On 12/09/2013 2:46 AM, Mikhailo Seledtsov wrote:
>> Hi,
>>
>>      JBS: https://bugs.openjdk.java.net/browse/JDK-7149464
>>          This bug description is Oracle internal.
>>          According to the bug, in certain cases JTReg failed to delete
>> the temporary files. In addition to that, the test consumed excessive
>> time and resources on the system.
>>
>>      Webrev:
>> http://cr.openjdk.java.net/~mseledtsov/7149464/webrev.01/
>> <http://cr.openjdk.java.net/%7Emseledtsov/7149464/webrev.01/>
>>
>>      Testing:
>>          JPRT using this specific test
>> (2013-09-10-135828.mseledtsov.bugFixing01)
>>
>>      Comments:
>>         - rewrote this test in Java. This had couple of benefits.
>
> There is a problem here that "we" need to resolve. The shell script uses
> COMPILEJDK to run the jar command. The Java program uses JDKToolFinder
> which uses the "test JDK". Now this test will have to be be added to the
> "needs_jdk" group in TEST.groups.

Never mind - I just saw Christian's RFR for the change to JDKToolFinder 
which fixes this problem.

Thanks,
David

> This is not a direction I think we want to head with these test
> conversions. There must be a way to ask the testlibrary for a tool from
> the compile-jdk!
>
> David
> -----
>
>
>> Following general direction of rewriting JTReg tests in Java and
>> avoiding portability issues. Also, the shell script created temporary
>> files for output analysis, which in case of test taking too long or
>> failure, in certain cases,  could not be deleted since the handle was
>> still active. The new test uses OutputAnalyzer utility for this purpose,
>> thus not needing the temporary output files, and solving the problem.
>>         - after discussions with the Run-time team, the limit for
>> malloc'ed memory was added to the test by using -XX:MallocMaxTestWords,
>> thus fixing the issue of using excessive resources
>>
>> Thank you,
>> Misha
>>
>>