[GRASS-dev] seemingly random errors in r.mapcalc

[Paulo van Breugel]

Thanks all for trying to help out with this and all information and
suggestions, much appreciated!

It is probably not related to incremental compilation issues. I had those
in the past, even though I always use make clean and re-run the
configuration file. So since then I regularly do a completely clean
compilation, i.e., removing the complete grass folder in /usr/local/bin and
downloading the grass source files again rather then updating. I did so for
the latest compilation too.I

I'll try if I can find anything in the log files and try the suggestions of
Soeren. I will also try to run the same calculations using a new mapset and
new data, to rule out corrupt data.




On Sat, Aug 3, 2013 at 4:02 AM, Glynn Clements <glynn at gclements.plus.com>wrote:

>
> Paulo van Breugel wrote:
>
> > Sorry, pushed the short cut sending the email off too early.. What I
> wanted
> > to ask is, is there any way I can find out what kind of error I am
> getting?
> > Now, the only message is "Error".
>
> There are only a few possible causes of "Error reading raster data",
> namely an error from lseek(), read(), G_zlib_read() or GDALRasterIO(),
> or a short count returned from read().
>
> Any of these can be caused by corrupted data, but that would normally
> be repeatable.
>
> G_zlib_read() is only applicable to floating-point maps, while
> GDALRasterIO() is only applicable to GDAL-linked maps (r.external).
>
> If it's a hardware error, it will be logged by the kernel. The log
> files are usually in /var/log, but which errors go in which files
> depends upon the distribution.
>
> If you're compiling from source, be sure to run "make clean" between
> "svn update" and "make". Incremental compilation isn't reliable in the
> general case. If "svn update" updates the configure script, be sure to
> re-run configure before doing anything else.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130803/a12b68cb/attachment.html>