Bound JDI test attach attempts by the startup deadline

[carstenartur]

Upstream submission

This is the prepared infrastructure fix for eclipse-jdt/eclipse.jdt.debug. The connected integration returned HTTP 403 when opening the upstream PR, so the patch and its reviewed scope are retained here.

Open the upstream pull-request comparison

This fork PR targets a read-only review baseline at upstream commit af15c262973bc93c130d33b993c5fd3195ae3ab5, not the fork's diverged working master. It contains exactly the three files intended for upstream. Please use upstream master as the base when submitting there.

---

What it does

Fixes a reproduced hang in the JDI test infrastructure: AbstractJDITest.connectToVM() checks a five-second retry budget, but calls the attaching connector with its default timeout=0. An accepted TCP connection whose peer does not reply to the JDWP handshake can therefore block inside attach() indefinitely. The outer retry loop never regains control to enforce its deadline.

The change passes a positive remaining startup budget to each attach attempt and handles org.eclipse.jdi.TimeoutException through the existing startup-failure path. It retains the five-second budget rather than increasing it.

Only the JDI test bundle changes:

• AbstractJDITest: configure the attach timeout and handle its expiration.
• VMConnectionTimeoutTest: exercise a real socket and the actual Eclipse JDI attaching connector against a silent peer.
• AutomatedSuite: include the new regression test.

No product debugger implementation, breakpoint code, test exclusion or retry-on-success mechanism is changed. No fork CI files are included in this PR.

How to test

Run org.eclipse.debug.jdi.tests.VMConnectionTimeoutTest as a JUnit Plug-in Test, or run the JDI AutomatedSuite.

The regression test opens a local TCP server, accepts the connection, reads and verifies JDWP-Handshake, and deliberately sends no reply. The unchanged test fails if the startup thread remains blocked beyond its ten-second safety guard. With the fix, startup instead reports its ordinary Could not contact the VM error after the five-second budget, and the test passes.

The real connectToVM() implementation and real JDI connector are used. A process double supplies only the console streams; it does not implement or simulate the transport. The peer is closed in finally to release even the unfixed implementation, and the startup thread, readers and previous static port are cleaned up/restored.

Executed before/after validation

Completed Tycho regression run, artifact jdi-startup-regression.

Both phases used the same test source, Java 26 toolchain and parent POM. The reactor built the JDI implementation and test bundle in both phases.

Implementation	Regression outcome	Recorded test duration
Unmodified upstream implementation plus the new test (3e00ec4)	Fails: The connector blocked past the startup deadline on a silent peer	10.466 s
Proposed fix (3ed46cb)	Passes; startup reports connection failure after 5011 ms	5.313 s

The validation checked the XML for exactly the intended named failure before the fix and a passing execution afterward, with no skipped tests. It did not infer success from Maven's exit status. Raw XML, Maven logs, the applied patch and toolchain checksums are retained in the artifact.

This is targeted before/after validation. A full upstream regression-suite result is still outstanding; the PR is draft pending that check.

Relationship to the failing builds under investigation

This defect was found while investigating the aborted builds for eclipse-jdt#990 and eclipse-jdt#992. It is independently reproducible and is separate from the startup-cleanup change in eclipse-jdt#992 upstream.

This PR does not claim that a silent handshake caused those original Jenkins failures. Their published failures include Connection refused; the complete Jenkins logs/thread dumps were not accessible in this investigation. Bounding a potentially unbounded attach fixes a demonstrated infrastructure bug, but does not itself make an unavailable VM accept a connection. The original startup failures still need to be followed through to a successful upstream run.

Author checklist

• I have thoroughly tested my changes (targeted before/after validation passed; full upstream CI pending)
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[carstenartur]

The proven attach-deadline fix has now been integrated into the existing upstream infrastructure PR eclipse-jdt#992, in commit df207cea34032ef36ac3a9d2073aa0cf8dcd5e2f. A separate upstream submission of this fork PR is therefore not needed for the current validation path.

The integration also retains the transport cause and pre-cleanup process state in the exception report, and verifies that a handshake timeout actually reaches startup cleanup.

Executed validation: https://github.com/carstenartur/eclipse.jdt.debug/actions/runs/33986167245, artifact startup-fix-evidence:

• The unchanged two new regression tests both fail on the previous cleanup-only implementation with the intended silent-peer deadline failure.
• With the integration, all 17 targeted tests and all 273 JDI test executions pass, none skipped. All previous 271 JDI executions remain, plus exactly two new ones.
• The tested integration has been pushed to the existing Ensure JDI test VM cleanup after failed startup eclipse-jdt/eclipse.jdt.debug#992 branch, and upstream Jenkins run 2 has started. Full debug-reactor runs, both with infrastructure alone and with the unchanged Clean up breakpoints after marker loss eclipse-jdt/eclipse.jdt.debug#990 patch, are also in progress.

The separate draft here retains the original minimal reproduction for reference. This does not establish that a silent handshake caused the original Connection refused failures; those still require a successful upstream run or further diagnosis using the new exception details.

[carstenartur]

Superseded by the integrated startup/cleanup fix in upstream eclipse-jdt#992 at df207cea34032ef36ac3a9d2073aa0cf8dcd5e2f. That version includes bounded real connector attaches, preserved transport cause/process state and two silent-peer/cleanup regression tests. Upstream Jenkins PR-992 build 2 has now passed the overall build and all 1,474 reported tests.

There is no longer a need to submit this older standalone draft separately upstream. Its original before/after evidence is retained here. PR eclipse-jdt#990 now includes the tested eclipse-jdt#992 commits as a separately identifiable dependency via merge b33666436ec20c8888fe87b01af16cbd32605864; the combined feature/infrastructure run is still pending.

Closing this fork-only draft as superseded, not merged.