This was discovered while calling imageObj.getBytes() in java mapscript.
I will attach a patch that fixes the leak, courtesy of Tamas Szekeres.
This was discussed extensively in the mailing list thread:
leaking memory in java mapscript (was Re: thread safety)
http://www.nabble.com/thread-safety-to15514019.html
But if you're trying to follow that there, you might want to skip ahead to at
least the point at which I changed the subject line of the mailing list
thread, after I realized that my problem was not a multithreading issue, but
instead a memory leak. Skipping to here probably will suffice:
http://www.nabble.com/forum/ViewPost.jtp?post=15621043&framed=y
The leak was found on a hand compiled version of mapserver 5.0.0, with hand
compiled versions of gd 2.0.35 and agg 2.5. Both on debian 3.1 (sarge) using
gcc 3.3.5, swig 1.3.24, and Sun java 1.5.0_06:
MapServer version 5.0.0 OUTPUT=GIF OUTPUT=PNG OUTPUT=WBMP OUTPUT=SVG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=THREADS INPUT=POSTGIS INPUT=SHAPEFILE
and on debian 4.0 (etch) using gcc 4.1.2, swig 1.3.29, and Sun java 1.5.0_14:
MapServer version 5.0.0 OUTPUT=GIF OUTPUT=PNG OUTPUT=WBMP OUTPUT=SVG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=THREADS INPUT=JPEG INPUT=POSTGIS INPUT=SHAPEFILE
The leak was observed both via watching memory consumption of the java process
in top, and using valgrind (3.2.0 on sarge, 3.2.1 on etch).
The leak was present using AGG (both with and without PALETTE_FORCE), but not
present using GD. The leak was present regardless of whether the input was
from PostGIS or from *.shp files.
I have so far just tested the fix on etch, but I have no reason to believe
that the fix won't work on sarge as well.
I can attach a more complete .zip file containing all of my testcases showing
how to observe the behavior both before and after the bugfix, if that is
desired.
