Opened 13 years ago

Closed 13 years ago

#3829 closed defect (fixed)

memory leak in msFreeLabelCacheSlot

Reported by: tbonfort Owned by: sdlime
Priority: normal Milestone: 6.0 release
Component: MapServer C Library Version: svn-trunk (development)
Severity: normal Keywords:
Cc: aboudreault, dmorissette

Description

this is rendering a label with a simple background (with the new STYLE->GEOMTRANSFORM mechanism), I'm getting this output from valgrind:

==14286== HEAP SUMMARY:
==14286==     in use at exit: 610 bytes in 3 blocks
==14286==   total heap usage: 4,130 allocs, 4,127 frees, 1,144,423 bytes allocated
==14286== 
==14286== 10 bytes in 1 blocks are indirectly lost in loss record 1 of 3
==14286==    at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==14286==    by 0xBDACB81: strdup (strdup.c:43)
==14286==    by 0x4A6755: msCopyStyle (mapcopy.c:422)
==14286==    by 0x4A5C8F: msCopyLabel (mapcopy.c:322)
==14286==    by 0x46D98C: msAddLabel (maplabel.c:394)
==14286==    by 0x48F550: msDrawShape (mapdraw.c:1798)
==14286==    by 0x48ADC4: msDrawVectorLayer (mapdraw.c:949)
==14286==    by 0x48A010: msDrawLayer (mapdraw.c:730)
==14286==    by 0x489193: msDrawMap (mapdraw.c:422)
==14286==    by 0x44255E: main (shp2img.c:299)
==14286== 
==14286== 568 bytes in 1 blocks are indirectly lost in loss record 2 of 3
==14286==    at 0x4C27480: calloc (vg_replace_malloc.c:467)
==14286==    by 0x44EE65: msGrowLabelStyles (mapfile.c:2916)
==14286==    by 0x4A5BF1: msCopyLabel (mapcopy.c:316)
==14286==    by 0x46D98C: msAddLabel (maplabel.c:394)
==14286==    by 0x48F550: msDrawShape (mapdraw.c:1798)
==14286==    by 0x48ADC4: msDrawVectorLayer (mapdraw.c:949)
==14286==    by 0x48A010: msDrawLayer (mapdraw.c:730)
==14286==    by 0x489193: msDrawMap (mapdraw.c:422)
==14286==    by 0x44255E: main (shp2img.c:299)
==14286== 
==14286== 610 (32 direct, 578 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==14286==    at 0x4C2815C: malloc (vg_replace_malloc.c:236)
==14286==    by 0x4C281D6: realloc (vg_replace_malloc.c:525)
==14286==    by 0x44ED64: msGrowLabelStyles (mapfile.c:2904)
==14286==    by 0x4A5BF1: msCopyLabel (mapcopy.c:316)
==14286==    by 0x46D98C: msAddLabel (maplabel.c:394)
==14286==    by 0x48F550: msDrawShape (mapdraw.c:1798)
==14286==    by 0x48ADC4: msDrawVectorLayer (mapdraw.c:949)
==14286==    by 0x48A010: msDrawLayer (mapdraw.c:730)
==14286==    by 0x489193: msDrawMap (mapdraw.c:422)
==14286==    by 0x44255E: main (shp2img.c:299)
==14286== 
==14286== LEAK SUMMARY:
==14286==    definitely lost: 32 bytes in 1 blocks
==14286==    indirectly lost: 578 bytes in 2 blocks
==14286==      possibly lost: 0 bytes in 0 blocks
==14286==    still reachable: 0 bytes in 0 blocks
==14286==         suppressed: 0 bytes in 0 blocks
==14286== 
==14286== For counts of detected and suppressed errors, rerun with: -v
==14286== Use --track-origins=yes to see where uninitialised values come from
==14286== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 16 from 6)

Change History (4)

comment:1 by tbonfort, 13 years ago

Basically, msFreeLabelCacheSlot() does not call freeLabel on its cacheslot->labels[i].label, which seems like an error

The following patch suppresses the error, but I'm hesitant to commit it as it may have side effects I am not aware of.

Index: mapfile.c
===================================================================
--- mapfile.c	(revision 11536)
+++ mapfile.c	(working copy)
@@ -5128,8 +5128,7 @@
       msFree(cacheslot->labels[i].text);
       if (cacheslot->labels[i].labelpath)
         msFreeLabelPathObj(cacheslot->labels[i].labelpath);
-      if( cacheslot->labels[i].label.font != NULL )
-          msFree( cacheslot->labels[i].label.font );
+      freeLabel(&(cacheslot->labels[i].label));
       msFreeShape(cacheslot->labels[i].poly); /* empties the shape */
       msFree(cacheslot->labels[i].poly); /* free's the pointer */
       for(j=0;j<cacheslot->labels[i].numstyles; j++) freeStyle(&(cacheslot->labels[i].styles[j]));

comment:2 by sdlime, 13 years ago

Cc: aboudreault dmorissette added

Adding Daniel and Alan for comment. I think the cache is full of label copies so this would be an ok patch.

Steve

comment:3 by aboudreault, 13 years ago

Checking the function msAddLabel in maplabel.c, the cache is effectively full of label copies. +1 to commit that patch thomas.

comment:4 by tbonfort, 13 years ago

Resolution: fixed
Status: newclosed

committed in r11548

Note: See TracTickets for help on using tickets.