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 <nete...@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.so...@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.so...@protonmail.ch > > Mastodon: @luis_de_sousa@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....@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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
