[GRASS5] raster category confusion

Hi,

the more I look into the problems of r.average and friends,
the more confused I get.

Simple test (Spearfish):

g.region n=4925010 s=4924770 w=598380 e=598740 nsres=120 ewres=90 -p
r.mapcalc "one=1"

r.info -t one
datatype=CELL

cd spearfish60/neteler/cats
cat one
# 1 categories

0.00 0.00 0.00 0.00

r.cats one
Reading one in neteler ... 100%
99
100
120
156

r.stats -1 one
120
156
99
100
120
156
99
100

r.report one
...
| #|description |
|-----------------------------------------------------------------------------|
| 99| |
|100| |
|120| |
|156| |

I am not convinced... Some initialization bug in libgis?

Markus

Markus Neteler wrote:

the more I look into the problems of r.average and friends,
the more confused I get.

Simple test (Spearfish):

g.region n=4925010 s=4924770 w=598380 e=598740 nsres=120 ewres=90 -p
r.mapcalc "one=1"

r.info -t one
datatype=CELL

What do you get without -t?

r.stats -1 one
120
156
99
100
120
156
99
100

That's at odds with the "r.mapcalc one=1", and shouldn't have anything
to do with categories.

Do you have some other mapset in the search path ahead of the current
mapset?

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

On Mon, Aug 29, 2005 at 09:13:44PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> the more I look into the problems of r.average and friends,
> the more confused I get.
>
> Simple test (Spearfish):
>
> g.region n=4925010 s=4924770 w=598380 e=598740 nsres=120 ewres=90 -p
> r.mapcalc "one=1"
>
> r.info -t one
> datatype=CELL

What do you get without -t?

I get this:

GRASS 6.1.cvs (spearfish60):~/grass61/scripts/v.rast.stats > r.info one
+----------------------------------------------------------------------------+
| Layer: one Date: Mon Aug 29 15:32:38 2005 |
| Mapset: neteler Login of Creator: neteler |
| Location: spearfish60 |
| DataBase: /ssi0/ssi/neteler/grassdata |
| Title: ( one ) |
|----------------------------------------------------------------------------|
| |
| Type of Map: cell Number of Categories: 1 |
| Data Type: CELL |
| Rows: 2 |
| Columns: 4 |
| Total Cells: 8 |
| Projection: UTM (zone 13) |
| N: 4925010 S: 4924770 Res: 120 |
| E: 598740 W: 598380 Res: 90 |
| Range of data: min = 1 max = 1 |
| |
| Data Source: |
| |
| |
| |
| Data Description: |
| generated by r.mapcalc |
| |
| Comments: |
| 1 |
| |
+----------------------------------------------------------------------------+

GRASS 6.1.cvs (spearfish60):~/grass61/scripts/v.rast.stats > g.gisenv
GISDBASE=/ssi0/ssi/neteler/grassdata
LOCATION_NAME=spearfish60
MAPSET=neteler
GRASS_DB_ENCODING=utf-8
DEBUG=0
MONITOR=x0
GRASS_GUI=text

GRASS 6.1.cvs (spearfish60):~/grass61/scripts/v.rast.stats > locate one| grep spearfish60
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cell/one
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cell_misc/one
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cell_misc/one/null
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cell_misc/one/range
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cell_misc/one
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/hist/one
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cellhd/one
/hardmnt/thuille0/ssi/grassdata/spearfish60/neteler/cats/one

GRASS 6.1.cvs (spearfish60):/hardmnt/thuille0/ssi/grassdata/spearfish60 > find . -name one
./neteler/cell/one
./neteler/cell_misc/one
./neteler/hist/one
./neteler/cellhd/one
./neteler/cats/one

> r.stats -1 one
> 120
> 156
> 99
> 100
> 120
> 156
> 99
> 100

That's at odds with the "r.mapcalc one=1", and shouldn't have anything
to do with categories.

Right. Looks a bit ugly.

Do you have some other mapset in the search path ahead of the current
mapset?

GRASS 6.1.cvs (spearfish60):/hardmnt/thuille0/ssi/grassdata/spearfish60 > g.mapsets -p
neteler PERMANENT user1

