[ https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17553669#comment-17553669 ]
Jesse Glick commented on SUREFIRE-2058: --------------------------------------- I was able to confirm that M7 fixes at least one variety of the stream corruption problem mentioned in the plugin FAQ. ([details|https://github.com/jenkinsci/plugin-pom/pull/557#issuecomment-1154075116]) Thanks! > 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 > Assignee: Tibor Digana > Priority: Blocker > Fix For: 3.0.0-M7 > > > 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.7#820007)