OutOfMemoryError during test report generation


(kiran_anantha) #1

I get an OutOfMemoryError during test report generation. The test suite is a fairly large one and also produces a fair amount of output to stdout/stderr. I have a large JVM heap (GRADLE_OPTS=-Xmx2048m) specified but it still runs out of memory. Is there any way I can suppress the stdout/stderr in the XML report that gets generated to save on memory? I am using gradle 1.0

This is the stack trace I see:

  Caused by: java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOfRange(Arrays.java:3209)

at java.lang.String.(String.java:215)

at java.lang.StringBuffer.toString(StringBuffer.java:585)

at org.apache.tools.ant.util.StringUtils.replace(StringUtils.java:92)

at org.apache.tools.ant.util.DOMElementWriter.encodedata(DOMElementWriter.java:501)

at org.apache.tools.ant.util.DOMElementWriter.write(DOMElementWriter.java:236)

at org.apache.tools.ant.util.DOMElementWriter.write(DOMElementWriter.java:221)

at org.apache.tools.ant.util.DOMElementWriter.write(DOMElementWriter.java:174)

at org.gradle.api.internal.tasks.testing.junit.JUnitXmlReportGenerator.completed(JUnitXmlReportGenerator.java:120)

at org.gradle.api.internal.tasks.testing.results.StateTrackingTestResultProcessor.completed(StateTrackingTestResultProcessor.java:65)


(Peter Niederwieser) #2

Can you double-check that the memory settings took effect? I don’t think that writing the XML report should consume that much memory (but maybe there’s a bug lurking there). I don’t see a way to prevent stdout/stderr from being written to the report.

Usually, the more time and memory consuming part is generating the HTML report. You can disable generation of the HTML report with ‘testReport = false’.


(kiran_anantha) #3

I added a gc log (-Xloggc:gc.log) and verified that it is indeed using the 2G allocated. In fact, the last log line says that there is a full GC in progress.

Any suggestions/ideas on how I can customize the behavior so that I don’t log the stdout/stderr? Can I substitute my own JUnitXmlReportGenerator?


(Szczepan Faber) #4

Hey Kiran,

You cannot customize this behavior in any way ATM. OOME occurs in the Junit ‘xml’ reports generator which is something that the test process always does (junit tests). If you use ‘testReport = false’ then you prevent the html report to be generated, but not the xml reports.

xml reports are generated by the test process (not Gradle process) so GRADLE_OPTS should not have any effect on them. Please try to increase the heap size using the jvm args / memory settings on the test task and let us know if it helps.

Cheers!


(kiran_anantha) #5

Hi, Thanks for the suggestion. While I could increase the memory, it will only be temporary until a job pushes it over the limit again.

I began looking into the changes in Gradle 1.2 but I cannot get the test.testLogging.showStandardStreams to take effect. I created this script:

apply plugin: 'java'
apply plugin: 'eclipse'
  dependencies {
    testCompile 'junit:junit:4.8.1'
}
  test {
    testLogging {
        events "failed"
        showStandardStreams false
        showStackTraces false
        showExceptions false
    }
}

But when running my sample project, I still see the standard out and I still see it being written to the Junit xml report.

Do these flags affect the Junit XML report at all?


(Szczepan Faber) #6

Do these flags affect the Junit XML report at all?

Those flags only influence the console output, not the xml results. Do you think it’s not documented this way?

The proper solution for us is probably fixing the memory issues rather than preventing the xml from generation. If the test xmls are not generated, your CI won’t be able to render test results nor will Gradle’s html report. Is it acceptable for you?


(kiran_anantha) #7

Thanks for clarifying the behavior of the flags.

Yes, I would like to fix the memory issue as well. But I am also looking for some workarounds to keep the tests running in the meantime.


(Szczepan Faber) #8

Other than increasing the test task’s memory settings I don’t have any workarounds I’m afraid.