All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "Martin Ågren" <martin.agren@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] config: free resources of `struct config_store_data`
Date: Sun, 13 May 2018 04:59:13 -0400	[thread overview]
Message-ID: <CAPig+cThT3VVw75VF0wuF-yR-xbnfNOxhviYGZLAksF8HFuOGw@mail.gmail.com> (raw)
In-Reply-To: <20180513082303.19582-1-martin.agren@gmail.com>

On Sun, May 13, 2018 at 4:23 AM Martin Ågren <martin.agren@gmail.com> wrote:
> Commit fee8572c6d (config: avoid using the global variable `store`,
> 2018-04-09) dropped the staticness of a certain struct, instead letting
> the users create an instance on the stack and pass around a pointer.

> We do not free the memory that the struct tracks. When the struct was
> static, the memory would always be reachable. Now that we keep the
> struct on the stack, though, as soon as we return, it goes out of scope
> and we leak the memory it points to.

> Introduce and use a small helper function `config_store_data_clear()` to
> plug these leaks. This should be safe. The memory tracked here is config
> parser events. Once the users (`git_config_set_multivar_in_file_gently()`
> and `git_config_copy_or_rename_section_in_file()` at the moment) are
> done, no-one should be holding on to a pointer into this memory.

> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
> ---
> diff --git a/config.c b/config.c
> @@ -2333,6 +2333,13 @@ struct config_store_data {
> +void config_store_data_clear(struct config_store_data *store)
> +{
> +       free(store->parsed);
> +       free(store->seen);
> +       memset(store, 0, sizeof(*store));
> +}

A newcomer to this code (such as myself) might legitimately wonder why
store->key and store->value_regex are not also being cleaned up by this
function. An examination of the relevant code reveals that those structure
members are manually (and perhaps tediously) freed already by
git_config_set_multivar_in_file_gently(), however, if
config_store_data_clear() was responsible for freeing them, then
git_config_set_multivar_in_file_gently() could be made a bit less noisy.

On the other hand, if there's actually a good reason for
  config_store_data_clear() not freeing those members, then perhaps it
deserves an in-code comment explaining why they are exempt.

  reply	other threads:[~2018-05-13  8:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-13  8:23 [PATCH] config: free resources of `struct config_store_data` Martin Ågren
2018-05-13  8:59 ` Eric Sunshine [this message]
2018-05-13  9:58   ` Martin Ågren
2018-05-13  9:58     ` [PATCH 2/1] config: let `config_store_data_clear()` handle `value_regex` Martin Ågren
2018-05-14  3:05       ` Eric Sunshine
2018-05-20 10:50         ` [PATCH] regex: do not call `regfree()` if compilation fails Martin Ågren
2018-05-21 18:43           ` Stefan Beller
2018-05-22  2:20             ` Eric Sunshine
2018-05-22 11:00               ` Martin Ågren
2018-05-13  9:58     ` [PATCH 3/1] config: let `config_store_data_clear()` handle `key` Martin Ågren
2018-05-14  3:03     ` [PATCH] config: free resources of `struct config_store_data` Eric Sunshine
2018-05-20 10:42       ` [PATCH v2 0/3] " Martin Ågren
2018-05-20 10:42         ` [PATCH v2 1/3] " Martin Ågren
2018-05-20 10:42         ` [PATCH v2 2/3] config: let `config_store_data_clear()` handle `value_regex` Martin Ågren
2018-05-20 10:42         ` [PATCH v2 3/3] config: let `config_store_data_clear()` handle `key` Martin Ågren
2018-05-23  7:03           ` Eric Sunshine
2018-05-23  7:01         ` [PATCH v2 0/3] config: free resources of `struct config_store_data` Eric Sunshine
2018-05-13 18:40 ` [PATCH] " Martin Ågren

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=CAPig+cThT3VVw75VF0wuF-yR-xbnfNOxhviYGZLAksF8HFuOGw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=martin.agren@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.