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

[Maris Nartiss]

Hello Vaclav.

otrd., 2020. g. 4. febr., plkst. 19:51 — lietotājs Vaclav Petras
(<wenzeslaus at gmail.com>) rakstīja:
>
> 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).

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.