slachiewicz commented on issue #38: URL: https://github.com/apache/maven-executor/issues/38#issuecomment-5403499111
Correction to "Why nothing catches it" above: the `@Timeout(60)` does fire. In the thread dumps on https://github.com/apache/maven/issues/12761 the `junit-jupiter-timeout-watcher` is `TIMED_WAITING` with a task queued at 68 s elapsed, and plain `WAITING` on a drained queue at 925 s — the timeout had already fired while the test thread was still parked. What defeats it is that `FastTerminal.getTerminal` catches `Exception`, `InterruptedException` included, and the caller re-enters the blocking call. The watcher interrupts once and then has nothing left to fire. `SEPARATE_THREAD` works because it reports from the watcher side without depending on the worker unblocking, and it attaches the stack trace of the frame that blocked. Root cause is https://github.com/apache/maven/issues/12761, a self-deadlock in `FastTerminal`; the fix is https://github.com/apache/maven/pull/12814. #40 makes the stall fail red here in the meantime, and its CI run reproduced it on `ubuntu-latest jdk-21-zulu 4.0.0-rc-6`: six named Maven 4 methods timing out at 60 s each, `Tests run: 60, Errors: 6`, where main previously reported `Tests run: 0` after nine minutes. The Surefire dump from that run also explains why six tests fail rather than one. `JLineNativeLoader.initialize()` is `static synchronized`, so the deadlocked thread holds the class monitor: the dump shows one `fast-terminal-thread` waiting and five BLOCKED at `initialize:158`. Noise reduction on the JLine side is https://github.com/jline/jline3/issues/2185. *This comment was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
