Re: [GRASS-user] v.rast.stats error: "Unable to seek"
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 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 grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.rast.stats error: "Unable to seek"
Hi Markus, I started by setting up the memory limit setting with g.gisenv, but v.to.rast fails with the same error. I then tried valgrind. It is not really saying much, I fiddled a bit with it but can't more outputs that what you see below. > valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD ==60598== Memcheck, a memory error detector ==60598== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==60598== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==60598== Command: v.to.rast input=PSU output=test use=cat memory=1 ==60598== ==60598== Warning: set address range perms: large range [0x154c9d040, 0x170a47950) (undefined) Killed I think I can create a workflow to replicate this error, I will work on that next week. Cheers. -- 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 Wednesday, February 3, 2021 6:57 PM, Markus Neteler wrote: > Hi Luís, > > On Wed, Feb 3, 2021 at 5:51 PM Luís Moreira de Sousa via grass-user > grass-user@lists.osgeo.org wrote: > > > Hi Stefan, thank you for the reply. > > The outputs you request are below. v.rast.stats takes about 8 GB of RAM > > before failing, only 1/4 of what is available in the workstation. I also > > tried increasing the memory parameter but it never goes above 8 GB and > > fails all the same. > > If I am not mistaken, the memory= parameter isn't used at all in > v.rast.stats, hence not passed to v.to.rast: > https://github.com/OSGeo/grass/blob/e5afa5a8a0f8e39376f4ddfbda1a62abdef99a21/scripts/v.rast.stats/v.rast.stats.py#L167 > > For a test, you could use g.gisenv and set the "cache" memory to a > higher value (v.to.rast will respect it then): > https://grass.osgeo.org/grass78/manuals/variables.html#list-of-selected-internal-grass-environment-variables > --> MEMORYMB > > Eg. > > set to 12 GB (default: 300 MB) > > === > > g.gisenv set="MEMORYMB=12000" > > Not sure if that would help anyway. > > However: > > > Let me know if there is something else I can check. Thank you. > > yes, you may try with "valgrind": > https://grasswiki.osgeo.org/wiki/GRASS_Debugging#Using_Valgrind > > CMD="v.to.rast input=PSU output=test use=cat memory=1" > valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD --o > > The output may give some hints (it will be long). > > Best > Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Support GRASS GIS financially !
Dear all, We just received our very first sponsorship contribution of 2021 (thank you !) and we want to take this occasion to thank all those who sponsored us last year and remind you that the GRASS GIS project needs financial support in order to: - organize very valuable face-to-face meetings and sprints gathering developers and the wider community for a few days to concentrate on improving GRASS GIS - fund specific fixes or enhancements (this year the use of micro-budgets for such fixes is planned) - maintain our website - produce marketing material to spread the word You can see the list of past individual and corporate sponsors here: https://grasswiki.osgeo.org/wiki/Sponsors As you can see, no amount is too small: if all GRASS GIS users give just a small amount regularly, we will already have a sizeable budget to work with ! And I challenge you to find software that does all that GRASS GIS does for 5€/$ or 10 €/$ a year ;-) So, just go to https://grass.osgeo.org/contribute/sponsoring/ and help us make GRASS GIS better. If you want to see more details about how we use the money, note that the project budgets are public. For 2021 see https://grasswiki.osgeo.org/wiki/GRASS_GIS_Budget_2021. The GRASS GIS Project Steering Committee ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
