RFR: 7904153: JTReg should include crash log data in the failure node for xml reports [v2]

[Jaikiran Pai]

On Tue, 17 Feb 2026 18:37:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/share/classes/com/sun/javatest/regtest/report/XMLWriter.java line 185:
>> 
>>> 183:                 Section s = tr.getSection(i);
>>> 184:                 for (String x : s.getOutputNames()) {
>>> 185:                     return s.getOutput(name);
>> 
>> Although I do agree that this code doesn't make too much sense, especially as variable `x` is unused, but it does some work since 2012. Maybe, others do rely on this feature? ➡️ https://www.hyrumslaw.com
>> 
>> Did you run this against more/all JDK tests and verify that no other party, like some test output parser tool, will break?
>
> Hi, thank you for looking at this PR. I've run `test/hotspot/jtreg:all` through AWS `CodeBuild` reports. Of course, I cannot test all the possible Junit XML parsers in the world, but I did test these popular search results on my change (with a little help from a friend 😉). I also added a unit test with this file to the Jenkins Junit Plugin. If there is some specific parser you would like me to test, please let me know.
> 
> 
> <?xml version="1.0" encoding="UTF-8" ?>
> <testsuite errors="0" failures="1" tests="1" hostname="776afbe4ce00" name="gc/shenandoah/TestRegionSampling.java#generational" time="2.887" timestamp="2026-02-17T02:11:56+0000">
>     <properties>
>         <property name="id" value="generational" />
>         <property name="keywords" value="othervm" />
>         <property name="requires" value="vm.gc.Shenandoah" />
>         <property name="run" value="USER_SPECIFIED main/othervm -Xmx1g -Xms1g -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+ShenandoahRegionSampling -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational TestRegionSampling
> " />
>         <property name="source" value="TestRegionSampling.java" />
>         <property name="title" value=" " />
>         <property name="description" value="file:/codebuild/output/src1098/src/s3/00/test/hotspot/jtreg/gc/shenandoah/TestRegionSampling.java#generational" />
>         <property name="elapsed" value="2887 0:00:02.887" />
>         <property name="end" value="Tue Feb 17 02:11:59 UTC 2026" />
>         <property name="environment" value="regtest" />
>         <property name="execStatus" value="Failed. Unexpected exit from test [exit code: 134]" />
>         <property name="harnessLoaderMode" value="Classpath Loader" />
>         <property name="harnessVariety" value="Full Bundle" />
>         <property name="hostname" value="776afbe4ce00" />
>         <property name="javatestOS" value="Linux 4.14.355-280.710.amzn2.x86_64 (amd64)" />
>         <property name="javatestVersion" value="6.0-ea+b24-2026-02-12-${BUILT_FROM_COMMIT}" />
>         <property name="jtregVersion" value="jtreg 8.3 dev 0" />
>         <property name="script" value="com.sun.javatest.regtest.exec.RegressionScript" />
>         <property name="sections" value="script_messages build compile main" />
>         <property name="start" value="Tue Feb 17 02:11:56 UTC 2026" />
>         <property name="test" value="gc/shenandoah/TestRegionSampling.java#generational" />
>         <property name="testJDK" value="/codebuild/outp...

Hello @earthling-amzn, I agree with Christian about this line change. It feels odd that there was a call to `Section.getOutputNames()` here, but looking at the implementation in getOutputNames() it looks like there are some state checks done. So I think it's better to retain the call to `getOutputNames()`. Of course, the use of for loop can be removed. I think you could change:


for (String x : s.getOutputNames()) {
    return s.getOutput(name);
}

to


String[] ignore = s.getOutputNames();
return s.getOutput(name);

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/316#discussion_r2822724911