90

My JUnit tests are failing when running them through Maven and the Surefire plugin (version information below). I see the error message:

Corrupted STDOUT by directly writing to native stream in forked JVM 4. See FAQ web page and the dump file C:\(...)\target\surefire-reports\2019-03-20T18-57-17_082-jvmRun4.dumpstream

The FAQ page points out some possible reasons but I don't see how I can use this information to start solving this problem:

Corrupted STDOUT by directly writing to native stream in forked JVM

If your tests use native library which prints to STDOUT this warning message appears because the library corrupted the channel used by the plugin in order to transmit events with test status back to Maven process. It would be even worse if you override the Java stream by System.setOut because the stream is also supposed to be corrupted but the Maven will never see the tests finished and build may hang.

This warning message appears if you use FileDescriptor.out or JVM prints GC summary.

In that case the warning is printed "Corrupted STDOUT by directly writing to native stream in forked JVM", and a dump file can be found in Reports directory.

If debug level is enabled then messages of corrupted stream appear in the console.

It refers to some native library printing out to STDOUT directly but how can I figure out which one, and even if I do, how do I deal with this issue if I need the library for my project?

It mentions "debug level" but it is unclear if this means Maven's debug level or Surefire plugin's debug level. I enabled Maven's debug but I don't see the console outputs as mentioned by the FAQ. And Surefire's debug option seems to be about pausing tests and waiting for a debugger to be connected to the process, not simply showing more information on the console.

The dump files also don't seem very helpful:

# Created on 2019-03-20T18:42:58.323
Corrupted STDOUT by directly writing to native stream in forked JVM 2. Stream 'FATAL ERROR in native method: processing of -javaagent failed'.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma after third character in command 'FATAL ERROR in native method: processing of -javaagent failed'.
    at org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.<init>(ForkClient.java:511)
    at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
    at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
    at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
    at java.base/java.lang.Thread.run(Thread.java:834)

So, how can I solve this problem?

Update: requested configuration information below.

I'm using OpenJDK 11 (Zulu distribution) on Windows 10, Maven 3.5.3, and Surefire 2.21.0 (full configuration below).

I'm running Maven from Eclipse using the "Run As..." context menu option on the pom.xml file, but obtain the same results when running it on the console.

I had never heard of JaCoco before the first comment to this question, but I see several error messages mentioning it:

[ERROR] ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was cmd.exe /X /C ""C:\Program Files\Zulu\zulu-11\bin\java" -javaagent:C:\\Users\\E26638\\.m2\\repository\\org\\jacoco\\org.jacoco.agent\\0.8.0\\org.jacoco.agent-0.8.0-runtime.jar=destfile=C:\\Users\\E26638\\git\\aic-expresso\\target\\jacoco.exec -Xms256m -Xmx1028m -jar C:\Users\E26638\AppData\Local\Temp\surefire10089630030045878403\surefirebooter8801585361488929382.jar C:\Users\E26638\AppData\Local\Temp\surefire10089630030045878403 2019-03-21T21-26-04_829-jvmRun12 surefire10858509118810158083tmp surefire_115439010304069944813tmp"
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1

This is the Surefire Maven plugin configuration:

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.21.0</version>
        <configuration>
            <skipTests>${skipUnitTests}</skipTests>
            <testFailureIgnore>false</testFailureIgnore>
            <forkCount>1.5C</forkCount>
            <reuseForks>true</reuseForks>
            <parallel>methods</parallel>
            <threadCount>4</threadCount>
            <perCoreThreadCount>true</perCoreThreadCount>
            <reportFormat>plain</reportFormat>
            <trimStackTrace>false</trimStackTrace>
            <redirectTestOutputToFile>true</redirectTestOutputToFile>
        </configuration>
    </plugin>
Community
  • 1
  • 1
