From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 1B3043858D37 for ; Tue, 23 May 2023 14:23:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B3043858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684851812; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wIQmQEBs2yQNrBFbZNrpiXIByRf/7xGKWYy4XThT1ho=; b=CcWQqmIgCnT+e3dFrJ4LTrl+wSR77tYqnTC5sFRs7Ia/eNuvT/U4DcgZTEsdGJfgo/1fS3 KPE6NHdiR+xvhJk3hJkhB3MymQO91iC4PrFWjCghwD/xoRaa/os7Sx+mj0aQlXr+5Rszbf 2Lvyvrci21wChwzL0XjTIBfBGZiQtlk= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-517-PwPXcCOqPDuvPeEeGbm3nw-1; Tue, 23 May 2023 10:23:31 -0400 X-MC-Unique: PwPXcCOqPDuvPeEeGbm3nw-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2af225e5b70so25167701fa.1 for ; Tue, 23 May 2023 07:23:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684851808; x=1687443808; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wIQmQEBs2yQNrBFbZNrpiXIByRf/7xGKWYy4XThT1ho=; b=DV8JlpzesJ0Hk1Mm/hIylHE1e9BXXFxaGPQuOovsCCeDGMEm4uhj6kgYFVMR8mR8En s41NZ1l1TlW7l2EeaZjLQEvCV4NdkN2rdByv0LNGksnJHIv5vHlE8lTTXy6ap/FS7U5k tfxtWDoXJAbEY+rWCH01YD6RJyBiOAzYQVoR3NhnD1T+iQPYL5wEqRauI3QIU/iby2wi oG/iEuL4oyALg7sGGJf20ZUKLi3ldTyjL3zUSg0BlTlVZ1jYGVGYNwZQynEa/89UHrmi afjoAQdgGDpYU1AAJnDPIs8jz6I848JOGX6JUlfkoiR+pu1sPWH6RVU/YOJAccn2Uzwq WZCA== X-Gm-Message-State: AC+VfDzsTzYXBv2C2/LyVs1Jv8B93jNCv5XNh0W6JeZpGt9S0bEVJmoT uuo8UDua3sgyyEKO3gANFgWF8hyzohG7TCV7f+AoWhq26s7Ms4XgC7j8CLfZajUzpVyf5s3TOkf TX0QdT7v7YIL8HbKtVrXnL9lGyclt4uvcnFeuc1aaC/KPdsg= X-Received: by 2002:a05:651c:14b:b0:2a8:ddb0:baa6 with SMTP id c11-20020a05651c014b00b002a8ddb0baa6mr5484365ljd.4.1684851807827; Tue, 23 May 2023 07:23:27 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4t2H+1mmGvb/mmtvm8P6RyiOBGIxfmUE3vNqiYKPhtD6CmQOkeW4OrvwMnzM2xlJlhHPafh4Ahe0t+0Z4YYbw= X-Received: by 2002:a05:651c:14b:b0:2a8:ddb0:baa6 with SMTP id c11-20020a05651c014b00b002a8ddb0baa6mr5484358ljd.4.1684851807519; Tue, 23 May 2023 07:23:27 -0700 (PDT) MIME-Version: 1.0 References: <46c030dcd5fc7a1a2ef4e078a92798f18c947ace.1684840908.git.aburgess@redhat.com> In-Reply-To: <46c030dcd5fc7a1a2ef4e078a92798f18c947ace.1684840908.git.aburgess@redhat.com> From: Aaron Merey Date: Tue, 23 May 2023 10:23:15 -0400 Message-ID: Subject: Re: [PATCH] gdb/debuginfod: cleanup debuginfod earlier To: Andrew Burgess Cc: gdb-patches@sourceware.org, Mark Wielaard X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, May 23, 2023 at 7:23=E2=80=AFAM Andrew Burgess 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 lookin= g 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