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

[rich.fromm]

Tamas Szekeres wrote:
> 
> 2008/2/21, rich.fromm <nospam420 at yahoo.com>:
>>
>>  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.
>>
> 
> Since gdImagePtr is a struct and allocated on the stack, it will be
> freed when it goes out of the actual scope.
> 

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 msSaveImageBufferGD() in mapgd.c.  This
value is NOT directly returned.  Instead, it is used to set unsigned char
*imgbytes, and that is returned.

The fact that all of these:

  gdImagePtr im      in  gdImageCreate()               in  gd.c
  gdImagePtr img     in  msImageCreateWithPaletteGD()  in  mapgd.c
  gdImagePtr gdPImg  in  msSaveImageBufferGD()         in  mapgd.c

are all local to the stacks of their respective functions is I think
irrelevant.  A gdImagePtr is a pointer.  From gd.h:

  typedef gdImage *gdImagePtr;

If the pointer goes out of scope and the memory to which it points has not
been freed, that's a memory leak.


Tamas Szekeres wrote:
> 
>>  Perhaps I should try to recreate this as a self contained test case, and
>>  then
>>  I could file a bug.
>>
> 
> I think that would be pretty useful.
> 

I have been able to replicate the leak with synthetic data.  Valgrind
reports
it, and by iterating repeatedly in my test code I can easily see it as well.

I am in the process of trying to pare down the case to see what does or does
not matter for the leak (e.g. forced pallette, postgis vs. shp file, gd
vs. agg).  Once I am done with this I will package it up to file as a bug
report.


Tamas Szekeres wrote:
> 
> BTW: I don't really understand your valgrind output. Maybe you have 2
> different versions of the gd library out there side by side. The
> mapserver core and the mapscript wrapper may use different gd (or crt)
> libraries therefore using gdFree doesn't actually free the memory
> segment passed by the argument. (I guess)
> 

(mapgd.c:3460) calls gdImageCreate() in gd.c.  

There are three different memory allocations within that function.  Line
numbers are from gd 2.0.35:


 83:  im = (gdImage *) gdMalloc (sizeof (gdImage));

 90:  im->pixels = (unsigned char **) gdMalloc (sizeof (unsigned char *) *
sy);

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

I can easily see how if one of these is leaking than all could be leaking.
Valgrind is reporting two different stack traces for two different leaks,
those at lines 83 and lines 104.  But it's presumably the same single thread
of execution for both.

I don't know why valgrind is not reporting the case at line 90.  Perhaps
it's
not really being leaked somehow, but I suspect that it's just a deficiency
in
valgrind that it's not finding it.  And it's only a single byte, so it's not
likely to be noticeable in my approximate leak size comparisons anyway.

I'll reply again when I have a concise reproducible test case to file.

- Rich

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