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

["Zoltan Meze (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17518885#comment-17518885 ] 

Zoltan Meze edited comment on SUREFIRE-2058 at 4/7/22 1:33 PM:
---------------------------------------------------------------

I believe this is caused by not clearing output buffer after reading chunks in AbstractStreamDecoder#readString.
In first iteration decodeString end up with underflow, decoding only 1023 out of 1024 characters and leaving 1 space in output char buffer. Because the 1 remaining space, the output is never flipped/cleared and second iteration always end up with overflow.
- In first scenario it force reads one additional byte. This fills output buffer completely so it is able to exit the loop. Leftover input bytes are leaving the channel corrupted.
- In second scenario output buffer after overflow always ends up with 1 leftover space remaining. This is causing readString to be stuck in infinite loop.

I am currently testing this, seems to be working fine. But not sure if this is correct approach, I am not familiar with this code.
https://github.com/apache/maven-surefire/compare/master...zoltanmeze:SUREFIRE-2058


was (Author: JIRAUSER287608):
I believe this is caused by not clearing output buffer after reading chunks in AbstractStreamDecoder#readString.
In first iteration decodeString end up with underflow, decoding only 1023 out of 1024 characters and leaving 1 space in output char buffer. Because the 1 remaining space, the output is never flipped/cleared and second iteration always end up with overflow.
- In first scenario it force reads one additional byte. This fills output buffer completely so it is able to exit the loop. Leftover input bytes are leaving the channel corrupted.
- In second scenario output buffer after overflow always ends up with 1 leftover space remaining. This is causing readString to be stuck in infinite loop.

I am currently testing this, seems to be working fine. But not sure if this is correct approach.
https://github.com/apache/maven-surefire/compare/master...zoltanmeze:SUREFIRE-2058

> 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
>            Priority: Blocker
>
>  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)