[GRASS-user] v.rast.stats error: "Unable to seek"

[Luí­s Moreira de Sousa]

Hi Maris,

thank you for the details. I can try compiling with the flag you suggest, but I need a bit more time. Will let you know if I succeed.

Regards.


--
Luís Moreira de Sousa
Pastoor Bruggemanlaan 21
6861 GR Oosterbeek
The Netherlands
Phone: +31 628 544 755
Email: luis.de.sousa at protonmail.ch
Mastodon: @luis_de_sousa at mastodon.social
URL: https://ldesousa.codeberg.page

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 4, 2021 10:21 AM, Maris Nartiss <maris.gis at gmail.com> wrote:

> Don't want to bring bad news, but it looks more like an offset
> overflow. You will not catch it with valgrind. Although it might catch
> a bug leading to offset value explosion, most likely the main cause is
> just code written for handling of small/medium datasets and not
> large/huge ones (=imperfect logic => can't catch that with valgrind).
>
> My suggestion: recompile GRASS with -ftrapv. If it is an integer
> overflow, at least it will become clearly obvious.
> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
>
> The bad thing is G_fseek calling G_fatal_error without knowing actual
> file name (lets put pipes aside) and thus it is impossible to tell
> where exactly the error originated from the error message alone.
> Better would be to bubble up error to main program and let it deal
> with it in a clean way. Of course, as GRASS is designed around current
> idioms (handling failure is responsibility of a library making module
> development really easy), this will not happen in a foreseeable
> future.
>
> One thing you could do – drasticly reduce size of computational region.
> Māris.