public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Costas Argyris <costas.argyris@gmail.com>
Cc: Jonathan Wakely <jwakely@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] driver: Fix memory leak.
Date: Thu, 7 Dec 2023 15:42:07 +0100	[thread overview]
Message-ID: <ZXHZv5Maj0rrruWO@tucnak> (raw)
In-Reply-To: <CAHyHGCnNb-B78c+gWaq4jsLcANVWAFj87L3Xx_5D__-JkY1NPA@mail.gmail.com>

On Thu, Dec 07, 2023 at 02:28:18PM +0000, Costas Argyris wrote:
> Would that be something like this?

Yes.  Or perhaps even easier just change

--- gcc/gcc.cc.jj	2023-12-07 08:31:59.970849379 +0100
+++ gcc/gcc.cc	2023-12-07 15:33:46.616886894 +0100
@@ -11368,6 +11368,7 @@ driver::finalize ()
   input_from_pipe = 0;
   suffix_subst = NULL;
 
+  XDELETE (mdswitches);
   mdswitches = NULL;
   n_mdswitches = 0;
 
> Although it didn't fix the leak, which was the entire point of this
> exercise.
> 
> Maybe because driver::finalize () is not getting called so the call to
> mdswitches.release () doesn't really happen, which was the reason
> I went with std::vector in the first place because it takes care of itself.

In that case you are fixing a non-issue.
exit frees all allocated memory, no need to do it explicitly and waste
compile time cycles on it.

Leak is when some memory is allocated and pointer to it lost, that is not
the case here.

Still reachable memory at exit e.g. from valgrind is not a bug.

E.g. glibc in order to make fewer still reachable memory reports exports
a __libc_freeres function which valgrind and other memory allocation
debuggers can call on exit to free extra memory, something that isn't really
needed to waste time on normally.  But I'm not sure if there is some way
for an application to provide such functions as well.

	Jakub


  reply	other threads:[~2023-12-07 14:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-02 21:24 Costas Argyris
2023-12-04 12:15 ` Jonathan Wakely
2023-12-06 14:29   ` Costas Argyris
2023-12-06 14:39     ` Jakub Jelinek
2023-12-07 14:28       ` Costas Argyris
2023-12-07 14:42         ` Jakub Jelinek [this message]
2023-12-07 15:16           ` Costas Argyris
2023-12-07 15:42             ` Jakub Jelinek
2023-12-07 16:01               ` Costas Argyris
2023-12-07 16:04                 ` Jakub Jelinek
2023-12-08 12:18                   ` Costas Argyris
2023-12-08 13:16                     ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXHZv5Maj0rrruWO@tucnak \
    --to=jakub@redhat.com \
    --cc=costas.argyris@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).