Memory leaks in msLayerClose()

[woodbri]

Running valgrind on a C application that I wrote using mapserver.a shows the following memory leaks. I was able to reproduce this on 5.0.3 and 5.2.0-rc1:

==26531==
==26531== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==26531== malloc/free: in use at exit: 90 bytes in 9 blocks.
==26531== malloc/free: 294,249 allocs, 294,240 frees, 269,637,193 bytes allocated.
==26531== For counts of detected errors, rerun with: -v
==26531== searching for pointers to 9 not-freed blocks.
==26531== checked 6,932,464 bytes.
==26531==
==26531== 24 bytes in 3 blocks are definitely lost in loss record 2 of 3
==26531==    at 0x4A18DA3: malloc (vg_replace_malloc.c:149)
==26531==    by 0x420F21: msLayerWhichItems (maplayer.c:440)
==26531==    by 0x423A8D: msDrawVectorLayer (mapdraw.c:841)
==26531==    by 0x4236C4: msDrawLayer (mapdraw.c:738)
==26531==    by 0x4232F3: msDrawMap (mapdraw.c:441)
==26531==    by 0x40A818: main (genimages.c:1148)
==26531==
==26531==
==26531== 66 (48 direct, 18 indirect) bytes in 3 blocks are definitely lost in loss record 3 of 3
==26531==    at 0x4A1A362: calloc (vg_replace_malloc.c:279)
==26531==    by 0x420F00: msLayerWhichItems (maplayer.c:435)
==26531==    by 0x423A8D: msDrawVectorLayer (mapdraw.c:841)
==26531==    by 0x4236C4: msDrawLayer (mapdraw.c:738)
==26531==    by 0x4232F3: msDrawMap (mapdraw.c:441)
==26531==    by 0x40A818: main (genimages.c:1148)
==26531==
==26531== LEAK SUMMARY:
==26531==    definitely lost: 72 bytes in 6 blocks.
==26531==    indirectly lost: 18 bytes in 3 blocks.
==26531==      possibly lost: 0 bytes in 0 blocks.
==26531==    still reachable: 0 bytes in 0 blocks.
==26531==         suppressed: 0 bytes in 0 blocks.
==26531== Reachable blocks (those to which a pointer was found) are not shown.
==26531== To see them, rerun with: --show-reachable=yes

I have a patch to maplayer.c attached that as a possible fix for this.

[sdlime]

It's a good catch but I don't think the patch quite covers it. There's a freeExpression() function in mapfile.c that the fix could be patterned after I think. It's not quite a "free", more of a reset as we want to leave parts such as the type, string and flags intact. Plus, the layer->filter should also be cleaned up.

Can this wait until 5.2.1? I'm not real keen on mucking with this area of the code right before a release.

Steve

[woodbri]

Yeah, I thought the filter code probably had the same issue, but I wasn't running into it. I was going to mention that but forgot. I was concerned that the assumptions around this code were more complex than the patch accounted for, based on looking at the similar code for the layer->items stuff, but had no clue what all the assumptions might be.

Yeah, I suppose this can wait for 5.2.1, the leaks are causing havoc with precache2.php but I have made some hacks to speed up restarts when it crashes or has to be killed. This are annoying work-a-rounds for the moment, but I would like to get the problems fixed.

[sdlime]

This is top of the list for 5.2.1 which could be out in a week or two.

Steve

[sdlime]

I applied a slightly abbreviated version of the patch (msFree and msFreeCharArray both check their args) to the main branch. Let's try it a bit and then back port for 5.2.1 if all is well.

Steve

[dmorissette]

Closing. Sounds like this would have been fixed in 5.2.