[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281048#comment-17281048
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 1:24 PM:
------------------------------------------------------------------------
With all due respect, what you say is illogical. My agent does not change a
single bit in any of those classes, signified by its returning {{null}} in all
cases. An agent has no influence over when it is being called by the JVM during
class-loading. This is true for both JaCoCo and my sample agent. What makes the
build hang is not instrumentation but the client logging something to the
system console in {{<forkNode ... SurefireForkNodeFactory"/>}} mode, sorry to
repeat myself.
This would happen the same if JaCoCo would log something in the same situation,
just like originally it happens with my ByteBuddy agent. It would happen with
all agents logging something during execution, such as AspectJ load-time weaver
or whatever other valid agents there are in this world. My agent is the
simplest possible agent, doing nothing but logging something. The very same
agent works when deleting the two log lines I mentioned or when not using the
brandnew {{<forkNode ... SurefireForkNodeFactory"/>}} setting. So it *is* the
combination of this Surefire setting with logging to the system console which
upsets the JVM, making is hang.
Need more proof? Fine. Just eliminate the Java agent from the equation by
changing
{code:xml}
<argLine>-javaagent:${project.build.directory}/${project.build.finalName}.jar</argLine>{code}
to simply
{code:xml}
<argLine>-verbose:class</argLine>
{code}
making the JVM log each loaded class to the system console. Optionally (not
really necessary), comment out
{{Agent.INSTRUMENTATION.retransformClasses(...);}} in {{AgentIT}} to stop the
test from failing with an exception due to the non-existent agent. The build
will again hang in {{<forkNode ... SurefireForkNodeFactory"/>}} mode and run
normally without that option, dumping the console logs to the ugly
{{*-jvmRun1.dumpstream}} file.
was (Author: kriegaex):
What you say is illogical. My agent does not change a single bit in any of
those classes, signified by its returning {{null}} in all cases. An agent has
no influence over when it is being called by the JVM during class-loading. This
is true for both JaCoCo and my sample agent. What makes the build hang is not
instrumentation but the client logging something to the system console in
{{<forkNode ... SurefireForkNodeFactory"/>}} mode, sorry to repeat myself.
This would happen the same if JaCoCo would log something in the same situation,
just like originally it happens with my ByteBuddy agent. It would happen with
all agents logging something during execution, such as AspectJ load-time weaver
or whatever other valid agents there are in this world. My agent is the
simplest possible agent, doing nothing but logging something. The very same
agent works when deleting the two log lines I mentioned or when not using the
brandnew {{<forkNode ... SurefireForkNodeFactory"/>}} setting. So it *is* the
combination of this Surefire setting with logging to the system console which
upsets the JVM, making is hang.
Need more proof? Fine. Just eliminate the Java agent from the equation by
changing
{code:xml}
<argLine>-javaagent:${project.build.directory}/${project.build.finalName}.jar</argLine>{code}
to simply
{code:xml}
<argLine>-verbose:class</argLine>
{code}
making the JVM log each loaded class to the system console. Optionally (not
really necessary), comment out
{{Agent.INSTRUMENTATION.retransformClasses(...);}} in {{AgentIT}} to stop the
test from failing with an exception due to the non-existent agent. The build
will again hang in {{<forkNode ... SurefireForkNodeFactory"/>}} mode and run
normally without that option, dumping the console logs to the ugly
{{*-jvmRun1.dumpstream}} file.
> 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)