It seems that there is only this single map gives wrong results.
It's a 32bit RHEL4 box.

Markus

Markus Neteler wrote:

> Do you have some other mapset in the search path ahead of the current
> mapset?

GRASS 6.1.cvs (spearfish60):/hardmnt/thuille0/ssi/grassdata/spearfish60 > g.mapsets -p
neteler PERMANENT user1

It seems that there is only this single map gives wrong results.
It's a 32bit RHEL4 box.

The only thing I can suggest is using a debugger.

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

On Tue, Aug 30, 2005 at 11:14:44PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > Do you have some other mapset in the search path ahead of the current
> > mapset?
>
> GRASS 6.1.cvs (spearfish60):/hardmnt/thuille0/ssi/grassdata/spearfish60 > g.mapsets -p
> neteler PERMANENT user1
>
> It seems that there is only this single map gives wrong results.
> It's a 32bit RHEL4 box.

The only thing I can suggest is using a debugger.

To recall, the problem:

r.mapcalc "one=1"
r.cats one
Reading one in neteler ... 100%
99
100
120
156

Using the debugger, I found that unusual things happen in
G_next_cell_stat() in lib/gis/cell_stats.c

It loops over s->curoffset, and when s->curoffset gets to 35,
then
if ((*count = s->node[s->curp].count[s->curoffset]))
gets true (*count is 2 then, before it was 0).

idx is 16 then.

*cat = (idx<<SHIFT) + s->curoffset;
results in *cat = 99 then (s->curoffset is 35). After that G_next_cell_stat()
is left for the second loop where 100 results and so on.

SHIFT isn't known by the debugger (on top it is defined as 6 ).

I am pretty clueless.

Markus

Markus Neteler wrote:

> > > Do you have some other mapset in the search path ahead of the current
> > > mapset?
> >
> > GRASS 6.1.cvs (spearfish60):/hardmnt/thuille0/ssi/grassdata/spearfish60 > g.mapsets -p
> > neteler PERMANENT user1
> >
> > It seems that there is only this single map gives wrong results.
> > It's a 32bit RHEL4 box.
>
> The only thing I can suggest is using a debugger.

To recall, the problem:

r.mapcalc "one=1"

r.cats one
Reading one in neteler ... 100%
99
100
120
156

Forget about r.cats (and categories in general). This:

r.stats -1 one
120
156
99
100
120
156
99
100

is a lot more interesting (and relevant).

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

On Wed, Aug 31, 2005 at 09:05:02PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > > Do you have some other mapset in the search path ahead of the current
> > > > mapset?
> > >
> > > GRASS 6.1.cvs (spearfish60):/hardmnt/thuille0/ssi/grassdata/spearfish60 > g.mapsets -p
> > > neteler PERMANENT user1
> > >
> > > It seems that there is only this single map gives wrong results.
> > > It's a 32bit RHEL4 box.
> >
> > The only thing I can suggest is using a debugger.
>
> To recall, the problem:
>
> r.mapcalc "one=1"

> r.cats one
> Reading one in neteler ... 100%
> 99
> 100
> 120
> 156

Forget about r.cats (and categories in general). This:

> r.stats -1 one
> 120
> 156
> 99
> 100
> 120
> 156
> 99
> 100

is a lot more interesting (and relevant).

OK:

in r.stats:

main.c
G_get_range_min_max (&range, &min, &max);
min =1
max =1

ok so far.
raw_stats (fd, verbose, with_coordinates, with_xy, with_labels);
           fd 0 0 0 0

Entering raw_stats():
raw_stats.c:49
rastp[i] = rast[i];
i=0
rastp[0]= void

raw_stats.c:98, when i is 0, then
*((CELL *) rastp[i]) is 120.

Then it prints 120 and so forth.

Should I add some G_debug() in raw_stats?

Markus

Markus Neteler wrote:

> Forget about r.cats (and categories in general). This:
>
> > r.stats -1 one
> > 120
> > 156
> > 99
> > 100
> > 120
> > 156
> > 99
> > 100
>
> is a lot more interesting (and relevant).

OK:

in r.stats:

main.c
G_get_range_min_max (&range, &min, &max);
min =1
max =1

