[mapserver-dev] 5.2.0 memory leaks?
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Jul 14 16:53:22 EDT 2008
Yes, these also leak in 5.0.3, I just rebuilt and tested there:
==1974== 24 bytes in 3 blocks are definitely lost in loss record 2 of 5
==1974== at 0x4A18DA3: malloc (vg_replace_malloc.c:149)
==1974== by 0x41FF61: msLayerWhichItems (maplayer.c:439)
==1974== by 0x422A2D: msDrawVectorLayer (mapdraw.c:828)
==1974== by 0x422686: msDrawLayer (mapdraw.c:722)
==1974== by 0x4222B9: msDrawMap (mapdraw.c:432)
==1974== by 0x40A405: main (genimages.c:1147)
==1974==
==1974==
==1974== 66 (48 direct, 18 indirect) bytes in 3 blocks are definitely
lost in loss record 3 of 5
==1974== at 0x4A1A362: calloc (vg_replace_malloc.c:279)
==1974== by 0x41FF40: msLayerWhichItems (maplayer.c:434)
==1974== by 0x422A2D: msDrawVectorLayer (mapdraw.c:828)
==1974== by 0x422686: msDrawLayer (mapdraw.c:722)
==1974== by 0x4222B9: msDrawMap (mapdraw.c:432)
==1974== by 0x40A405: main (genimages.c:1147)
==1974==
==1974==
These two look like they are probably trivial to fix by free'ing:
for (i=0; i<layer->numclasses; i++) {
free(layer->class[i]->expression.indexes);
free(layer->class[i]->expression.items);
}
in msLayerClose() or something like that (I am not familiar with this code).
The following one appears to be a leak in the GD library that we should
probably report so that it gets fixed. I have not tried GD-2.1-rc1 yet
to see if that solves this problem.
==1974== 864 bytes in 144 blocks are definitely lost in loss record 4 of 5
==1974== at 0x4A18DA3: malloc (vg_replace_malloc.c:149)
==1974== by 0x4B35D78: gdMalloc (in /usr/lib/libgd.so.2.0.33)
==1974== by 0x4B33830: (within /usr/lib/libgd.so.2.0.33)
==1974== by 0x4B336DB: gdImageCreatePaletteFromTrueColor (in
/usr/lib/libgd.so.2.0.33)
==1974== by 0x43277D: msImageCreateWithPaletteGD (mapgd.c:3471)
==1974== by 0x432A94: msSaveImageGDCtx (mapgd.c:3597)
==1974== by 0x4328B9: msSaveImageGD (mapgd.c:3525)
==1974== by 0x43B721: msSaveImageAGG (mapagg.cpp:2194)
==1974== by 0x4169F4: msSaveImage (maputil.c:599)
==1974== by 0x40A516: main (genimages.c:1186)
==1974==
These leaks are also very problematic to running precache2.php to
populate the ka-map tilecache. Basically you can not run it for any
large potion of the cache or it will crash. These are also problematic
for any fast-cgi processes or similar long running processes. I have
been plagued with these in the past, but this is the first that I have
been able to isolate them down to some specific cases in the code.
-Steve W
Steve Lime wrote:
> Have run against 5.0? If they're there in that version too then I'm not worried about
> this for this release. My guess is that these are not new leaks.
>
> Steve
>
>>>> On 7/13/2008 at 12:13 AM, in message <48798F14.1070801 at swoodbridge.com>,
> Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>> Steve L,
>>
>> I have been playing around with a test program to generate some images.
>> It was some mapscript that I wanted to see if I could get working as a C
>> program calling the mapserver library calls.
>>
>> This run was based on mapserver-5.2.0-beta2 and it looks like we have
>> some memory leaks in the mapserver code. It is also possible that I
>> mis-used the library, but these seem to be pretty deep in mapserver and
>> I'm not trying to do anything fancy.
>>
>> I'll check the same run against RC1, but I guess my generic question is
>> how much check has been done with valgrind. This run only generates two
>> images, but if I wanted to generate lots more this could be serious. In
>> fact, I think I've seen php/mapscript precache2.php run into a leak
>> where the process kept growing and finally died and had to be restarted.
>>
>> -Steve
>>
>>
>> ==5821== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
>> ==5821== malloc/free: in use at exit: 7,724 bytes in 29 blocks.
>> ==5821== malloc/free: 337,243 allocs, 337,214 frees, 121,668,226 bytes
>> allocated.
>> ==5821== For counts of detected errors, rerun with: -v
>> ==5821== searching for pointers to 29 not-freed blocks.
>> ==5821== checked 15,450,752 bytes.
>> ==5821==
>> ==5821== 24 bytes in 3 blocks are definitely lost in loss record 5 of 15
>> ==5821== at 0x4A18DA3: malloc (vg_replace_malloc.c:149)
>> ==5821== by 0x4276A1: msLayerWhichItems (maplayer.c:440)
>> ==5821== by 0x42A20D: msDrawVectorLayer (mapdraw.c:841)
>> ==5821== by 0x429E44: msDrawLayer (mapdraw.c:738)
>> ==5821== by 0x429A73: msDrawMap (mapdraw.c:441)
>> ==5821== by 0x40E67E: main (genimages.c:1112)
>> ==5821==
>> ==5821==
>> ==5821== 24 bytes in 4 blocks are definitely lost in loss record 6 of 15
>> ==5821== at 0x4A18DA3: malloc (vg_replace_malloc.c:149)
>> ==5821== by 0x4B35D78: gdMalloc (in /usr/lib/libgd.so.2.0.33)
>> ==5821== by 0x4B33830: (within /usr/lib/libgd.so.2.0.33)
>> ==5821== by 0x4B336DB: gdImageCreatePaletteFromTrueColor (in
>> /usr/lib/libgd.so.2.0.33)
>> ==5821== by 0x43ACED: msImageCreateWithPaletteGD (mapgd.c:3441)
>> ==5821== by 0x43B022: msSaveImageGDCtx (mapgd.c:3576)
>> ==5821== by 0x43AE2F: msSaveImageGD (mapgd.c:3495)
>> ==5821== by 0x4437A8: msSaveImageAGG (mapagg.cpp:2216)
>> ==5821== by 0x41ACB4: msSaveImage (maputil.c:657)
>> ==5821== by 0x40E6B4: main (genimages.c:1120)
>> ==5821==
>> ==5821==
>> ==5821== 66 (48 direct, 18 indirect) bytes in 3 blocks are definitely
>> lost in loss record 11 of 15
>> ==5821== at 0x4A1A362: calloc (vg_replace_malloc.c:279)
>> ==5821== by 0x427680: msLayerWhichItems (maplayer.c:435)
>> ==5821== by 0x42A20D: msDrawVectorLayer (mapdraw.c:841)
>> ==5821== by 0x429E44: msDrawLayer (mapdraw.c:738)
>> ==5821== by 0x429A73: msDrawMap (mapdraw.c:441)
>> ==5821== by 0x40E67E: main (genimages.c:1112)
>> ==5821==
>> ==5821== LEAK SUMMARY:
>> ==5821== definitely lost: 96 bytes in 10 blocks.
>> ==5821== indirectly lost: 18 bytes in 3 blocks.
>> ==5821== possibly lost: 0 bytes in 0 blocks.
>> ==5821== still reachable: 7,610 bytes in 16 blocks.
>> ==5821== suppressed: 0 bytes in 0 blocks.
>> ==5821== Reachable blocks (those to which a pointer was found) are not
>> shown.
>> ==5821== To see them, rerun with: --show-reachable=yes
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
More information about the mapserver-dev
mailing list