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

["Andrzej Jarmoniuk (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SUREFIRE-2058 ]


    Andrzej Jarmoniuk deleted comment on SUREFIRE-2058:
    ---------------------------------------------

was (Author: ajarmoniuk):
This is probably related to how failed tests from parent classes are reported (not checked that), but, if there were tests only defined in parent test classes and not in the concrete classes, 0 test cases were reported, like so:

[ERROR] <redacted>
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.172 s - in <redacted>
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

This is also fixed by this commit.

> 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.10#820010)