ok so far.
raw_stats (fd, verbose, with_coordinates, with_xy, with_labels);
           fd 0 0 0 0

Entering raw_stats():
raw_stats.c:49
rastp[i] = rast[i];
i=0
rastp[0]= void

raw_stats.c:98, when i is 0, then
*((CELL *) rastp[i]) is 120.

Then it prints 120 and so forth.

Should I add some G_debug() in raw_stats?

I'd start by examining the pointers rastp[0] and rast[0], and the
contents of the buffer to which they point, before entering the
"for (col = ..." loop. I.e.:

  print rast[0]
  print rastp[0]
  print *(CELL*)(rast[0])@50

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

On Thu, Sep 01, 2005 at 01:21:24PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > Forget about r.cats (and categories in general). This:
> >
> > > r.stats -1 one
> > > 120
> > > 156
> > > 99
> > > 100
> > > 120
> > > 156
> > > 99
> > > 100
> >
> > is a lot more interesting (and relevant).
>
> OK:
>
> in r.stats:
>
> main.c
> G_get_range_min_max (&range, &min, &max);
> min =1
> max =1
>
> ok so far.
> raw_stats (fd, verbose, with_coordinates, with_xy, with_labels);
> fd 0 0 0 0
>
> Entering raw_stats():
> raw_stats.c:49
> rastp[i] = rast[i];
> i=0
> rastp[0]= void
>
> raw_stats.c:98, when i is 0, then
> *((CELL *) rastp[i]) is 120.
>
> Then it prints 120 and so forth.
>
> Should I add some G_debug() in raw_stats?

I'd start by examining the pointers rastp[0] and rast[0], and the
contents of the buffer to which they point, before entering the
"for (col = ..." loop. I.e.:

  print rast[0]
  print rastp[0]
  print *(CELL*)(rast[0])@50

The @ is dislike (not sure what it does). This is what I get:

GRASS 6.1.cvs (spearfish60):~/grass61/raster/r.stats > cvs diff raw_stats.c
Index: raw_stats.c

RCS file: /grassrepository/grass6/raster/r.stats/raw_stats.c,v
retrieving revision 2.1
diff -u -r2.1 raw_stats.c
--- raw_stats.c 13 Jul 2005 15:55:40 -0000 2.1
+++ raw_stats.c 1 Sep 2005 13:10:08 -0000
@@ -52,6 +52,11 @@
        if (with_coordinates)
            G_format_northing (G_row_to_northing(row+.5, &window), nbuf, -1);

+
+ G_debug(0, "rast[%d]: %d", rast[i], i);
+ G_debug(0, "rastp[%d]: %d", rastp[i], i);
+ G_debug(0, "*(CELL*)(rast[0]): %d", *(CELL*)(rast[0]));
+ G_debug(0, "*(CELL*)(rast[%d]): %d", *(CELL*)(rast[i]));
        for (col = 0; col < ncols; col++)
        {
            if (no_nulls || no_nulls_all)
GRASS 6.1.cvs (spearfish60):~/grass61/raster/r.stats > r.stats -1 one
D0/0: rast[0]: 1
D0/0: rastp[0]: 1
D0/0: *(CELL*)(rast[0]): 120
Segmentation fault

Apparently the last G_debug does not make sense, but the mysterious (?) 120
is there.

BTW:
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)

I just see that the damn optimization creeped in again.

When I do

CFLAGS="-g -Wall" ./configure ...
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc -g -Wall ) works... yes
checking whether the C compiler (gcc -g -Wall ) is a cross-compiler... no
...
C compiler: gcc -g -Wall
C++ compiler: c++ -g -O2
...

But:
grep CFLAGS_OPTIMIZE ~/grass61/include/Make/Platform.make
CFLAGS_OPTIMIZE = -O2

I have to manually fix that. Seems to be evil in aclocal.m4
around line 756:

        Linux*)
            SHLIB_CFLAGS="-fPIC"
            SHLIB_LD_LIBS='${LIBS}'
            SHLIB_SUFFIX=".so"

            CFLAGS_OPTIMIZE=-O2
            # egcs-2.91.66 on Redhat Linux 6.0 generates lots of warnings
            # when you inline the string and math operations. Turn this off to
            # get rid of the warnings.
            #CFLAGS_OPTIMIZE="${CFLAGS_OPTIMIZE} -D__NO_STRING_INLINES -D__NO_MATH_INLINES"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The r.stats debug result remains however the same.

