Skip to main content
Question Protected by CommunityBot
Commonmark migration
Source Link

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.

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.

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.

format quote as quote.
Source Link
Joachim Sauer
  • 309.3k
  • 59
  • 568
  • 624
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. 

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.

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. 

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.

Added requested configuration information
Source Link
user118967
  • 5.9k
  • 9
  • 43
  • 64

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

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> 

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

So, how can I solve this problem?

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

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> 
Source Link
user118967
  • 5.9k
  • 9
  • 43
  • 64
Loading