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: [email protected] Mastodon: @[email protected] URL: https://ldesousa.codeberg.page Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 4, 2021 10:21 AM, Maris Nartiss <[email protected]> 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. _______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
