Re: [PATCH] gdb/debuginfod: cleanup debuginfod earlier

[Aaron Merey <amerey@redhat.com>]

On Tue, May 23, 2023 at 7:23 AM Andrew Burgess <aburgess@redhat.com> wrote:
>
> And then a global debuginfod_client_up is created to hold a pointer to
> the debuginfod_client object.  As a global this will be cleaned up
> using the standard C++ global object destructor mechanism, which is
> run after the at_exit handlers.
>
> However, it is expected that when debuginfod_end is called the
> debuginfod_client object will still be in a usable state, that is, we
> don't expect the at_exit handlers to have run and started cleaning up
> the library state.

The crash comes down to curl_multi_cleanup triggering a double free
when it's called during process exit. Ideally this should be fixed in
libcurl or at least the libcurl docs should mention that curl_multi_cleanup
shouldn't be called at exit.

But it's still a good idea to add this workaround to gdb. Thanks for looking
into this. I tested Simon's patch since it's a bit simpler and it fixes the
crash for me on F37.

> There's no test associated with this patch.  I have no idea how I
> might trigger this bug from within the testsuite.  If anyone has any
> ideas then I'm happy to have a go at writing something.

gdb's debuginfod tests only pull files from local servers.  This crash
does not reproduce when using a localhost URL.  To test for this
gdb would have to download from a remote server and maybe
use the OPENSSL_CONF environment variable to set a custom
config file path.  However this might cause more problems than it
solves.

Aaron