[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280734#comment-17280734
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:45 AM:
------------------------------------------------------------------------
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
was (Author: kriegaex):
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
Edit: Here is a Maven log file I with debug logging activated (see attachment)
{code:none}
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit4\3.0.0-M5\common-junit4-3.0.0-M5.jar
[DEBUG] boot(compact) classpath: surefire-booter-3.0.0-M5.jar
surefire-api-3.0.0-M5.jar surefire-logger-api-3.0.0-M5.jar
surefire-shared-utils-3.0.0-M4.jar surefire-extensions-spi-3.0.0-M5.jar
test-classes surefire-print-console-problems-1.0-SNAPSHOT.jar
junit-4.13.1.jar hamcrest-core-1.3.jar surefire-junit4-3.0.0-M5.jar
common-java5-3.0.0-M5.jar common-junit3-3.0.0-M5.jar
common-junit4-3.0.0-M5.jar
[DEBUG] Forking command line: cmd.exe /X /C ""C:\Program
Files\Java\jdk-15.0.2\bin\java"
-javaagent:C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
-jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876\surefirebooter561074834657146383.jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876
2021-02-08T10-38-32_566-jvmRun1 surefire10506462700469984517tmp
surefire_014028304743446008368tmp"
{code}
> 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: 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)
