[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