[GRASS-dev] Re: [GRASS GIS] #565: r.colors: glibc double free or corruption with -ae

GRASS GIS trac at osgeo.org
Wed Apr 22 07:06:40 EDT 2009


#565: r.colors: glibc double free or corruption with -ae
---------------------+------------------------------------------------------
  Reporter:  hamish  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect  |      Status:  closed                   
  Priority:  minor   |   Milestone:  6.5.0                    
 Component:  Raster  |     Version:  svn-develbranch6         
Resolution:  fixed   |    Keywords:  r.colors                 
  Platform:  Linux   |         Cpu:  x86-32                   
---------------------+------------------------------------------------------
Comment (by glynn):

 Replying to [comment:6 hamish]:

 > fwiw, valgrind still reports an error, but now it is slightly different:

 > ie before it read
 {{{
 Address 0x4223EDC is 12 bytes before a block of size 4,000 alloc'd
 }}}
 >
 > now it reads
 {{{
 ... is 0 bytes after a block of size 4,000 alloc'd
 }}}
 >
 > ?

 Fencepost error. If x == statf->max, then i == statf->count, which
 overruns. The array needs to have statf->count+1 elements. Fixed in
 r36862.

 > are the min/max values really bogus? r.univar and 'r.info -r' both give
 (-23,1999) for those values. The 'max' value seen in gdb frame # 7 (ie
 7.60) is simply the natural log of the max value in the map (1999).

 Right; get_fp_stats() overwrites min/max with the log/log-abs values, and
 gdb is showing the updated values.

 So, yes, the bug was due to failing to account for the fact that log-abs
 needs to include zero in the range calculation as well as min and max.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/565#comment:8>
GRASS GIS <http://grass.osgeo.org>


More information about the grass-dev mailing list