[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312854#comment-17312854
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 4/1/21, 6:36 AM:
------------------------------------------------------------------------
{quote}I am guessing that the CLI is too long
{quote}
CLI = command line interface? I am not sure if you mean
# the amount of information printed to {{stdOut}},
# the number of arguments on the command line or
# the length of the Java command line (number of characters).
I am assuming you mean #2 or #3. Actually, that is not the problem. Remember,
you tried different CLI arguments yesterday by yourself:
{quote}2. tried with -verbose:class and the get() method hanged.
3. tried with -verbose:gc and the build did NOT hang
4. tried with -Xmx128m and the build did NOT hang
{quote}
If the number or length of arguments was the problem, it would always hang.
Like I said many times before, the problem is that the forked VM starts logging
something
* either _when_ Surefire does not expect it
* or _what_ is logged is unexpected.
As for length or number of arguments on the command line, I am using this in
order to debug the forked VM:
{code:xml}
<argLine>-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:34567</argLine>
{code}
This works nicely and the test passes, even though it is an additional argument
and very long. So let us focus on what is really wrong here and not waste
energy on the length of the command line or the number of arguments.
*Update:* That in Tibor's test e.g. {{-verbose:gc}} did not hang is explained
easily by the fact that no GC information was logged, at least not at an
unexpected time during client-server handshake. If by chance a GC would occur
during that time, the test would hang too.
was (Author: kriegaex):
{quote} I am guessing that the CLI is too long{quote}
CLI = command line interface? I am not sure if you mean
# the amount of information printed to {{stdOut}},
# the number of arguments on the command line or
# the length of the Java command line (number of characters).
I am assuming you mean #2 or #3. Actually, that is not the problem. Remember,
you tried different CLI arguments yesterday by yourself:
{quote}
2. tried with -verbose:class and the get() method hanged.
3. tried with -verbose:gc and the build did NOT hang
4. tried with -Xmx128m and the build did NOT hang
{quote}
If the number or length of arguments was the problem, it would always hang.
Like I said many times before, the problem is that the forked VM starts logging
something
* either _when_ Surefire does not expect it
* or _what_ is logged is unexpected.
As for length or number of arguments on the command line, I am using this in
order to debug the forked VM:
{code:xml}
<argLine>-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:34567</argLine>
{code}
This works nicely and the test passes, even though it is an additional argument
and very long. So let us focus on what is really wrong here and not waste
energy on the length of the command line or the number of arguments.
*Update:* That in Tibor's test e.g. {{-verbose:gc}} did not hang is explained
easily by the fact that no GC information was logged, at least not at an
unexpected time during client-server handshake. If by change a GC would occur
during that time, the test would hang too.
> 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,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.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)