Markus

To separate the threads, I repost it again:

On Thu, Sep 01, 2005 at 04:06:33PM +0200, Markus Neteler wrote:
...

I just see that the damn optimization creeped in again.

When I do

CFLAGS="-g -Wall" ./configure ...
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc -g -Wall ) works... yes
checking whether the C compiler (gcc -g -Wall ) is a cross-compiler... no
...
C compiler: gcc -g -Wall
C++ compiler: c++ -g -O2
...

But:
grep CFLAGS_OPTIMIZE ~/grass61/include/Make/Platform.make
CFLAGS_OPTIMIZE = -O2

I have to manually fix that. Seems to be evil in aclocal.m4
around line 756:

        Linux*)
            SHLIB_CFLAGS="-fPIC"
            SHLIB_LD_LIBS='${LIBS}'
            SHLIB_SUFFIX=".so"

            CFLAGS_OPTIMIZE=-O2
            # egcs-2.91.66 on Redhat Linux 6.0 generates lots of warnings
            # when you inline the string and math operations. Turn this off to
            # get rid of the warnings.
            #CFLAGS_OPTIMIZE="${CFLAGS_OPTIMIZE} -D__NO_STRING_INLINES -D__NO_MATH_INLINES"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Paul, do you remember the reason for this modification?
http://grass.itc.it/pipermail/grass-commit/2004-July/012136.html

Markus

On Thu, Sep 01, 2005 at 04:06:33PM +0200, Markus Neteler wrote:

On Thu, Sep 01, 2005 at 01:21:24PM +0100, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > > Forget about r.cats (and categories in general). This:
> > >
> > > > r.stats -1 one
> > > > 120
> > > > 156
> > > > 99
> > > > 100
> > > > 120
> > > > 156
> > > > 99
> > > > 100
> > >
> > > is a lot more interesting (and relevant).
> >
> > OK:
> >
> > in r.stats:
> >
> > main.c
> > G_get_range_min_max (&range, &min, &max);
> > min =1
> > max =1
> >
> > ok so far.
> > raw_stats (fd, verbose, with_coordinates, with_xy, with_labels);
> > fd 0 0 0 0
> >
> > Entering raw_stats():
> > raw_stats.c:49
> > rastp[i] = rast[i];
> > i=0
> > rastp[0]= void
> >
> > raw_stats.c:98, when i is 0, then
> > *((CELL *) rastp[i]) is 120.
> >
> > Then it prints 120 and so forth.
> >
> > Should I add some G_debug() in raw_stats?
>
> I'd start by examining the pointers rastp[0] and rast[0], and the
> contents of the buffer to which they point, before entering the
> "for (col = ..." loop. I.e.:
>
> print rast[0]
> print rastp[0]
> print *(CELL*)(rast[0])@50

The @ is dislike (not sure what it does). This is what I get:

GRASS 6.1.cvs (spearfish60):~/grass61/raster/r.stats > cvs diff raw_stats.c
Index: raw_stats.c

RCS file: /grassrepository/grass6/raster/r.stats/raw_stats.c,v
retrieving revision 2.1
diff -u -r2.1 raw_stats.c
--- raw_stats.c 13 Jul 2005 15:55:40 -0000 2.1
+++ raw_stats.c 1 Sep 2005 13:10:08 -0000
@@ -52,6 +52,11 @@
        if (with_coordinates)
            G_format_northing (G_row_to_northing(row+.5, &window), nbuf, -1);

