[GRASS-dev] Re: [GRASS GIS] #837: Memory leaks in r.example

[GRASS GIS]

#837: Memory leaks in r.example
----------------------+-----------------------------------------------------
  Reporter:  sprice   |       Owner:  grass-dev at 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>