maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tibor Digana (JIRA)" <>
Subject [jira] [Commented] (SUREFIRE-1574) Communication between surefire plugin and its forks corrupted by test code
Date Fri, 02 Nov 2018 03:54:00 GMT


Tibor Digana commented on SUREFIRE-1574:

[~jactor] You have a different issue where Class-Path are relative in MANIFEST.MF within surefire
booter Jar.

[~arnoud] The tests are non-interactive which is intended. What sense it makes to require
STD/IN in the forked JVM? You use a separate application which sends some data to the {{InputStream}}
of the JVM which executes your tests?

> Communication between surefire plugin and its forks corrupted by test code
> --------------------------------------------------------------------------
>                 Key: SUREFIRE-1574
>                 URL:
>             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
>            Assignee: Tibor Digana
>            Priority: Blocker
>             Fix For: 3.0.0-M3
> 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 `` 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' `` 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 `` for the entire run()
(wrapping the entire run with synchronized( {}) to ensure no other thread can read
from the InputStream (as the individual read methods of BufferedInputStream used for
as synchronized as well). This is a risky move though, as I guess there is no guarantee that is always implemented by BufferedInputStream.
> I have prepared a project that demonstrates this behaviour: []
. 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

View raw message