[GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Glynn Clements]

Dylan Beaudette wrote:

> I can now verify that t.rast.mapcalc is creating some raster maps with
> corrupt (?) data. Corrupt in the sense that subsequent reading of the
> maps results in the "Error reading raster data for row ..." error.
> Just in case anyone is interested, I have opened a ticket for more
> informative errors raised by lib/raster/get_row.c
> (https://trac.osgeo.org/grass/ticket/2762).
> 
> As previously reported, errors seem to occur about 50-60% of the time
> and _do not_ appear to be related to the number of concurrent
> t.rast.mapcalc instances.

t.rast.mapcalc relies upon r.mapcalc.

If it's a pthread issue, using "export WORKERS=0" from the shell
before running t.rast.mapcalc should make it go away.

r.mapcalc uses a mutex for each map to prevent multiple threads
accessing a single map concurrently. Accessing different maps from
multiple threads should be safe ... for normal GRASS rasters, and
provided that no MASK raster is present (otherwise it ends up
accessing the MASK raster from multiple threads concurrently, which
results in the "Error reading raster data ..." error, due to a race
condition between the lseek() and the read()).

But for GDAL-linked (r.external) rasters, there may be re-entrancy
issues with GDAL itself, meaning that even accessing different maps
from multiple threads is unsafe.

Fixing that is potentially problematic. r.mapcalc doesn't know whether
its inputs are GDAL-linked (this feature is supposed to be transparent
to modules; there isn't a Rast_is_gdal(int fd) or similar function),
and lib/raster itself doesn't have any knowledge of pthreads (lib/gis
provides functions for managing a thread pool; r.mapcalc/r3.mapcalc
are currently the only modules using these functions, and r3.mapcalc
specifically sets WORKERS=0 because lib/raster3d isn't thread-safe).

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