[GRASS-dev] Fwd: New Defects reported by Coverity Scan for grass

[Vaclav Petras]

Hi Maris and Markus,

On Tue, Feb 4, 2020 at 3:39 AM Maris Nartiss <maris.gis at 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).


> 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.


>
> 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.

Best,
Vaclav


>
> Just my 0.02 cents,
> Māris.
>
> pirmd., 2020. g. 3. febr., plkst. 21:50 — lietotājs Markus Neteler
> (<neteler at osgeo.org>) rakstīja:
> >
> > Hi devs,
> >
> > I have re-run the coverity scan on master, results below.
> >
> > There is also the option of Travis integration which might be a good
> idea.
> > Anyone to support this?
> >
> > Markus
> >
> >
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20200204/61ea6263/attachment.html>