[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311058#comment-17311058
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 3/30/21, 2:10 AM:
-------------------------------------------------------------------------
[~tibordigana], are you just being stubborn now or simply not reading my
messages carefully, even though I keep repeating myself?
* Failsafe hangs, at least on Windows, like Patrick said.
* This happens even if you (*r)*completely deactivate the agent(*r)* on the
command line in favour of a JVM option just logging loaded classes:
{{<argLine>-verbose:class</argLine>}}
* You keep obsessing about the agent, claiming there is a problem in the agent
instead of just running the tests without it, like I advised you to. It also
seems to me that you refuse to believe me that even if you use the agent (which
is not necessary to reproduce the error, like I said),
** my agent does not "reload" any classes (there is no concept of reloading
classes in the same classloader in Java),
** it just prints information on the console and
** you can completely disable the sample retransform call (which would make
the transformer do nothing else but print a log line again) in the test. *It
still hangs!!!*
Now I would be very much obliged if you started doing your part of the job (I
certainly did my part and more than that), trying to debug this problem instead
of refusing to do so, claiming the agent is the problem, even not calling it
not a "real agent" because it does not use a class name filter. If that was the
problem, how do you explain that even *without the agent* the JVM hangs? I am
really getting angry now. I provided so much information, which you just keep
dismissing. Comparing my agent to JaCoCo without knowing how agents work is not
helping either.
As for what "real agents" do: An agent cannot influence which classes the JVM
loads, only decide to either modify the byte code or not. The latter is done by
returning {{null}} from the {{transform(..)}} method, which my sample agent
does for every single class. JaCoCo does exactly the same for classes it is not
interested in instrumenting. So again, please just stop obsessing about agents,
run the test *without the agent* (I can repeat it 5 more times if it helps). I
explained in detail what to modify in order to achieve that.
Patrick even reproduced the problem in a GitHub Actions CI environment and you
say "that's nice, but it does not help"??? How jaded can anyone be if their
users are providing so much information? I even debugged it up to the exact
line in your source code where the hang occurs.
Oh, and by the way, I built the latest master and the test is not run on my
machine. M6-SNAPSHOT hangs at the exact same line of code as M5.
was (Author: kriegaex):
[~tibordigana], are you just being stubborn now or simply not reading my
messages carefully, even though I keep repeating myself?
* Failsafe hangs, at least on Windows, like Patrick said.
* This happens even if you (*r)*completely deactivate the agent(*r)* on the
command line in favour of a JVM option just logging loaded classes:
{{<argLine>-verbose:class</argLine>}}
* You keep obsessing about the agent, claiming there is a problem in the agent
instead of just running the tests without it, like I advised you to. It also
seems to me that you refuse to believe me that even if you use the agent (which
is not necessary to reproduce the error, like I said),
** my agent does not "reload" any classes (there is no concept of reloading
classes in the same classloader in Java),
** it just prints information on the console and
** you can completely disable the sample retransform call (which would make
the transformer do nothing else but print a log line again) in the test. *It
still hangs!!!*
Now I would be very much obliged if you started doing your job, trying to debug
this problem instead of refusing to do so, claiming the agent is the problem,
even not calling it not a "real agent" because it does not use a class name
filter. If that was the problem, how do you explain that even *without the
agent* the JVM hangs? I am really getting angry now. I provided so much
information, which you just keep dismissing. Comparing my agent to JaCoCo
without knowing how agents work is not helping either.
As for what "real agents" do: An agent cannot influence which classes the JVM
loads, only decide to either modify the byte code or not. The latter is done by
returning {{null}} from the {{transform(..)}} method, which my sample agent
does for every single class. JaCoCo does exactly the same for classes it is not
interested in instrumenting. So again, please just stop obsessing about agents,
run the test *without the agent* (I can repeat it 5 more times if it helps). I
explained in detail what to modify in order to achieve that.
Patrick even reproduced the problem in a GitHub Actions CI environment and you
say "that's nice, but it does not help"??? How jaded can anyone be if their
users are providing so much information? I even debugged it up to the exact
line in your source code where the hang occurs.
Oh, and by the way, I built the latest master and the test is not run on my
machine. M6-SNAPSHOT hangs at the exact same line of code as M5.
> 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
> Assignee: Tibor Digana
> Priority: Major
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> maven-failsafe-debug-log.txt, screenshot-1.png
>
>
> 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)
