#565: r.colors: glibc double free or corruption with -ae
---------------------+------------------------------------------------------
Reporter: hamish | Owner: [email protected]
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>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev