[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552812#comment-17552812
]
Richard Harris edited comment on SUREFIRE-2058 at 6/10/22 4:10 PM:
-------------------------------------------------------------------
The consequence of this is quite significant - we have just upgraded to
3.0.0-M6 from 3.0.0-M3 and have found that some test goals (with JUnit4 tests)
have been marked as passing even though there are test failures, in each
problematic case this warning was produced, but it doesn't cause a failure and
means the actual results are hidden.
was (Author: JIRAUSER290819):
The consequence of this is quite significant - we have just upgraded to
3.0.0-M6 from 3.0.0-M3 and have found that test goals have been marked as
passing even though there are test failures, in each case this warning was
produced, but it doesn't cause a failure and means the actual results are
hidden.
> 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)
