Hello Vaclav. otrd., 2020. g. 4. febr., plkst. 19:51 — lietotājs Vaclav Petras (<wenzesl...@gmail.com>) rakstīja: > > Hi Maris and Markus, > > On Tue, Feb 4, 2020 at 3:39 AM Maris Nartiss <maris....@gmail.com> wrote: >> >> Hello Markus, >> as most of errors reported are legit, some of them are useless at the >> current philosophy of GRASS GIS. We are OK with small memory leaks, as >> modules are intended to be short running and then memory is reclaimed >> by the OS (this is faster than freeing it before exit). Of course, >> this would not be OK for long-running apps. > > > Most of them will be like what you describe, but are there some where memory > could be freed during the processing making space for more processing (e.g. > by another process)? Also the library should not leak as it should be > possible to write module which is long-running (without leaks and checkable > by Coverity or valgrind).
As I wrote, it is more about philosophical approach as most of leaks are small (i.e. not freeing a mapset / location name after use etc.). If we adopt a new policy of no leaks, code could be changed in a slowly manner (case by case as need arises). > >> >> Unless we change our >> approach, resource leaks are just a noise. > > > One approach might be marking the places for Coverity to ignore making the > leak explicit (i.e., clearly intentional). Another approach might be some > G_optional_free() which could be G_free() in debug mode, but empty otherwise. This is interesting idea. I recently was thinking about having different build types. I haven't been doing any profiling, but getting rid of G_debug could be an option for release version. Having GRASS scripts running for more than 400 CPU days forces to be creative ;-) >> >> >> I would vote against integrating Coverty scan into CI — just to keep >> noise level down. It is useless to get regular reports if we do not >> plan (lack of manpower) to react to them. > > > I agree that the current number of errors is high, but if I understand it > correctly (and Markus can correct me here), the integration with CI is not > about having the errors visible for each PR on GitHub, but rather pushing > things automatically to Coverity from Travis, so that Markus does not have to > upload that manually. +1 if it reduces load of Markus. > > Best, > Vaclav Māris. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
