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. _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users