[GRASS5] [bug #3974] (grass) r.mapcalc/libgis failure with LFS enabled

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

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=3974
-------------------------------------------------------------------------

Subject: r.mapcalc/libgis failure with LFS enabled

One thing which I note about the implemention of LFS in GRASS is that
it works by defining the macros in config.h.

Consequently, every file which uses off_t must include config.h before
including any other headers. Otherwise, you will have different source
files assuming different sizes for off_t.

Historically, files have typically only included config.h if they need
to explicitly use a specific macro which it defines.

In adding the _FILE_OFFSET_BITS setting to config.h, you need to
re-evaluate the set of files which need to include config.h.

If I intended to enable LFS globally, I would have done so by adding
-D_FILE_OFFSET_BITS=64 to the compiler flags in Grass.make. That
guarantees that the same settings will be used throughout.

--
Glynn Clements <glynn@gclements.plus.com>