Opened 20 years ago
Closed 17 years ago
#660 closed defect (worksforme)
Tileindex memory leaks in raster code
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL Support | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
Running a simple raster map with a tile index reports the following memory leak (and others not shown here) using valgrind: ==17403== 4 bytes in 1 blocks are definitely lost in loss record 1 of 20 ==17403== at 0x400268D5: malloc (vg_replace_malloc.c:160) ==17403== by 0x80A3D35: msDBFGetValueList (mapxbase.c:831) ==17403== by 0x806D449: msLayerNextShape (maplayer.c:289) ==17403== by 0x80B9841: msDrawRasterLayerLow (mapraster.c:1486) ==17403== by 0x807201A: msDrawRasterLayer (mapdraw.c:930) ==17403== by 0x80708B3: msDrawLayer (mapdraw.c:581) ==17403== by 0x806FB2B: msDrawMap (mapdraw.c:295) ==17403== by 0x804EA81: main (shp2img.c:159) The problem seems to be that msDrawRasterLayerLow() reused the shapeObj, but the code in msLayerNextShape() does not try to clear old "values" lists off the shapeObj passed in before assigning a new one in this bit of code: shape->values = values; shape->numvalues = layer->numitems; Should the msDrawRasterLayerLow() be calling msFreeShape() each time through the loop, instead of just at the end? I believe this problem exists in the 4.2 branch as well as the development tree.
Change History (4)
comment:1 by , 20 years ago
Cc: | added |
---|---|
Status: | new → assigned |
comment:3 by , 20 years ago
I guess I had forgotten it was an issue in 4.2 as well. I don't think it would be wise to try and change this in 4.2 at this point as it has a high risk of introducing bugs. It might be wise to fix in 4.2 release for a 4.2.1 if there will be one.
comment:4 by , 17 years ago
Description: | modified (diff) |
---|---|
Priority: | high → normal |
Resolution: | → worksforme |
Status: | assigned → closed |
I have run valgrind on shp2img on the msautotest/gdal/tileindex.map map, and it does not show this memory leak. I believe it was resolved some time ago.
Closing.
Note:
See TracTickets
for help on using tickets.