[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677243#comment-17677243
]
Andrzej Jarmoniuk commented on SUREFIRE-2058:
-
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:
{{noformat}}
[ERROR]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.172 s
- in
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{{noformat}}
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=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>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)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553681#comment-17553681
]
Richard Harris commented on SUREFIRE-2058:
--
[~zoltan.meze] yes - we've upgraded onwards to 3.0.0-M7 and the tests failures
started showing up properly and failing the builds again, so we're all good.
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=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>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)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>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)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553041#comment-17553041
]
Zoltan Meze commented on SUREFIRE-2058:
---
[~richardh-alfa] New version 3.0.0-M7 is out now. Can you try on that one?
> 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=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>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)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552812#comment-17552812
]
Richard Harris commented on SUREFIRE-2058:
--
The consequence of this is quite significant - we have just upgraded to
3.0.0-M6 from 3.0.0-M5 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=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>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)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518885#comment-17518885
]
Zoltan Meze commented on SUREFIRE-2058:
---
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=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>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)
