On Fri, 7 Aug 2026 14:39:30 GMT, Shiv Shah <[email protected]> wrote: >> The failure handler keys each HTML section id by the command's name path, so >> when a command name occurs again after an intervening command - the same >> command repeated, or the same top-level tool reused, as in >> "jcmd.compiler.codecache jinfo jcmd.compiler.codelist" - a second section >> with the same id is written. Anchors and the data-toggle / data-show >> javascript resolve ids via document.getElementById, which returns the first >> match, so the later occurrence's output is unreachable. These are the two >> cases reported in the bug. >> >> Fix: the root section keeps a registry of issued ids; a repeated id gets the >> first free numeric suffix ("jcmd-2", ...). Displayed names are unchanged, >> adjacent commands with a shared prefix still share their sections, children >> of a suffixed section are unique automatically, and the registry also >> prevents collisions with a command literally named like a suffix. The only >> external id reconstruction, ToolKit.link(), is keyed by PID and unaffected. >> >> Ids can still repeat across appended fragments (each invocation appends a >> complete HTML document); that is pre-existing and tracked as JDK-8389541. >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Shiv Shah has updated the pull request incrementally with one additional > commit since the last revision: > > Remove bug id from comment and always initialize sectionIds
> Thank you for the updates. Looks good to me. > > Before integrating, if you haven't done so already, please once run this > change in our CI against a (intentionally) failing test and a (intentionally) > timing out test to make sure that the artifacts/reports continue to be > generated correctly through the timeout handler and the failure handler > actions. > I tested this in CI with one test that fails intentionally and one that times > out intentionally. In the timeout case, the handler ran, processes.html > contained the expected jcmd and jstack output, and its SIGABRT kill produced > a populated cores.html. The failure observer produced a populated > environment.html for both cases, and I found no duplicate section IDs in any > generated report. The plain failure did not produce cores.html... it only > throws a Java exception and produces no core. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32157#issuecomment-5220724501
