Another race condition involving MessageUtils

[oehme]

Affected version

4.0.x

Bug description

MessageUtils uses a FastTerminal, which calls systemInstall in a background thread. I already found one race condition where uninstall was called before this background thread finishes. #11048

Unfortunately, there is another race in LookupInvoker. It also calls System.setOut and depending on the timing, this can happen before the FastTerminal background thread finishes. When that happens, you get a StackOverflowError on the next log message.

[oehme]

Ah sorry, nevermind, this method is called on the background thread. We are still seeing race conditions though, so I'll have to keep digging. I'll get back when I know more. Here's what we keep seeing on our CI server with 4.0.x nightly builds:

at org.apache.maven.cling.invoker.LookupInvoker.lambda$doConfigureWithTerminalWithRawStreamsDisabled$9(LookupInvoker.java:395)
          at org.apache.maven.logging.LoggingOutputStream.write(LoggingOutputStream.java:54)
          at java.base@21.0.4/java.io.FilterOutputStream.write(FilterOutputStream.java:139)
          at java.base@21.0.4/java.io.PrintStream.implWrite(PrintStream.java:643)
          at java.base@21.0.4/java.io.PrintStream.write(PrintStream.java:629)
          at java.base@21.0.4/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:309)
          at java.base@21.0.4/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:381)
          at java.base@21.0.4/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:357)
          at java.base@21.0.4/sun.nio.cs.StreamEncoder.lockedWrite(StreamEncoder.java:158)
          at java.base@21.0.4/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:139)
          at java.base@21.0.4/java.io.OutputStreamWriter.write(OutputStreamWriter.java:219)
          at java.base@21.0.4/java.io.BufferedWriter.implFlushBuffer(BufferedWriter.java:178)
          at java.base@21.0.4/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:163)
          at java.base@21.0.4/java.io.BufferedWriter.implWrite(BufferedWriter.java:334)
          at java.base@21.0.4/java.io.BufferedWriter.write(BufferedWriter.java:313)
          at java.base@21.0.4/java.io.Writer.write(Writer.java:278)
          at java.base@21.0.4/java.io.PrintStream.implWrite(PrintStream.java:810)
          at java.base@21.0.4/java.io.PrintStream.write(PrintStream.java:796)
          at java.base@21.0.4/java.io.PrintStream.print(PrintStream.java:1002)
          at java.base@21.0.4/java.io.PrintStream.println(PrintStream.java:1171)
          at org.apache.maven.slf4j.MavenBaseLogger.write(MavenBaseLogger.java:230)
          at org.apache.maven.slf4j.MavenSimpleLogger.write(MavenSimpleLogger.java:81)
          at org.apache.maven.slf4j.MavenBaseLogger.innerHandleNormalizedLoggingCall(MavenBaseLogger.java:378)
          at org.apache.maven.slf4j.MavenBaseLogger.handleNormalizedLoggingCall(MavenBaseLogger.java:309)
          at org.slf4j.helpers.AbstractLogger.handle_0ArgsCall(AbstractLogger.java:382)
          at org.slf4j.helpers.AbstractLogger.info(AbstractLogger.java:203)
          at org.apache.maven.cling.invoker.LookupInvoker.lambda$doConfigureWithTerminalWithRawStreamsDisabled$9(LookupInvoker.java:395)

[oehme]

One thing I noticed: systemUninstall has no protection against underflow: https://github.com/jline/jline3/blob/master/jansi-core/src/main/java/org/jline/jansi/AnsiConsole.java#L401.

So if for some reason uninstall is called twice, then installed == -1 and the next install call will do nothing. I'm not sure this is the cause for this problem, but it seems like something that should be protected against. It should probably fail when uninstall is called when nothing was installed.

If it had this protection, we would also have found the previous race condition faster.

[oehme]

Opened jline/jline3#1525 to address that.

[guylabs]

@gnodet is it possible to update the version of Jline on the master branch as raised here?

[guylabs]

@cstamas Are you maybe able to have a look at this?

[cstamas]

@gnodet is it possible to update the version of Jline on the master branch as raised here?

Version of jline is up to date on master, so unsure what version you refer to?

[guylabs]

It appears that the new patch version has not been released yet, as indicated by this change: jline/jline3#1525. Once that is released, it would be nice if you could upgrade the version on the master branch of Maven core.

[guylabs]

@cstamas What is the status here?

[guylabs]

@gnodet @cstamas Would it be possible to release a new version of jline and update the Maven maven-4.0.x and master branch?

[cstamas]

Jline3 release expected next week, then we can update.

[guylabs]

Thanks for the new JLine release. Once this pull request is merged, we can see if that solves our issue.

• Bump jlineVersion from 3.30.6 to 4.0.0 #11757

Will the maven-4.0.x branch be merged back to master once the above is merged?

[guylabs]

@cstamas @gnodet Can you merge these two pull requests?

• Bump jlineVersion from 3.30.6 to 4.0.4 #11789
• Bump jlineVersion from 3.30.6 to 4.0.4 #11793