gdImagePtr gdPImg memory leak in mapgd.c:msSaveImageBufferGD()

[richf]

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.

[richf]

mapgd.c.diff

[tamas]

I take over this.

[richf]

This is not entirely a self contained testcase, but it might be a useful reference.

[tamas]

Applied the changes in trunk r7397 and branch-5-0 r7398