Reduce OpenCloseTest iterations and dump threads on hang#4102
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adjusts the OpenCloseTest stress tests to be less costly in CI and to produce actionable diagnostics when a UI-thread deadlock/hang occurs (notably on macOS), by adding a per-test watchdog that emits a full thread dump and then aborts instead of waiting for the bundle-level timeout.
Changes:
- Reduce stress iteration count from 10 to 4 to keep automated builds faster.
- Add a per-test watchdog thread that, after 200s, dumps all thread stacks and attempts to abort the JVM if the test remains stuck.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| try { | ||
| Thread.sleep(WATCHDOG_GRACE_MS); | ||
| } catch (InterruptedException e) { | ||
| return; // test recovered after the interrupt and disarmed the watchdog | ||
| } |
There was a problem hiding this comment.
Good catch. The PR now records the test as failed whenever the per-method deadline is exceeded, even if the thread recovers after the interrupt, so a late run can no longer pass silently.
|
Nice, no timeout anymore with this change. The suggestion from from copilot is not wrong, I will update the PR |
3fc54e3 to
86e2f1c
Compare
|
Mobile app still create merge commit, will fix |
OpenCloseTest occasionally deadlocks on macOS in testOpenClosePerspective and then produces no output until the 1200 second bundle timeout kills the whole JVM, so the run fails with no usable diagnostic. Add a per method watchdog that dumps all thread stacks and aborts once a method exceeds 200 seconds, so a hang reports a stacktrace instead of being killed silently. A plain JUnit timeout cannot be used because these tests run on the UI thread. Also reduce the iteration count from 10 to 4 to keep the automated build fast; it can be raised locally for real stress testing. eclipse-platform#4101
5ef078e to
86e1252
Compare
OpenCloseTest occasionally deadlocks on macOS in testOpenClosePerspective and then produces no output until the 1200 second bundle timeout kills the whole JVM, so the run fails with no usable diagnostic. This adds a per method watchdog that dumps all thread stacks and aborts once a method exceeds 200 seconds, so a hang reports a stacktrace instead of being killed silently. A plain JUnit timeout cannot be used here because these tests run on the UI thread. The iteration count is also reduced from 10 to 4 to keep the automated build fast; it can be raised locally for real stress testing.
See #4101.