[
https://jira.codehaus.org/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364705#comment-364705
]
Andreas Gudian commented on SUREFIRE-1147:
------------------------------------------
What we could do is that if all reporters are set to off / brief (i.e. no stack
trace) and test output is redirected to file and (!) rerunFailingTestCount=0,
we could make sure that nothing is handed to the deferred output streams, no
stack traces are stored, and not details are stored for the individual test
runs. In summary: don't hold stuff that is not actually read after the test
suite finished.
But I'm not sure if it's really worth all the hacks, given that you get an only
marginally meaningful output.
A simple restructuring of the tests to not perform such a huge amount of tests,
but to do the repetitions within only a few test methods would solve all (!)
the problems - be it within an IDE, within Maven or within most other test
execution frameworks. With surefire, you could even go ahead and dump a whole
lot of output to stdout, without ending up OOM. Your disk may be full at some
point, though.
> Huge memory leak noticeable when running MANY tests
> ---------------------------------------------------
>
> Key: SUREFIRE-1147
> URL: https://jira.codehaus.org/browse/SUREFIRE-1147
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.18.1
> Environment: win7, jdk 8u25, mvn 3.2.5
> Reporter: Laurent Claisse
> Attachments: surefire-allocation-traces.png, surefire-leak2.png,
> surefire-leak3.png, surefire-leak.png
>
>
> I'm writing concurrency tests, checking that this thing is reproducible, that
> other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to
> reproduce the leak, the test project is here:
> https://github.com/vandekeiser/parallel-stream-fork-join-pool)
> I see in VisualVM that the culprit is WrappedReportEntry, which indirectly
> holds references to lots of byte[] and char[] (allocation traces and heap
> dump pics are included in attachment)
> I forked and patched maven-surefire-common, and that makes the leak go. I had
> to replace WrappedReportEntry.original by a singleton fake ReportEntry.
> Bebefore that i had replaced
> Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a
> NullOutputStream and the leak was lesser but still here.
> My fork of maven-surefire-common is there:
> https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common.
> It IS a patch so i checked the patch checkbox in the issue reporter, but it
> is NOT intended to be distributed of course since it is very brutal and basic.
> Also in my test project i explicitly deactivated reporting, but that doesn't
> make the reporting leak go away at all:
> <disableXmlReport>true</disableXmlReport>
> <printSummary>false</printSummary>
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
