<div dir="ltr"><div>Hi Maris and Markus,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 4, 2020 at 3:39 AM Maris Nartiss <<a href="mailto:maris.gis@gmail.com">maris.gis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Markus,<br>
as most of errors reported are legit, some of them are useless at the<br>
current philosophy of GRASS GIS. We are OK with small memory leaks, as<br>
modules are intended to be short running and then memory is reclaimed<br>
by the OS (this is faster than freeing it before exit). Of course,<br>
this would not be OK for long-running apps.</blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Unless we change our<br>
approach, resource leaks are just a noise.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would vote against integrating Coverty scan into CI — just to keep<br>
noise level down. It is useless to get regular reports if we do not<br>
plan (lack of manpower) to react to them.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Best,<br></div><div>Vaclav<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Just my 0.02 cents,<br>
Māris.<br>
<br>
pirmd., 2020. g. 3. febr., plkst. 21:50 — lietotājs Markus Neteler<br>
(<<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>>) rakstīja:<br>
><br>
> Hi devs,<br>
><br>
> I have re-run the coverity scan on master, results below.<br>
><br>
> There is also the option of Travis integration which might be a good idea.<br>
> Anyone to support this?<br>
><br>
> Markus<br>
><br>
><br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></blockquote></div></div>