[4.0.x] Fix #12761: do not wait for the terminal on the thread building it - #12854
Merged
Conversation
…12814) * Fix #12761: do not wait for the terminal on the thread building it MessageUtils.systemInstall publishes the FastTerminal before the background thread has built the real one, and every FastTerminal method delegates through getTerminal(). Anything that thread logs is therefore rendered through a terminal that same thread is still producing, and parks on its own future. There is no lock cycle, so jstack reports no deadlock. Both the builder callable and the consumer callback are inside that window: the consumer runs before terminal.complete(term). Two distinct call paths reach it from a single log statement, the level rendering via toAnsi and the log sink via terminal.writer(), so guarding one call site is not enough. getTerminal() hands the building thread a dumb stand-in instead, which unblocks every delegating method at once. Do not narrow this to a plain-text fallback in the message builder: the writer path would still park. The stand-in writes to the System.err captured at construction, not the live one, which the consumer replaces with a logging-backed stream that would feed the output back into the logger it came from. Rendering degrades to unstyled text for the duration of the build, which is what a dumb terminal would produce anyway. The build thread also becomes a daemon, so a wedged build cannot keep the JVM alive. JLine 4.x initialises its native loader during provider probing and logs a warning when a library candidate fails, which is what made this reachable after the 3.30.6 to 4.3.1 bump in 4.0.0-rc-6. The failure itself is harmless, JLine recovers by extracting the bundled library. * Answer the two terminal calls directly instead of standing in a terminal Handing the building thread a DumbTerminal meant constructing a terminal inside terminal construction, on that same thread, in a failure path. It wedged on ubuntu/jdk-17 when the stand-in was built after the consumer had already run AnsiConsole.systemInstall, while passing everywhere else. A log statement asks the terminal for exactly two things, its type while rendering and its writer while emitting. AttributedCharSequence.toAnsi asks for the type first and renders plain for a dumb one, so it never reaches any other method. Answering those two with a constant and a PrintWriter over the captured stream covers the same paths and cannot block. The tests now exercise both calls from both halves of the window rather than one call each.
gnodet
commented
Aug 27, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
Author
There was a problem hiding this comment.
Clean cherry-pick of #12814 deadlock fix to maven-4.0.x. The diff is byte-for-byte identical to the original (only git index hashes differ due to different base). All 21 CI checks pass across the full OS/JDK matrix.
✅ Looks good
- Re-entrancy detection logic (
isBuildThreadWaitingOnItself) is identical to the original - Safe fallbacks (
TYPE_DUMBforgetType(), pre-capturedSystem.errwriter forwriter()) are correctly preserved - Test exercises re-entrant calls from both builder callable and consumer callback with preemptive timeouts
maven-3.9.x/maven-3.10.xdon't useFastTerminal(JLine 4.x / maven-jline module), so no further backports needed
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #12814 to
maven-4.0.x.Fixes a startup hang where
FastTerminaldeadlocks when JLine 4.x logs a JUL warning during native-library probing on the terminal-building thread. The thread parks on its own future whengetTerminal()is called re-entrantly through the SLF4J bridge.The fix returns
TYPE_DUMBand a pre-captured writer for the two re-entrant call sites (getType()andwriter()), degrading to unstyled text only while the real terminal is still being built.Cherry-picked cleanly from 02a675d.