From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KghXMLc5lGCjKwAAWB0awg (envelope-from ) for ; Thu, 06 May 2021 14:47:19 -0400 Received: by simark.ca (Postfix, from userid 112) id B59901F11C; Thu, 6 May 2021 14:47:19 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1717B1E54D for ; Thu, 6 May 2021 14:47:19 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 64795386100F; Thu, 6 May 2021 18:47:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64795386100F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620326838; bh=blmPFj1OiVmrTUvZfqSEC4ieQdo3W2EEBc0cZFXWwcw=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=i2bGZrMVYgX7HhGGrDQUIKbaU0J7xny5CzgxTaffQ5NWM1GjajoCfy8YXoaCYt1RE cQkI0MkPWnxu24UzPy2EFpKG+PoM/jz2HFsftEsuCiZiYjCq0Ltot1z63stlI4P6ay dVicZoUPCBQPBIJMxsdXV0jiu3STAEJhM8p3kssc= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 556D0386100F for ; Thu, 6 May 2021 18:47:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 556D0386100F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-323-YfC5NsjLMsarBWHizYrZjA-1; Thu, 06 May 2021 14:47:11 -0400 X-MC-Unique: YfC5NsjLMsarBWHizYrZjA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EB0D01006C84; Thu, 6 May 2021 18:47:09 +0000 (UTC) Received: from redhat.com (ovpn-112-75.phx2.redhat.com [10.3.112.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C24E15D6AC; Thu, 6 May 2021 18:47:09 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94) (envelope-from ) id 1lej1g-0000tV-1I; Thu, 06 May 2021 14:47:08 -0400 Date: Thu, 6 May 2021 14:47:07 -0400 To: Simon Marchi Subject: Re: [PATCH] debuginfod-support.c: Use long-lived debuginfod_client Message-ID: <20210506184707.GA29815@redhat.com> References: <20210430235735.1371915-1-amerey@redhat.com> <87eeek1y07.fsf@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Frank Ch. Eigler via Gdb-patches" Reply-To: "Frank Ch. Eigler" Cc: Tom Tromey , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi - > 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. If it's not hard to do, sure .... but wouldn't that necessitate exposing the pointer from function static scope again? > 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. I suspect that if we were to do any of those things in the future, we'd keep things clean by techniques like holding onto fd's to unlinked files, so process exit is enough. (We could make a commitment in the docs.) - FChE