Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Java heap space issue #855

Closed
vmassol opened this issue May 17, 2017 · 23 comments
Closed

Java heap space issue #855

vmassol opened this issue May 17, 2017 · 23 comments
Labels
3rd-party: Maven Surefire
Milestone
5.0 M6

Comments

@vmassol
Copy link

vmassol commented May 17, 2017

Note: Issue created from #801

Seems using surefire 2.20 + JUnit5 is causing a java heap space issue, see https://jira.xwiki.org/browse/XCOMMONS-1189?focusedCommentId=94953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-94953

Note that running the exact same build by commenting out the following part doesn't exhibit the "Java Heap Space" issue so for some reason the junit5 provider is eating more memory. FTR I'm running with MAVEN_OPTS="-Xmx2048m -XX:MaxPermSize=196m" which is already quite substantial so it could be a memory leak somewhere.

        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <!-- Lock down plugin version for build reproducibility -->
          <version>2.20</version>
...
          <dependencies>
            <!-- Allow running both JUnit4 and JUnit5 tests -->
            <!--dependency>
              <groupId>org.junit.platform</groupId>
              <artifactId>junit-platform-surefire-provider</artifactId>
              <version>1.0.0-M4</version>
            </dependency>
            <dependency>
              <groupId>org.junit.jupiter</groupId>
              <artifactId>junit-jupiter-engine</artifactId>
              <version>${junit5.version}</version>
            </dependency>
            <dependency>
              <groupId>org.junit.vintage</groupId>
              <artifactId>junit-vintage-engine</artifactId>
              <version>4.12.0-M4</version>
            </dependency-->
          </dependencies>
        </plugin>

Thanks
@marcphilipp
Copy link
Member

Can you please post step-by-step instructions how I can reproduce this locally? Can you please take a heap dump and share it with us?

@marcphilipp marcphilipp added this to the 5.0 M5 milestone May 17, 2017
@sbrannen
Copy link
Member

Please note that junit-platform-surefire-provider:1.0.0-M4 is not supported with maven-surefire-plugin:2.20.

junit-platform-surefire-provider:1.0.0-M4 is only supported with maven-surefire-plugin:2.19.

If you want to use maven-surefire-plugin:2.20 you will then have to build against a snapshot of the junit-platform-surefire-provider -- for example, version 1.0.0-SNAPSHOT.

@shakuzen
Copy link

shakuzen commented Jun 4, 2017

@marcphilipp
Here is a small project that reproduces the (I believe) same issue: https://github.com/shakuzen/junit-surefire-heap
As the README states, just running ./mvnw test will reproduce.

This may be more of a Surefire 2.20 issue than a JUnit 5 issue*, but I personally was not able to reproduce it with JUnit 4 and Surefire 2.20.
In my reproduction example, the equivalent test in JUnit 4 works fine with the Surefire plugin 2.20 (runs with ./mvnw -Pjunit4 test).

@sbrannen changing junit-platform-surefire-provider to SNAPSHOTs (1.0.0-SNAPSHOT) results in the same "Java heap space" build error in my above linked repro project.

* I say this because the Spring Boot project - not using JUnit 5 yet - seems to have ran into this problem when attempting to upgrade to surefire 2.20, per spring-projects/spring-boot#6299 (comment)

@marcphilipp
Copy link
Member

@Tibor17 Are you aware of a memory leak in Surefire 2.20 as claimed by Spring Boot (see above)?

@Tibor17
Copy link

Tibor17 commented Jun 10, 2017

No we dont have any leak.

@vmassol
Copy link
Author

vmassol commented Jun 10, 2017

@sbrannen thanks. Yes, I'm using maven-surefire-plugin:2.20 with junit-platform-surefire-providerversion 1.0.0-SNAPSHOT (see thread #801 for details).

Similar to @shakuzen, I get the Java Heap space only with surefire 2.20 and junit-platform-surefire-providerversion 1.0.0-SNAPSHOT. I don't get it with surefire 2.19 and JUnit4 or surefire 2.20 and JUnit4.

@Tibor17
Copy link

Tibor17 commented Jun 10, 2017 via email

@vmassol
Copy link
Author

vmassol commented Jun 10, 2017

@Tibor17 I'm just trying to help you guys stabilize JUnit5 by reporting issues before you release JUnit5 as final (so that it's as stable as possible). However I don't have the time to help you debug it at this point, I'm quite busy with XWiki development itself... :) If I get some time in the future I'll sure help out more but don't wait for me.

