[MAPSERVER-USERS] Antwort: Re: leaking memory in java mapscript (was Re: thread safety)

[rich.fromm]

Benedikt Rothe wrote:
> 
> It's easier to watch the SWIG-generated JNI-Code in 
> mapscript/java/mapscript_wrap.c 
> Example: 
>   mapscriptJNI.delete_imageObj(swigCPtr);
> is implemented by the C-function
>   SWIGEXPORT jbyteArray JNICALL 
> Java_edu_umn_gis_mapscript_mapscriptJNI_imageObj_1getBytes 
> 
>> confirm that the caller must free the returned array (with gdFree()).
> At the end of the long-named C-function you'll find a call to gdFree
> 
> Can you estimate how much memory is lost in each step of your
> testprogram? Is it approx. the size of the image?
> 

I do see the gdFree() call.  Nevertheless, just to take the SWIG version
issue
hopefully off of the table, I tried recompiling everything on debian etch
(4.0), which has a dpkg for swig 1.3.29.  I still get the leak.

Running my test for 100 iterations, it leaks approximately 30 MB.  Which is
a
little bit more than 300 KB per iteration:

(/ (* 30 1024 1024) 100)
314572

Note that this figure is approximate, since the 30 MB is just from top.

The leak is independent of the image size.  I get the same amount of leaking
with a test image of 79813 bytes and one of 30328 bytes.  If I run 200
iterations instead of 100, the amount that is leaked doubles.

I have finally been able to successfully run a single iteration in valgrind
and have it report a leak in the code:

--- begin ---
==21154== 41,600 bytes in 65 blocks are possibly lost in loss record 46 of
55
==21154==    at 0x401C6CA: calloc (vg_replace_malloc.c:279)
==21154==    by 0x42B15E3: gdCalloc (gdhelpers.c:79)
==21154==    by 0x42A4F49: gdImageCreate (gd.c:104)
==21154==    by 0x40BFEA9: msImageCreateWithPaletteGD (mapgd.c:3460)
==21154==    by 0x40C04E8: msSaveImageBufferGD (mapgd.c:3695)
==21154==    by 0x40CCD6B: msSaveImageBufferAGG (mapagg.cpp:2248)
==21154==    by 0x40A70F8: msSaveImageBuffer (maputil.c:682)
==21154==    by 0x406CB6C:
Java_edu_umn_gis_mapscript_mapscriptJNI_imageObj_1getBytes
(mapscript_wrap.c:2586)
==21154==    by 0x88614AA: ???
==21154==    by 0x885BA63: ???
==21154==    by 0x885BA63: ???
==21154==    by 0x8859218: ???
==21154== 
==21154== 
==21154== 271,588 (7,268 direct, 264,320 indirect) bytes in 1 blocks are
definitely lost in loss record 49 of 55
==21154==    at 0x401D38B: malloc (vg_replace_malloc.c:149)
==21154==    by 0x42B15AC: gdMalloc (gdhelpers.c:85)
==21154==    by 0x42A4EA4: gdImageCreate (gd.c:83)
==21154==    by 0x40BFEA9: msImageCreateWithPaletteGD (mapgd.c:3460)
==21154==    by 0x40C04E8: msSaveImageBufferGD (mapgd.c:3695)
==21154==    by 0x40CCD6B: msSaveImageBufferAGG (mapagg.cpp:2248)
==21154==    by 0x40A70F8: msSaveImageBuffer (maputil.c:682)
==21154==    by 0x406CB6C:
Java_edu_umn_gis_mapscript_mapscriptJNI_imageObj_1getBytes
(mapscript_wrap.c:2586)
==21154==    by 0x88614AA: ???
==21154==    by 0x885BA63: ???
==21154==    by 0x885BA63: ???
==21154==    by 0x8859218: ???
--- end ---

The amount reported matches up quite nicely with the amount that I'm
observing, so I'm inclined to believe the valgrind report:

(+ 271588 41600)
313188

While the memory is indeed being allocated outside of mapserver code (this
is
with gd 2.0.35):

(gd.c:104)
      im->pixels[i] = (unsigned char *) gdCalloc (sx, sizeof (unsigned
char));

(gd.c:83)
  im = (gdImage *) gdMalloc (sizeof (gdImage));

the function gdImageCreate() returns a gdImagePrt:

BGD_DECLARE(gdImagePtr) gdImageCreate (int sx, int sy)
{
  // ...
  gdImagePtr im;
  // ...
  return im;
}

to mapserver:

(mapgd.c:3460)
  img = gdImageCreate(sx, sy);

and I would assume that it is the responsibility of mapserver to free the
memory.  (Do you agree?)

Esp. since this happens to me for both test cases of different requests, I
suspect that I could create a synthetic test case independent of my postgis
data to create this, but I haven't yet done so.

I will investigate this further, I just wanted to post this update here.

- Rich

-- 
View this message in context: http://www.nabble.com/thread-safety-tp15514019p15621043.html
Sent from the Mapserver - User mailing list archive at Nabble.com.