+
+ G_debug(0, "rast[%d]: %d", rast[i], i);
+ G_debug(0, "rastp[%d]: %d", rastp[i], i);
+ G_debug(0, "*(CELL*)(rast[0]): %d", *(CELL*)(rast[0]));
+ G_debug(0, "*(CELL*)(rast[%d]): %d", *(CELL*)(rast[i]));
        for (col = 0; col < ncols; col++)
        {
            if (no_nulls || no_nulls_all)
GRASS 6.1.cvs (spearfish60):~/grass61/raster/r.stats > r.stats -1 one
D0/0: rast[0]: 1
D0/0: rastp[0]: 1
D0/0: *(CELL*)(rast[0]): 120
Segmentation fault

Apparently the last G_debug does not make sense, but the mysterious (?) 120
is there.

BTW:
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)

OK, we debugged some more hours here. Outcome:

With apparently identical settings (PATH, LD_LIBRARY_PATH etc),
identical software (GRASS, libs etc), identical shell:

- user 'neteler' still writes/reads nonsense raster maps
- another user on the same machine successfully writes/reads raster
  maps except for those generated by user 'neteler'

It seems that I am out of the game :slight_smile:

Crazy.

Markus

Hello Markus

On Fri, 2 Sep 2005, Markus Neteler wrote:

            CFLAGS_OPTIMIZE=-O2
            # egcs-2.91.66 on Redhat Linux 6.0 generates lots of warnings
            # when you inline the string and math operations. Turn this off to
            # get rid of the warnings.
            #CFLAGS_OPTIMIZE="${CFLAGS_OPTIMIZE} -D__NO_STRING_INLINES -D__NO_MATH_INLINES"
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Paul, do you remember the reason for this modification?
http://grass.itc.it/pipermail/grass-commit/2004-July/012136.html

I don't think that is relevant as CFLAGS_OPTIMIZE isn't actually used anywhere (to answer your question it was copied from the most recent version in the Tcl/Tk source at the time and seemed to work well so I re-used it).

I suspect the -O2 is being added in automatically by autoconf at some stage. Search for -O2 in the configure script and you will see there are some occurences that are not sourced from either configure.in nor aclocal.m4.
You could manually edit the configure script after editing it perhaps: this
looks very suspicious:

echo "$ac_t""$ac_cv_prog_cxx_g" 1>&6
if test "$ac_test_CXXFLAGS" = set; then
   CXXFLAGS="$ac_save_CXXFLAGS"
elif test $ac_cv_prog_cxx_g = yes; then
   if test "$GXX" = yes; then
     CXXFLAGS="-g -O2"
   else
     CXXFLAGS="-g"
   fi
else
   if test "$GXX" = yes; then
     CXXFLAGS="-O2"
   else
     CXXFLAGS=
   fi
fi

but I suspect the more robust solution is to explicitly set CXXFLAGS as well as CFLAGS, i.e. something like:
CFLAGS="-g -Wall" CXXFLAGS="-g -Wall" ./configure ...

Does that work?

Paul

Hello Paul,

On Fri, Sep 02, 2005 at 03:09:26PM +0100, Paul Kelly wrote:

Hello Markus

On Fri, 2 Sep 2005, Markus Neteler wrote:

>>
>> CFLAGS_OPTIMIZE=-O2
>> # egcs-2.91.66 on Redhat Linux 6.0 generates lots of warnings
>> # when you inline the string and math operations. Turn this
>> off to
>> # get rid of the warnings.
>> #CFLAGS_OPTIMIZE="${CFLAGS_OPTIMIZE} -D__NO_STRING_INLINES
>> -D__NO_MATH_INLINES"
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>Paul, do you remember the reason for this modification?
>http://grass.itc.it/pipermail/grass-commit/2004-July/012136.html

I don't think that is relevant as CFLAGS_OPTIMIZE isn't actually used
anywhere

good point, I didn't realize that (so, false alarm).

(to answer your question it was copied from the most recent
version in the Tcl/Tk source at the time and seemed to work well so I
re-used it).

I suspect the -O2 is being added in automatically by autoconf at some
stage. Search for -O2 in the configure script and you will see there are
some occurences that are not sourced from either configure.in nor
aclocal.m4.
You could manually edit the configure script after editing it perhaps: this
looks very suspicious:

echo "$ac_t""$ac_cv_prog_cxx_g" 1>&6
if test "$ac_test_CXXFLAGS" = set; then
  CXXFLAGS="$ac_save_CXXFLAGS"