user118967
  • 4,895
  • 5
  • 33
  • 54
  • 1
    First it would be helpful to have more information. Which Maven version, JDK version, Surefire Version do you use ? Are you using JaCoco ? How do you called Maven? etc. ? – khmarbaise Mar 21 '19 at 08:34
  • Thank you, @khmarbaise. I have updated the question with the information you requested. – user118967 Mar 22 '19 at 04:34
  • 2
    First upgrade the plugins to the most recent versions https://maven.apache.org/plugins/ – khmarbaise Mar 23 '19 at 12:26
  • Yep, that solved it. I updated all the plugins I was using and the problem went away (not sure which one because I updated them all at once). Thanks! – user118967 Mar 24 '19 at 06:58
  • 7
    For me updating the jacoco-maven-plugin solved this issue – tiktock Mar 25 '19 at 16:27
  • 1
    @ticktock's comment is the answer i feel for this issue. Works for me as well. Jacoco version - 0.8.4, jdk 11.0.3 – Upen Jul 17 '19 at 20:59
  • I have run into this issue and noticed that I had a hs_err_pid23210.log file in my working directory, generated by the crash. It clearly stated at the beginnig what was the problem: `# There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 158334976 bytes for committing reserved memory.` – h3f3st0 Oct 28 '19 at 09:46
  • I run into this issue once, but running again make the error disappear. Strange... – Hoàng Long Apr 06 '20 at 14:42
  • Check out this answer: https://stackoverflow.com/a/61936537/316343 – Jahan Zinedine Jul 25 '21 at 18:59

13 Answers13

114

Run in the same problem while migrating project from JAVA 8 to JAVA 11, upgrading jacoco-plugin from 0.8.1 to 0.8.4 did the job.

Analysing maven dependencies, seeing from where jacoco is pulled and then fixing the version should solve the issue.

Nemesis
  • 2,750
  • 2
  • 22
  • 20
  • 1
    I had the exact same issue. However, I was using an older version `0.7.7.201606060606`. It looks like this issue was addressed in the last release `0.8.4`. – Sylvester Loreto Sep 06 '19 at 12:46
  • Worked for me as well, thank you! I migrated a project from Java 12 to Java 13. – lilgallon Nov 06 '19 at 06:48
  • I'm not using Jacoco in the project that failed after migrating to JUnit 5, but like the other project (with Jacoco 0.8.4) staying at Surefire plugin 2.19 or 2.20 does the trick for both of them, I would not go above unless a major incompatibility with Java 17 or 21 forced me to ;-) – Werner Keil Jan 12 '20 at 16:35
  • 2
    There should not be a problem with the version 3.0.0-M5 but you should configure the plugin with – tibor17 Jul 01 '20 at 10:10
  • I have migrated from Java 8 to Java 15. This jacoco upgrade solved problem as well. – Vytautas Arminas Nov 23 '20 at 16:00
  • Using @tibor17 suggestion got my maven build stuck / hung up for good. Had to terminate my build within eclipse. I am not using Jacoco plugin.. should I add it as a dependency within surefire configuration ? this answer worked - https://stackoverflow.com/a/66647687/1354517 – Gautam Jun 15 '21 at 16:38
  • @Gautam I think you found a known issue https://github.com/apache/maven-surefire/pull/343 – tibor17 Jun 16 '21 at 13:33
34

I was running into this issue when running my Junit tests using a custom Runner. If I made any output to System.out or System.err in my custom runner or in my test class, this exact warning would show up. In my case the problem was not caused by some older Jacoco version. Updating the surefire plugin to version 2.22.2 or the more recent 3.0.0-M4 did not solve the issue.

According to the Jira issue SUREFIRE-1614, the problem will be fixed in the 3.0.0-M5 release of the maven-surefire-plugin (not released as of May 21st 2020).

Update The Maven Surefire plugin version 3.0.0-M5 has now been released. In your pom.xml you can do the following:

    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.0.0-M5</version>
      <configuration>
        <!-- Activate the use of TCP to transmit events to the plugin -->
        <forkNode implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
      </configuration>
    </plugin>

Original answer

If you cannot wait for the release of the 3.0.0-M5 plugin, you can use the "SNAPSHOT" version of the plugin. It did fix the issue for me. You have to enable some specific setting in the plugin so that the plugin uses TCP instead of the standard output/error to obtain the events raised in your tests. Configuration changes below:

In my pom.xml:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

...
  <!-- Add the repository to download the "SNAPSHOT" of maven-surefire-plugin -->
  <pluginRepositories>
    <pluginRepository>
      <id>apache.snapshots</id>
      <url>https://repository.apache.org/snapshots/</url>
    </pluginRepository>
  </pluginRepositories>

  <build>
    <pluginManagement>
      <plugins>
    ...
    <artifactId>maven-surefire-plugin</artifactId>
      <!-- Use the SNAPSHOT version -->
      <version>3.0.0-SNAPSHOT</version>
      <configuration>
        <!-- Activate the use of TCP to transmit events to the plugin -->
        <forkNode implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
      </configuration>
    </plugin>
