Re: [PATCH] debuginfod-support.c: Use long-lived debuginfod_client

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-05-06 1:27 p.m., Aaron Merey via Gdb-patches wrote:
> On Wed, May 5, 2021 at 8:56 PM Frank Ch. Eigler via Gdb-patches
> <gdb-patches@sourceware.org> wrote:
>>> Will there ever be a need to finalize this object?  Like, shut it down
>>> cleanly in some way?
>>
>> Nope (except perhaps if running gdb under valgrind?).
> 
> Running gdb under valgrind appears to work properly and no
> debuginfod-related leaks are reported.
> 
> If there aren't any other concerns then I will merge this patch with
> Tom's suggestion to define global_client in debuginfod_init() included.

That might be because Valgrind does not show the memory that is still
allocated at program exit that is still reachable by a global variable.

I think it would still be a good idea to properly close the client at
exit.  Not because the memory leak is a concern, but because we
shouldn't assume what closing a debuginfod client (current or future)
does or does not do, so we shouldn't assume that we can get away without
calling debuginfo_end.   A debuginfod client could eventually maintain
some temporary files that need to be deleted when closing in order not
to litter /tmp, some cache files need to be flushed, etc.

Simon