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_1getB
rich.fromm wrote:
>
> 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
2008/2/21, rich.fromm <[EMAIL PROTECTED]>:
>
> it's only the (unsigned char *imgbytes) from above (mapgd.c) that gets
> freed,
> leaking the original (gdImagePtr gdPImg) allocated by the gd code.
>
> At least that's my guess, still exploring further.
>
Rich,
Since gdImagePtr is a struct and a
Tamas Szekeres wrote:
>
> 2008/2/21, rich.fromm <[EMAIL PROTECTED]>:
>>
>> it's only the (unsigned char *imgbytes) from above (mapgd.c) that gets
>> freed,
>> leaking the original (gdImagePtr gdPImg) allocated by the gd code.
>>
>> At least that's my guess, still exploring further.
>>
>
> S
2008/2/22, rich.fromm <[EMAIL PROTECTED]>:
>
> The actual memory allocation happens in gdImageCreate() in gd.c, which
> returns
> gdImagePtr im.
>
> This sets gdImagePtr img in msImageCreateWithPaletteGD() in mapgd.c, which
> returns it.
>
> This then sets gdImagePtr gdPImg in msSaveImageBuffe
rich.fromm wrote:
>
> I will file a bug.
>
It's bug 2525:
http://trac.osgeo.org/mapserver/ticket/2525
Let me know if you want me to attach a complete self contained testcase.
- Rich
--
View this message in context:
http://www.nabble.com/thread-safety-tp15514019p15641420.html
Sent from the
Rich,
Thank you for your efforts, that was pretty sound :-)
I'll take over this bug and apply the fix this evening.
Best regards,
Tamas
2008/2/22, rich.fromm <[EMAIL PROTECTED]>:
>
>
> rich.fromm wrote:
> >
> > I will file a bug.
> >
>
>
> It's bug 2525:
> http://trac.osgeo.org/mapserver
Tamas Szekeres wrote:
>
> I think this might be the case. Would you try adding something like:
>
I have the following six testcases:
1) Data from PostGIS, AGG renderer, FORMATOPTION "PALETTE_FORCE=TRUE"
2) Data from PostGIS, AGG renderer, no forcing
3) Data from PostGIS, GD renderer
4) Data f
