[ https://issues.apache.org/jira/browse/SUREFIRE-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16666493#comment-16666493
]
Tor Egil Jacobsen edited comment on SUREFIRE-1574 at 10/28/18 5:42 PM:
-----------------------------------------------------------------------
Is this bug not present on all operating systems? I have a code base which builds fine on
my Mac, but when building on docker image maven:3.5.4-jdk-10, the build fails...
Please take a look at [[https://github.com/jactor-rises/jactor-rises/issues/6]|http://example.com/]
was (Author: jactor):
Is this bug not present on all operating systems? I have a code base which builds fine on
my Mac, but when building on docker image maven:3.5.4-jdk-10, the build fails...
Please take a look at [https://github.com/jactor-rises/jactor-rises/issues/6|http://example.com/]
> Communication between surefire plugin and its forks corrupted by test code
> --------------------------------------------------------------------------
>
> Key: SUREFIRE-1574
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1574
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.22.0
> Environment: Maven 3.5.4
> Surefire 2.22.0
> Pax Exam 4.12.0
> Reporter: Arnoud Glimmerveen
> Priority: Blocker
> Fix For: 3.0.0-M2
>
>
> In a setup with maven-surefire-plugin 2.22.0 with PAX Exam 4.12.0 I occasionally see
that the Maven build takes about 30 seconds longer than expected. The source of this additional
30 seconds is a timeout used to eventually terminate a fork if it does not terminate by itself.
> I have traced the cause of this failure to terminate to the Thread inside the fork receiving
commands from the maven plugin (silently) terminating with an IOException. This is triggered
by the validation logic inside MasterProcessCommand to check for commands without payload
(NOOP, BYE_ACK) that there is actually no data send. If some other code reads data from the
same `System.in` InputStream, the MasterProcessCommand.decode method may read data belonging
to subsequent commands.
> Relying on the assumption that the Surefire logic in the forked process is the only one
reading from the 'shared resource' `System.in` makes it vulnerable to this corruption. I see
that the catch clause of IOException in CommandReader also reports this, though I did not
see the '[SUREFIRE] std/in stream corrupted' error in my runs.
> Some of the solutions I thought of:
> * Replacing the communication protocol (also mentioned here)
> * Have the CommandRunnable hold an exclusive lock on `System.in` for the entire run()
(wrapping the entire run with synchronized(System.in) {}) to ensure no other thread can read
from the InputStream (as the individual read methods of BufferedInputStream used for System.in
as synchronized as well). This is a risky move though, as I guess there is no guarantee that
System.in is always implemented by BufferedInputStream.
> I have prepared a project that demonstrates this behaviour: [https://github.com/glimmerveen/fork-test]
. The timeout behaviour is visible as the test results are reported on the stdout of Maven,
but the build process does not continue for another 30 seconds or so. Note that the corruption
does not always happen.
> Note that I reported this as blocking not necessarily because of the additional time
it takes for the build to execute, but due to the fact that when the fork is terminated by
the timeout, frameworks like JaCoCo don't get the opportunity to output their results.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)