this bug's URL: http://intevation.de/rt/webrt?serial_num=3974
-------------------------------------------------------------------------
Subject: r.mapcalc/libgis failure with LFS enabled
Platform: GNU/Linux/x86_64
grass obtained from: CVS
grass binary for platform: Compiled from Sources
Hi,
we have discovered some severe problems in the GRASS raster map
library (within libgis) in certain cases. The problem was first
identified in August/December 2005 (see other mails). We really
need to fix it.
For a test, I have generated a XY location with 3x3 pixels
and generated a simple map:
GRASS 6.1.cvs (xy):~ > r.mapcalc "one=1"
100%
GRASS 6.1.cvs (xy):~ > r.univar one
Processing .. 100%
total null and non-null cells: 9
total null cells: 0
Of the non-null cells:
----------------------
n: 9
minimum: 99
maximum: 156
range: 57
mean: 125
standard deviation: 23.5372
variance: 554
variation coefficient: 18.8298 %
sum: 1125
GRASS 6.1.cvs (xy):~ > r.out.ascii one
north: 3
south: 0
east: 3
west: 0
rows: 3
cols: 3
120 156 99
120 156 99
120 156 99
My proposal is to add some tests to libgis/ to verify
if the data are wrongly written or read or both.
Here some tests:
* Machine: 64bit PENTIUM, RHEL4, gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
- 64bit enabled
- LFS enabled
-> above problems
* Machine: 64bit PENTIUM, RHEL4, gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
- 64bit enabled
- LFS disabled
-> maps generated *here* are read correctly
-> maps generated with LFS enabled are read wrongly (so write error with LFS enabled?)
* Machine: 32bit Mandriva2006
- LFS enabled
Here various raster modules crash with LFS enabled
(r.sun, r.mapcalc + d.rast - error reading compressed row)
Apparently something is wrong with LFS (off_t issues?).
Is anyone able to write some low level test for libgis which
will be performed during compilation (as already exists for
libvect)?
Markus
-------------------------------------------- Managed by Request Tracker