RFR(XS): 8251121: six SA tests leave core files behind on macOS
Chris Plummer
chris.plummer at oracle.com
Thu Aug 6 18:31:01 UTC 2020
Hi Dan,
On 8/6/20 10:17 AM, Daniel D. Daugherty wrote:
> On 8/5/20 9:16 PM, Chris Plummer wrote:
>> Hello,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8251121
>> http://cr.openjdk.java.net/~cjplummer/8251121/webrev.00/index.html
>
> test/lib/jdk/test/lib/util/CoreUtils.java
> You might consider two messages with timestamps: one before the move
> and one after the move completes.
>
Do we have an standard timestamp printing support for our jtreg tests? I
found the following in vmTestbase/nsk/share/Log.java:
/**
* Compose line to print possible prefixing it with timestamp.
*/
private String composeLine(String message) {
if (timestamp) {
long time = System.currentTimeMillis();
long ms = time % 1000;
time /= 1000;
long secs = time % 60;
time /= 60;
long mins = time % 60;
time /= 60;
long hours = time % 24;
return "[" + hours + ":" + mins + ":" + secs + "." + ms +
"] " + message;
}
return message;
}
Would be nice if we had something like that more generally available to
all jtreg tests.
thanks,
Chris
> test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java
> No comments.
>
> Thumbs up. No need for another webrev if you decide to update the mesgs.
>
> I'm testing your patch on my MBP13 to verify that it solves the issue
> that I reported.
>
> Dan
>
>
>>
>> On OSX (and possibly some linux systems), core files are not produced
>> in the cwd, but instead end up in some well known location. For OSX
>> it is the /cores directory. The core files tend to accumulate there.
>> This fixes the core file accumulation problem by moving the core file
>> into the cwd, allowing jtreg to manage it. By default jtreg will
>> delete the core if the test passes, and retain if if the test fails
>> or RETAIN=all is specified.
>>
>> I got rid of the code in ClhsdbCDSCore.java that explicitly deletes
>> the core file because we don't want it deleted if RETAIN=all is used.
>>
>> thanks,
>>
>> Chris
>
More information about the serviceability-dev
mailing list