#837: Memory leaks in r.example
----------------------+-----------------------------------------------------
Reporter: sprice | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: normal | Milestone: 6.4.0
Component: default | Version: svn-releasebranch64
Resolution: | Keywords:
Platform: MacOSX | Cpu: OSX/Intel
----------------------+-----------------------------------------------------
Comment (by glynn):
Replying to [comment:4 glynn]:
> > The third, fourth, & last leaks (in lib/gis/opencell.c) are a bit more
difficult to take care of all permutations:
>
> [snip]
>
> This is a large part of the reason why we just resign ourselves to each
map requiring a certain amount of memory. And I'd leave it at that, if it
wasn't for the null bitmap handling calling this function repeatedly.
My mistake. The null bitmap code calls G_open_old_misc(). That also leaks
memory, but it wouldn't be nearly as much trouble to fix as
G_open_cell_old().
That still leaves us with the question of whether to change G_find_*.
Returning unique allocations would allow the caller to free the returned
mapset string. We could then safely fix the significant leak in the null
bitmap handling (which is leaking memory per-row), but would add a fixed
increase in memory consumption in the case where unqualified map names are
used, at least until we modify everything which calls it (which is around
350 files).
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/837#comment:6>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
