[
https://issues.apache.org/jira/browse/SUREFIRE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15997438#comment-15997438
]
Tibor Digana edited comment on SUREFIRE-1359 at 5/4/17 9:41 PM:
----------------------------------------------------------------
[~MattNelson]
This problem was always, but nobody could see it in the logs. Here we only
notify you that something went wrong but not on surefire side. The entire
problem is that we have blocker and critical issues assigned against Maven
because the tests and frameworks print bytes to native std/out stream in the
forked jvm. Therefore we may decode it by mistake. This way we try to force the
f/w vendors to use {{System.out.print()}} instead of {{FileDescriptor.out}} and
{{ProcessBuilder.inheritIO()}}.
{quote}
even those which surefire did not spawn
{quote}
This sounds like the plugin process loaded test classes and static code which
has {{ProcessBuilder}}. We load the class first in plugin process and scan
{{@Test}} annotations and then in forked jvm second this and instantiating the
class via JUnit framework.
Please see SUREFIRE-1222. The Arquillian avoided using inherited channel:
https://github.com/tremes/arquillian-container-se/commit/8e8c4455af0412a363824690e77e8ee102fc3b9f
Maybe this helps.
was (Author: tibor17):
[~MattNelson]
This problem was always, but nobody could see it in the logs. Here we only
notify you that something went wrong but not on surefire side. The entire
problem is that we have blocker and critical issues assigned against Maven
because the tests and frameworks print bytes to native std/out stream in the
forked jvm. Therefore we may decode it by mistake. This way we try to force the
f/w vendors to use {{System.out.print()}} instead of {{FileDescriptor.out}} and
{{ProcessBuilder.inheritIO()}}.
>>even those which surefire did not spawn
This sounds like the plugin process loaded test classes and static code which
has {{ProcessBuilder}}. We load the class first in plugin process and scan
{{@Test}} annotations and then in forked jvm second this and instantiating the
class via JUnit framework.
Please see SUREFIRE-1222. The Arquillian avoided using inherited channel:
https://github.com/tremes/arquillian-container-se/commit/8e8c4455af0412a363824690e77e8ee102fc3b9f
Maybe this helps.
> Corrupted stdin stream in forked JVM 1. See the dump file
> ---------------------------------------------------------
>
> Key: SUREFIRE-1359
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1359
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.20
> Environment: JDK 1.8.0_121
> maven version 3.5.0
> Reporter: Brian Oxley
> Assignee: Tibor Digana
> Attachments: 2017-04-13T10-56-35_635-jvmRun1.dumpstream,
> 2017-04-13T10-56-36_592.dumpstream, failsafe-summary.xml,
> hm.binkley.labs.GitInfoIT.txt, hm.binkley.labs.GreetingControllerIT.txt,
> TEST-hm.binkley.labs.GitInfoIT.xml,
> TEST-hm.binkley.labs.GreetingControllerIT.xml
>
>
> Surefire 2.20 complains "Corrupted stdin stream in forked JVM 1. See the dump
> file". Version 2.19.1 does not, and testing completes successfully.
> Project is here: https://github.com/binkley/sproingk.
> Run with "mvn clean verify".
> Same behavior on Windows 10 (Oracle JDK), MacOS and the Linux subsystem on
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
