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.133.124]) by sourceware.org (Postfix) with ESMTPS id 9C7D03857C40 for ; Thu, 7 Dec 2023 15:45:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C7D03857C40 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9C7D03857C40 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701963901; cv=none; b=ZVWLCmaS1sJi9rTzExCCq0nLNSUHiDtZWz8o97yJ2QmLLOptxadrZa5AAwn5ZkoJhhWr/pXpGTxPXXHu8NkqFlOkkxDIYeyVaMPdzuqgn2oDEEyYiFY2MBQiB/cf5bYupFvvv9AimEmriRzXw1e5evEFnqs9vDAQIOUk44HJSYM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701963901; c=relaxed/simple; bh=cei7V97CnG/mz0I0wVSifQ+mPokuz9YspvHDrYeiCQI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=BahYQ7p53eJFiW1wSdroDVW3Gb42g2Ce3kM9vA6zl0sql2HRhYqavrEa+Xae052JhOXE/tBOXIoXFuVY8rT5E4ELux+dIDi2TNb0qrC0/x5KgOwps/i8i+cCevkWd7TCiYJf+CNkpI1vlUPn6X/KLhUvooAQ1H0DEgk1ufq9gUo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701963900; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=rt6LTQl4aW8uYE91CjzQi6wBVTyXmXRGYelVIhBtYZs=; b=HTSyRBz9qaosY25zR16OgCmDrc5ZriX2hbVeBQvqOo+6GbyaDFk7ByzjdP3+t+rEJ1p5oW WuAnA1PmJ3X3ES6QbuNRyjwT5bsGm3o0FJAZTgYMmIc1ua72xZMbmZ6M/hlTeAijdkjx1Q Eo20evq0xCc15FVVMMQH+so7f6T90ag= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-500-23HPhEp0Paqi-ZlswrdGSQ-1; Thu, 07 Dec 2023 10:42:48 -0500 X-MC-Unique: 23HPhEp0Paqi-ZlswrdGSQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7209985A596; Thu, 7 Dec 2023 15:42:48 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 35E911C060AF; Thu, 7 Dec 2023 15:42:48 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 3B7Fgjw7166692 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 7 Dec 2023 16:42:46 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3B7Fgj7X166691; Thu, 7 Dec 2023 16:42:45 +0100 Date: Thu, 7 Dec 2023 16:42:44 +0100 From: Jakub Jelinek To: Costas Argyris Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] driver: Fix memory leak. Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 Thu, Dec 07, 2023 at 03:16:29PM +0000, Costas Argyris wrote: > > Still reachable memory at exit e.g. from valgrind is not a bug. > > Indeed, this is coming from a valgrind report here: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019 > > where it was noted that the driver memory leaks could be > problematic for JIT. In the invoke_embedded_driver JIT case yes, that calls driver::finalize (), which is why it should be freed before clearing the pointer in there (as then it is a real leak). > So, since using std::vector did reduce the valgrind records > by one (I only targeted a single variable to begin with) I took > that as a good sign. > > Regarding adding a call to XDELETE (mdswitches), yes, > that would help in the case where driver::finalize () is actually > called, which I think is for JIT. I was trying to take care of the > case where it doesn't get called as well, but from what you say > I take it that this case is not of interest. That is wasted compile time on a non-issue. If you see a JIT issue with definitely lost records, that is something that obviously should be fixed (but even in that area I think we've been a little bit lazy in the option handling). The most important is that the actual compiler binaries (cc1, cc1plus, ...) don't leak memory (in the definitely lost kind) like crazy, we have --enable-checking=valgrind for that purpose, where the driver runs cc1/cc1plus etc. under valgrind, but this is very expensive and slow, so usually it is run once during a cycle (if at all), on a fast machine could take even in non-bootstrap mode a weekend to go through the whole testsuite, then one can look at the leaks. Jakub