elif test $ac_cv_prog_cxx_g = yes; then
  if test "$GXX" = yes; then
    CXXFLAGS="-g -O2"
  else
    CXXFLAGS="-g"
  fi
else
  if test "$GXX" = yes; then
    CXXFLAGS="-O2"
  else
    CXXFLAGS=
  fi
fi

but I suspect the more robust solution is to explicitly set CXXFLAGS as
well as CFLAGS, i.e. something like:
CFLAGS="-g -Wall" CXXFLAGS="-g -Wall" ./configure ...

Does that work?

Yep:

grep 'O2\|CFLA' include/Make/Platform.make
CFLAGS_DEBUG = -g
CFLAGS_OPTIMIZE = -O2
CFLAGS_WARNING = -Wall -Wconversion -Wno-implicit-int
SHLIB_CFLAGS = -fPIC
CFLAGS1 = -g -Wall
COMPILE_FLAGS = $(CPPFLAGS) $(CFLAGS1) $(CFLAGS_WARNING) $(INCLUDE_DIRS)
XCFLAGS = -I/usr/X11R6/include
GDALCFLAGS = -I/usr/local/include
PROJINC = $(GDALCFLAGS)

Thanks,

Markus

Markus Neteler wrote:

> > Entering raw_stats():
> > raw_stats.c:49
> > rastp[i] = rast[i];
> > i=0
> > rastp[0]= void
> >
> > raw_stats.c:98, when i is 0, then
> > *((CELL *) rastp[i]) is 120.
> >
> > Then it prints 120 and so forth.
> >
> > Should I add some G_debug() in raw_stats?
>
> I'd start by examining the pointers rastp[0] and rast[0], and the
> contents of the buffer to which they point, before entering the
> "for (col = ..." loop. I.e.:
>
> print rast[0]
> print rastp[0]
> print *(CELL*)(rast[0])@50

The @ is dislike (not sure what it does). This is what I get:

The above are gdb commands. Appending @<n> to a value in a gdb print
statement prints <n> elements.

GRASS 6.1.cvs (spearfish60):~/grass61/raster/r.stats > cvs diff raw_stats.c
Index: raw_stats.c

RCS file: /grassrepository/grass6/raster/r.stats/raw_stats.c,v
retrieving revision 2.1
diff -u -r2.1 raw_stats.c
--- raw_stats.c 13 Jul 2005 15:55:40 -0000 2.1
+++ raw_stats.c 1 Sep 2005 13:10:08 -0000
@@ -52,6 +52,11 @@
        if (with_coordinates)
            G_format_northing (G_row_to_northing(row+.5, &window), nbuf, -1);

+
+ G_debug(0, "rast[%d]: %d", rast[i], i);
+ G_debug(0, "rastp[%d]: %d", rastp[i], i);

The arguments are the wrong way around.

+ G_debug(0, "*(CELL*)(rast[0]): %d", *(CELL*)(rast[0]));
+ G_debug(0, "*(CELL*)(rast[%d]): %d", *(CELL*)(rast[i]));
        for (col = 0; col < ncols; col++)
        {
            if (no_nulls || no_nulls_all)
GRASS 6.1.cvs (spearfish60):~/grass61/raster/r.stats > r.stats -1 one
D0/0: rast[0]: 1
D0/0: rastp[0]: 1

These two say that rast[1] == rastp[1] == 0 (i.e. NULL). I would have
expected to see values for rast[0].

gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)

I just see that the damn optimization creeped in again.

When I do

CFLAGS="-g -Wall" ./configure ...
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc -g -Wall ) works... yes
checking whether the C compiler (gcc -g -Wall ) is a cross-compiler... no
...
C compiler: gcc -g -Wall
C++ compiler: c++ -g -O2
...

But:
grep CFLAGS_OPTIMIZE ~/grass61/include/Make/Platform.make
CFLAGS_OPTIMIZE = -O2

I have to manually fix that. Seems to be evil in aclocal.m4
around line 756:

Right. Both CFLAGS_OPTIMIZE and CFLAGS_WARNING are bogus. Any compiler
switches which aren't essential (e.g. include directories) should be
left up to the user.

The simplest solution is to remove them from include/Make/*.make[.in].

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