[GRASS5] [bug #1502] (grass) r.mapcalc error

[Glynn Clements]

Markus Neteler wrote:

> The command crashing is:
> 
> r.mapcalc "test=@census1994dryUTM34S"
> 6%
> Segmentation fault
> 
> Thanks for looking into this. The map was imported with r.in.shape.

OK. The segfault occurs when G_get_cat() is called for an invalid
category (in this case 0; the cats table starts at 1). However, the
problem actually occurs when G__quant_get_rule_for_d_raster_val()
returns NULL (no quantisation rule matches the argument), and
G_quant_get_cell_value() tries to dereference the NULL pointer.

The problem with r.mapcalc is due to the algorithm which is used for
caching the results of G_get_cat() (in translate_from_cats()). Results
are stored in a btree; however, rather than storing individual values,
blocks of 64 values are stored. When the code is called for a value in
the range 1-63, it attempts to retrieve the values for the range 0-63,
resulting in an error.

The algorithm was copied verbatim from the original r.mapcalc, and I
would guess that it would have the same problem.

There are a variety of possible fixes.

1. Change G_quant_get_cell_value() to handle the case where
G__quant_get_rule_for_d_raster_val() returns NULL. I'm not sure what
it should return in this case (although it shouldn't segfault). In
this particular case (r.mapcalc) it shouldn't actually matter what was
returned, as the value should never actually be used.

2. Change translate_from_cats() to cache individual values in the
btree, rather than blocks. However, this may incur a substantial
penalty in terms of speed or memory usage or both. Discarding the
btree altogether would eliminate any memory issues, but the speed
penalty would probably be horrendous (the quantisation table lookup is
a linear search).

3. Change translate_from_cats() to trap invalid categories which would
cause a segfault. However, it isn't entirely clear what the test
should be; there's a fair amount of code between the call to
G_get_cat() and the quantisation table lookup.

-- 
Glynn Clements <glynn.clements at virgin.net>