[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280757#comment-17280757
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 5:31 AM:
------------------------------------------------------------------------
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
What I also found out is that the line of code which triggered the
{{ExecutionException}} caught in the last {{catch}} block is the line:
{{clientSocketChannel.connect( hostAddress ).get();}}
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
was (Author: kriegaex):
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> ------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
> Affects Versions: 3.0.0-M5
> Reporter: Alexander Kriegisch
> Priority: Major
> Attachments: image-2021-02-08-12-07-34-183.png,
> maven-failsafe-debug-log.txt
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{<forkNode
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