Patrick
  • 1,458
  • 13
  • 27
  • 2
    The version `3.0.0-M5` will be released very soon. We have to finish JPMS issue. It's more and more demanding fix. – tibor17 May 24 '20 at 18:58
  • 3
    Please note that the real fix is not in SUREFIRE-1614 but in [SUREFIRE-1788](https://issues.apache.org/jira/browse/SUREFIRE-1788). Please also note that sometimes when using snapshot or RC1 version (which is getting updated sometimes, not a fixed version), the build is hanging, so there must be another issue which hopefully gets fixed before M5. – kriegaex Jun 02 '20 at 06:23
  • 1
    there a typo - s/b forkMode, not forkNode in – Sasha Bond Mar 03 '21 at 21:10
  • Thanks you for the careful proofing @Sasha. However I think you are mistaken in this instance. `forkMode` and `forNode` are two different settings for the surefire and failsafe plugins. `forkMode` allows you to [choose if and how tests are executed in parallel](https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html) while the `forkNode` which is discussed in my answer relates to how the Surefire plugin communicates with forked JVM in which the tests are running. – Patrick Mar 04 '21 at 06:06
  • Speaking of typos, I just noticed there is one in my comment just above. It should read "forkNode", not "forNode". Unfortunately it is too late to fix it XD. – Patrick Mar 04 '21 at 09:54
  • Thanks @Patrick, I see why I made that comment - it does not allow me to use SNAPSHOT version for the artifact, so i put latest available 2.22.2 and with that forkNode is not permitted but forkMode is – Sasha Bond Mar 08 '21 at 23:02
  • @Sasha That makes sense. The `forkNode` configuration was introduced in the more recent versions. But you realize that you do not need to use the SNAPSHOT version anymore? You can use the "3.0.0-M5" version which was released in June 2020? Maybe this is not a possibility for your particular constraints? – Patrick Mar 10 '21 at 03:38
  • Thanks for this. For me it was the missing forkNode element. – Maritim Apr 24 '22 at 11:00
  • 1
    I am using 3.0.0-M6 and ran into this today. Not Jacoco, but the JDK's HTTP client doing the writing in this case. – Tim Boudreau May 05 '22 at 20:54
21

For me it was updating the failsafe plugin from 2.22.0 to 2.22.2

Petar Tahchiev
  • 4,336
  • 4
  • 35
  • 48
  • 2
    Helped me to. Here's a link to bug that caused `STDOUT` issue: [SUREFIRE-1614](https://issues.apache.org/jira/browse/SUREFIRE-1614) – jarst Mar 03 '20 at 14:06
  • This was also the solution for me. Java 11, macOS 10.14.5. – synkarius Mar 12 '20 at 15:36
9

If you are unable to upgrade to the latest JaCoCo version, I was also able to fix this for my project by setting forkCount to 0:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.22.0</version>
  <configuration>
    <forkCount>0</forkCount>
  </configuration>
</plugin>
Matthew Read
  • 1,365
  • 1
  • 30
  • 50
5

We are using log4j backend and could also fix it using follow set to true.

<Appenders>
    <Console name="Console" target="SYSTEM_OUT">
        <PatternLayout pattern="${messagePattern}" />
        <follow>true</follow>
    </Console>
</Appenders>

(We had the same error message but without jacoco being involved. But I can confirm that setting the forkNode in maven-surefire-plugin to TCP did also work.)

Benjamin Peter
  • 4,009
  • 2
  • 23
  • 23
1

None of the listed answers helped in our case. The issue began after we've upgraded from Java 8 to Java 11.

Note: updating Surefire plugin was not possible in our case since it has broken some mechanisms the tests in our projects rely on - inspecting the issue took too long so we started identifying the root cause in Jacoco for that behaviour.

After some debugging and JVM dumps we found the cause: in our case we had JavaFX dependencies on the classpath which were loaded automatically by a resolver util. Loading these classes with jacoco enabled led to the JVM crash (without jacoco - encapsulated in a profile "coverage" in our case - did run fine). Excluding the loading of classes from JavaFX libraries (were not needed in our case) fixed the issue. Tests are running fine now without JVM crashs.

The exact class that led to the JVM crash (or at least the last that were loaded before) was in our case: com.sun.javafx.logging.jfr.JFRPulsePhaseEvent Jar: javafx-base-12-win.jar

Hint: in many IDEs you can debug the Maven build with specific profile and check what is going on exactly.

Using Jacoco 0.8.6 and Surefire plugin 2.22.2

Marco
  • 31
  • 4
1

We faced the same problem (OpenJDK 64-Bit Server VM Temurin-11.0.17+8 (11.0.17+8, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)). We already had a jacoco-plugin version of 0.8.5. A downgrade to 0.8.4 did not help. We dug deepter into the dump file and it (i.e., the gitlab runner) spit out:

Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream '# /builds/mygroup/myproject/hs_err_pid114.log'.

In that file we discovered

Internal Error (sharedRuntime.cpp:1262), pid=114, tid=115 guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method

... which lead to this bug issue: https://bugs.openjdk.org/browse/JDK-6776659

The issue should be fixed in Java 16. Upgrading at this point was not possible. Luckily, the thread creator provided a workaround:

CUSTOMER SUBMITTED WORKAROUND : -Xint or -server

As we were running a maven docker image in the gitlab runner, we had to set the forkCount to 0 in the maven surefire plugin configuration:

<configuration>
  <forkCount>0</forkCount>
</configuration>

That solved the VM crash. Unfortunately, we also had a testcoverage check (JaCoCo) and that was no longer working, as the surefire plugin created a separate VM for e.g., test classes instrumentatlization.

target/site/jacoco/jacoco.csv: No such file or directory

Finally, we had to use the argLine configuration of surefire (2, 3)

<configuration>
  <argLine>-Xint ${argLine}</argLine>
</configuration>

.. and it worked.

Manuel
  • 3,828
  • 6
  • 33
  • 48
0

What solved it for me is upgrading maven surefire plugin to 2.22.2

jhas
  • 587
  • 6
  • 8
0

For me it was upgrading org.testng to the latest version (7.3.0)

seinecle
  • 10,118
  • 14
  • 61
  • 120
0

This issue happens to me too at random

I'm using

IntelliJ IDEA 2020 (Community Edition)
Surefire plugin (3.0.0-M5)
Maven 3.3.9
AdoptOpenJDK 11

And when it happens usually Windows 10 after several minutes shows a beautiful blue screen of death.

And then after a restart everything goes back to normal

miroana
  • 494
  • 3
  • 22
  • 3
    wow, that's incredible. I am a developer of Surefire. Blue screen can be related to Windows or JDK. Maybe we would know more after seen the dump files located in target/surefire-reports. Can you show me these files? – tibor17 May 02 '21 at 21:24
0

In my case I moved my development to a new PC and didn't have all our company library-dependencies in my Maven-repo yet. So when Maven ran there was such a library missing and I had to install it with mvn install:install-file ....

Therefore, it's important to read the latest surefire-logs as it suggests those things.

No idea, why the surefire-plugin doesn't just print that conflicting line on STDOUT to the console, so it would be obvious in less than a second.

sjngm
  • 12,423
  • 14
  • 84
  • 114
-1

I was getting this error when running Maven build in Intelij Idea. I had a couple of projects open in separate windows and had other strange errors in a different project.

Solved for me by closing all the Intellij Idea windows and re-opening the project. No dependencies versions were changed.

havryliuk
  • 136
  • 1
  • 11
  • This indeed solved it for me right now just another time when I tried to increase the memory used by Intellij IDEA and had to restart to put this into effect. – havryliuk May 20 '21 at 10:54
-3

The newer Surefire plugin versions are completely buggy and broken. for me (tested all the way up to Java 12) the only solution was to stick with 2.20.

Don't use 2.20.1 either, that failed with a NPE, although maybe it is specific to particular tests, but I don't have time to investigate that.

Werner Keil
  • 592
  • 5
  • 12
  • 2
    Maybe just create an issue at jira. If you have public code, that would help as well. – Benjamin Marwell Jan 16 '20 at 18:53
  • The problem is, the Surefire project page already mentioned it but it's totally fuzzy and so is the dump when it crashes. – Werner Keil Jan 17 '20 at 19:19
  • 2
    Werner, if you do not create an issue it will never get fixed. Maybe your case is different, how could the surefire team know if you do not provide additional information? – Benjamin Marwell Jan 19 '20 at 09:45