Our situation: We do have a product build from 80+ modules. Each module has its own buildscript, which is called from a master buildscript. The module build scripts define custom tasks, which make use of thirdparty libraries, for example Dom4J. Now, since we introduced those custom tasks, we get OutOfMemoryErrors somewhere in the build process, even if we give it incredible amounts of memory (1 GB, for example). We don't get this error when putting dom4j.jar into the Ant classpath, so this is a workaround for now. It isn't acceptable for the long term though, as we plan to use even more custom tasks which might use other thirdparty libraries and have to maintain several Ant installations, so this would represent too big a maintenance burden. ---- Reproducing the problem: The attached zipfile contains four files to reproduce the problem: - a minimal custom task using Dom4J - a minimal test.xml that is loaded by the custom task using Dom4J - a subbuild.xml which defines the task and calls it - a build.xml which simply calls subbuild.xml a huge amount of times * compile DummyTask.java * update the classpath definition in subbuild.xml to your local environment * run build.xml using Ant 1.6.2, JDK 1.4.2, without having dom4j.jar in the classpath, giving it 2MB of heap (-mx2m). After some time, you get an OutOfMemoryError * try the same with dom4j.jar in the Ant classpath. You don't get the error. ---- Analysis: Adding some debug statements to AntClassLoader and running Ant in JProfiler, it becomes obvious that neither the AntClassLoader, nor the Dom4J classes used for loading and executing the custom task ever get garbage collected. Those classes build up in memory until it comes to the OutOfMemoryError.
Created attachment 13979 [details] files needed to reproduce the problem Files needed for following the instructions in the initial bug report to reproduce the problems.
Hmm, we had a memory leak which was fixed before Ant 1.6.2 <http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/AntClassLoader.java?r1=1.76.2.6&r2=1.76.2.7> Testing with CVS HEAD I can see the memory usage grow as you describe.
I hit the same problem, as the unit tests I run involve repeated calls to a target in another build file. The workaround I implemented was to set ANT_OPTS=-XX:+AggressiveHeap According to Sun, this should only be helpful on multiprocessor machines, as it uses multiple GC threads, but the single CPU hyperthreaded machine on which I build seems able to take advantage of it. Not really a fix, but hopefully someone will find this useful.
Ilja, can you confirm that setting -XX,+AggressiveHeap works for you as well?
Using task/type def in child projects is always problematic. You could try to rearrange the build file to get the taskdef done in the master build file.
I also get OutOfMemoryError, but with a empty execute method. The memory footprint for the ant java process increases 3 times.
Thanks for the build file, it was a *big* help in tracking down this bug. With the fix, I can now call <ant antfile="subbuild.xml"/> 10,000 times without oome. <target name="loop"> <ac:for param="ignore" end="10000"> <sequential> <ant antfile="subbuild.xml" /> </sequential> </ac:for> </target> *** This bug has been marked as a duplicate of 28283 ***