@marcphilipp
Copy link
Member

marcphilipp commented Jun 10, 2017 •
edited

Since Spring Boot also has a problem with 2.20 (without using JUnit 5), the leak is most likely in Surefire and not in JUnit 5.

@Tibor17 Can you get in touch with Spring Boot?

@vmassol
Copy link
Author

vmassol commented Jun 10, 2017

@marcphilipp Are you sure that's what @shakuzen said? AFAICS he said:

This may be more of a Surefire 2.20 issue than a JUnit 5 issue*, but I personally was not able to reproduce it with JUnit 4 and Surefire 2.20.

So to me it's more a JUnit5 issue (at least a JUnit5 + Surefire 2.20 combination issue).

@marcphilipp
Copy link
Member

Well, Spring Boot seems to think it's Surefire: spring-projects/spring-boot#9414

@Tibor17
Copy link

Tibor17 commented Jun 10, 2017 via email

@marcphilipp
Copy link
Member

marcphilipp commented Jun 10, 2017 •
edited

Ok, I checked out @shakuzen's sample project.

Here are a couple of things I observed:

  1. The OutOfMemoryError happens in the Maven JVM, not in the forked JVM. That means that there's no memory leak in JUnit 5.
  2. In the heap dump, there's a single very large (>1GB) char array that contains the same content all over again "systemEnvironment]systemEnvironment]...". Any ideas where that might come from?
  3. Adding a very simple logback.xml file solved the [WARNING] Corrupted stdin stream in forked JVM 1. warning and the OutOfMemoryError (see https://github.com/shakuzen/junit-surefire-heap/pull/1/files). Probably because Logback disables java.util.logging.

So, (3) clearly points in the direction of logging, in particular since JUnit 5 uses java.util.logging while JUnit 4 does not.

@Tibor17 What changed in Surefire 2.20 with regard to stream handling? How can java.util.logging break it?

@shakuzen
Copy link

Just to add some information, in the dump file it contains messages like this for presumably every log message during test execution:

# Created on 2017-06-11T12:51:51.095
Corrupted stdin stream in forked JVM 1. Stream '12:51:51.094 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor''.
java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma after third character in command '12:51:51.094 [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Returning cached instance of singleton bean 'lifecycleProcessor''.
        at org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.<init>(ForkClient.java:469)
        at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:191)
        at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:158)
        at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:87)
        at java.lang.Thread.run(Thread.java:748)

@Tibor17
Copy link

Tibor17 commented Jun 11, 2017 via email

@Tibor17
Copy link

Tibor17 commented Jun 11, 2017 via email

@shakuzen
Copy link

After analyzing the heap dump, I realized there was an infinite loop in the surefire code. It looks like someone else also realized this and already fixed it in apache/maven-surefire@7176d3c which will be in surefire 2.20.1 per SUREFIRE-1382. Therefore, I believe this issue can be closed. I haven't been able to confirm because running my sample with surefire 2.21-SNAPSHOT fails for an unrelated reason I'm unable to look into now.

@vmassol
Copy link
Author

vmassol commented Jun 15, 2017

@shakuzen Thanks for posting the explanation and links! Great that it's fixed. Waiting eagerly for Surefire 2.20.1 :)

@marcphilipp
Copy link
Member

@Tibor17 When is 2.20.1 going to be released?

@marcphilipp marcphilipp modified the milestones: 5.0 M6, 5.0 M5 Jun 17, 2017
@marcphilipp marcphilipp mentioned this issue Jun 17, 2017
Closed
3 tasks
@marcphilipp
Copy link
Member

Closing in favor of #809.

@Tibor17
Copy link

Tibor17 commented Jul 10, 2017 via email

@marcphilipp
Copy link
Member

@Tibor17 Thanks for chiming in! So, will there be a 2.20.1 or do we have to wait for 2.21?

@Tibor17
Copy link

Tibor17 commented Jul 11, 2017 via email

@kazuki43zoo kazuki43zoo mentioned this issue Jul 15, 2017
Closed
@sormuras sormuras mentioned this issue Jul 17, 2017
Closed
1 task
@tushar025 tushar025 mentioned this issue Apr 26, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3rd-party: Maven Surefire
Projects
None yet
Milestone
5.0 M6
Development

No branches or pull requests
5 participants
@sbrannen @marcphilipp @vmassol @Tibor17 @shakuzen