Hello,
I strongly suspect there's a memory leak in Hudson concerning building on
slaves. It may be related to issue 3076, and certainly to
http://www.nabble.com/Possible-memory-leak-in-hudson.remoting.ExportTable-td12000299.html,
but it's not entirely the same.
We run Hudson 314 on Windows XP, with master and slaves on the same machine. I
see the same symptoms whether the slaves are started by the master or started
via jnlp.
The best numbers I have are from a week of running 313 (slaves started by
master), where I had java log GC activity to a file. Grepping "Full GC" lines
out of the log and massaging the numbers into a spreadsheet, a clear linear
growth in memory consumption is seen. From those numbers I could predict that we
would run out of heap (512M) sometime on day 24 of running.
This morning I switched to 314 (slaves start via jnlp). The first day gave
essentially flat memory curve, but it's starting to grow by the end of the day.
It's clear from dumpExportTable that each and every build leaks objects. They do
not disappear when the build ends, nor does a

/gc remove them. This
was observed on a slave ("stager", see below) with builds that where started
manually by me. No SCM or triggering involved (the builds would normally be
triggered by upstream builds).
But the week of logging GC also demonstrates that the growth in memory is the
same over the weekend and during the nights, when essentially no builds took
place. So something else is at play here; perhaps the SCM polling? We use the
Perforce plugin for that.
I have dumpExportTable dumps from all three slaves (see attached). The first
("builder") has 3 projects, all polling SCM. Builds take a long time, so it can
perform perhaps 10 builds in one day. The dump is 5428 KB. The second ("tester")
runs the unittests of 2 of the builder projects. They take even longer, so it
runs perhaps 6-7 builds in a day. Triggering is done by upstream, but SCM is
involved to sync the right files. That dump is 28K. The third ("stager") copies
artifacts from a number of builds (both from "builder" and "master") to a
staging area. That's somewhat frequent, and is only triggered by upstream
although part of the staging is done from the SCM. This dump is 36K.
Both "builder" and "tester" will regularly have 1-2 jobs in their queues at all
times.
The dumps are pretty much the same. The "builder" has these two exports
repeatedly (LOTS of them):
#3 (ref.1) : java.io.PipedInputStream@29830f
#4 (ref.1) : hudson.CloseProofOutputStream@12bde6c
The "tester" has no PipedInputStream, but only CloseProofOutputStream and a
RemoteClassLoader.
The "stager" only has CloseProofOutputStream.