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

[Andrew Burgess <aburgess@redhat.com>]

Aaron Merey <amerey@redhat.com> writes:

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

It's only a workaround if libcurl doesn't just update their docs to say
don't call curl_multi_cleanup at exit!  If they do that then debuginfod
needs to update its docs to say don't call debuginfod_end at exit
... and then we're back here, right?

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

Excellent, I'll add a commit message to Simon's version and repost it.

Thanks,
Andrew

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