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 grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
