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

[Markus Neteler]

On Tue, Jan 14, 2003 at 01:59:49AM +0000, Glynn Clements wrote:
> 
> 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).

Excuse me, but this is not clear to me. The cats file starts with
1:0.0000
Do you mean that 0.0000 is invalid?

> 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.

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

Correct, I have just tested the old r.mapcalc which also fails.
 
> 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).

My maps are rather big :-)

> 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.

It is surprising that this problem was not yet already fixed some
years ago... Hope we can find a solution!

Markus