You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Zoltan Meze (Jira)" <ji...@apache.org> on 2022/04/05 09:16:00 UTC

[jira] [Created] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging

Zoltan Meze created SUREFIRE-2058:
-------------------------------------

             Summary: Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
                 Key: SUREFIRE-2058
                 URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
             Project: Maven Surefire
          Issue Type: Bug
          Components: JUnit 5.x support, Maven Surefire Plugin
    Affects Versions: 3.0.0-M6
            Reporter: Zoltan Meze


 With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
{code:java}
[WARNING] Corrupted channel by directly writing to native stream in forked JVM 1. {code}


This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test project).

 
After some digging, there are two different scenarios (most likely caused by the same issue):
 * 2-byte character at position 1023 (or N * 1024 - 1) in log message is causing the following warning
{code:java}
[WARNING] Corrupted channel by directly writing to native stream in forked JVM 1.
{code}
To reproduce this issue logback (with slf4j) should be used. 
Not able to reproduce with System.out.println.

 * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
Can be reproduced with System.out.println (logback not required in this case).
This blocks surefire entirely at (from jstack):
{code:java}
"fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms elapsed=32.94s tid=0x00007ff8292d7800 nid=0x3caef runnable  [0x00007ff7876f6000]
   java.lang.Thread.State: RUNNABLE
	at org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
	at org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
	at org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
	at org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
	at org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
{code}
 

Project with reproducible tests (for both scenarios, more in README):
[https://github.com/zoltanmeze/surefire-corrupted-channel]

 

One workaround on M6 for now is to use different charset (instead of default UTF-8) or limit message size.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)