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

[Luí­s Moreira de Sousa]

Hi Markus,

I tried compiling GRASS with the -ftrapv flag, but it was failing (can't remember now why). I was also supposed to create a replicating procedure, but other things came up in the meantime. However, it looks like for rasters larger than a certain size none of the modules depending on v.to.rast function correctly.

I will try to have a look again at an agnostic replication procedure.

Cheers.

--
Luís

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, May 18, 2021 10:56 PM, Markus Neteler <neteler at osgeo.org> wrote:

> Hi Luís,
>
> Did you get any insights?
>
> Best,
> Markus
>
> On Fri, Feb 5, 2021 at 4:17 PM Luí­s Moreira de Sousa
> luis.de.sousa at protonmail.ch wrote:
>
> > 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.
>
> --
>
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog