[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311973#comment-17311973
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 3/31/21, 2:27 AM:
-------------------------------------------------------------------------
{quote}Debugging is useless in this case{quote}
[~tibordigana], debugging is never useless.
Can you explain to me how you got that callstack above? Whenever I press
{{Ctrl-C}}, I see absolutely nothing in {{target/surefire}}.
{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}
Of course, because only #2 makes the JVM print something to the console,
probably before Surefire has properly set up the output redirection. Like I
said, the connection to the forked VM works if that VM does not log anything
before the connection is established. That implies it is not a networking issue
as such with regard to access rights, or it would never work.
Maybe it is as simple as the forked VM trying to do
{{System.[out,err]::println}} but those streams are not writable yet, to that
call hangs and the same thread cannot do anything else meanwhile, causing the
freeze.
{quote}{{-verbose:class}} caused the method call
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}} within the
ForkedBooter to somehow freeze the forked process indefinitely. As soon I
removed this argument all went back to normal.{quote}
[~reinhapa], of course it does work on all OS's if you remove that argument.
That is what I was saying since day 1 of creating this ticket. It is the same
as making my Java agent not print anything to the console, then the Java agent
also works. If it was not about printing to the console, Surefire could never
connect to a forked child process and Java agents would never work in
connection with Surefire. Logic implies that. Guys, whether you like it or not,
it is because the forked VM prints to the console. It is the only explanation
for the behaviour in all scenarios we discussed together so far. Look at the
big picture, read the whole ticket, don't just focus on what you are trying at
the moment in isolation.
was (Author: kriegaex):
{quote}Debugging is useless in this case{quote}
[~tibordigana], debugging is never useless.
Can you explain to me how you got that callstack above? Whenever I press
{{Ctrl-C}}, I see absolutely nothing in {{target/surefire}}.
{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}
Of course, because only #2 makes the JVM print something to the console,
probably before Surefire has properly set up the output redirection. Like I
said, the connection to the forked VM works if that VM does not log anything
before the connection is established. That implies it is not a networking issue
as such with regard to access rights, or it would never work.
Maybe it is as simple as the forked VM trying to do
{{System.{out,err}::println}} but those streams are not writable yet, to that
call hangs and the same thread cannot do anything else meanwhile, causing the
freeze.
{quote}{{-verbose:class}} caused the method call
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}} within the
ForkedBooter to somehow freeze the forked process indefinitely. As soon I
removed this argument all went back to normal.{quote}
[~reinhapa], of course it does work on all OS's if you remove that argument.
That is what I was saying since day 1 of creating this ticket. It is the same
as making my Java agent not print anything to the console, then the Java agent
also works. If it was not about printing to the console, Surefire could never
connect to a forked child process and Java agents would never work in
connection with Surefire. Logic implies that. Guys, whether you like it or not,
it is because the forked VM prints to the console. It is the only explanation
for the behaviour in all scenarios we discussed together so far. Look at the
big picture, read the whole ticket, don't just focus on what you are trying at
the moment in isolation.
> 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)
