From: Junio C Hamano <gitster@pobox.com>
To: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>,
Jeff King <peff@peff.net>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 1/1] change contract between system_path and it's callers
Date: Tue, 25 Nov 2014 13:13:24 -0800 [thread overview]
Message-ID: <xmqqfvd7rnkb.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1416939854-29930-1-git-send-email-kuleshovmail@gmail.com> (Alexander Kuleshov's message of "Wed, 26 Nov 2014 00:24:14 +0600")
Alexander Kuleshov <kuleshovmail@gmail.com> writes:
> Now system_path returns path which is allocated string to callers;
> It prevents memory leaks in some places. All callers of system_path
> are owners of path string and they must release it.
>
> Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> ---
Comparing this with what I sent out...
> builtin/help.c | 10 +++++++---
> exec_cmd.c | 17 +++++++++--------
> exec_cmd.h | 4 ++--
> git.c | 16 ++++++++++++----
> 4 files changed, 30 insertions(+), 17 deletions(-)
>
> @@ -372,7 +373,9 @@ static void show_man_page(const char *git_cmd)
> static void show_info_page(const char *git_cmd)
> {
> const char *page = cmd_to_page(git_cmd);
> - setenv("INFOPATH", system_path(GIT_INFO_PATH), 1);
> + char *git_info_path = system_path(GIT_INFO_PATH);
> + setenv("INFOPATH", git_info_path, 1);
> + free(git_info_path);
We are just about to exec; does this warrant the code churn?
> execlp("info", "info", "gitman", page, (char *)NULL);
> die(_("no info viewer handled the request"));
> @@ -34,8 +34,7 @@ const char *system_path(const char *path)
> #endif
>
> strbuf_addf(&d, "%s/%s", prefix, path);
> - path = strbuf_detach(&d, NULL);
> - return path;
> + return d.buf;
These happens to be the same with the current strbuf implementation,
but it is a good manner to use strbuf_detach(&d, NULL) here. We
don't know what other de-initialization tomorrow's implementation of
the strbuf API may have to do in strbuf_detach().
> @@ -68,16 +67,16 @@ void git_set_argv_exec_path(const char *exec_path)
>
>
> /* Returns the highest-priority, location to look for git programs. */
> -const char *git_exec_path(void)
> +char *git_exec_path(void)
> {
> const char *env;
>
> if (argv_exec_path)
> - return argv_exec_path;
> + return strdup(argv_exec_path);
>
> env = getenv(EXEC_PATH_ENVIRONMENT);
> if (env && *env) {
> - return env;
> + return strdup(env);
> }
Now you are making callers of git_exec_path() responsible for
freeing the result they receive.
git_exec_path() may be called quite a lot, which means we may end up
calling system_path() many times during the life of a process
without freeing its return value, so this change may be worth doing,
but this patch is insufficient, isn't it?
You just added load_command_list() in help.c a new leak or two, for
example. There probably are other callers of this function but I
don't have time to look at all of them myself right now.
> @@ -95,8 +94,10 @@ void setup_path(void)
> {
> const char *old_path = getenv("PATH");
> struct strbuf new_path = STRBUF_INIT;
> + char* exec_path = git_exec_path();
>
> - add_path(&new_path, git_exec_path());
> + add_path(&new_path, exec_path);
> + free(exec_path);
> add_path(&new_path, argv0_path);
This part by itself is good, provided if we make it the caller's
responsiblity to free string returned by git_exec_path().
> diff --git a/git.c b/git.c
> index 82d7a1c..d01c4f1 100644
> --- a/git.c
> +++ b/git.c
> @@ -95,17 +95,25 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
> if (*cmd == '=')
> git_set_argv_exec_path(cmd + 1);
> else {
> - puts(git_exec_path());
> + char *exec_path = git_exec_path();
> + puts(exec_path);
> + free(exec_path);
> exit(0);
> }
> } else if (!strcmp(cmd, "--html-path")) {
> - puts(system_path(GIT_HTML_PATH));
> + char *git_html_path = system_path(GIT_HTML_PATH);
> + puts(git_html_path);
> + free(git_html_path);
> exit(0);
> } else if (!strcmp(cmd, "--man-path")) {
> - puts(system_path(GIT_MAN_PATH));
> + char *git_man_path = system_path(GIT_MAN_PATH);
> + puts(git_man_path);
> + free(git_man_path);
> exit(0);
> } else if (!strcmp(cmd, "--info-path")) {
> - puts(system_path(GIT_INFO_PATH));
> + char *git_info_path = system_path(GIT_INFO_PATH);
> + puts(git_info_path);
> + free(git_info_path);
> exit(0);
> } else if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
> use_pager = 1;
None of these warrant the code churn, I would say.
next prev parent reply other threads:[~2014-11-25 21:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-23 13:56 GIT: [PATCH] exec_cmd: system_path memory leak fix 0xAX
2014-11-23 13:56 ` 0xAX
2014-11-23 14:01 ` 0xAX
2014-11-23 18:51 ` Junio C Hamano
2014-11-23 19:06 ` Alex Kuleshov
2014-11-23 19:19 ` Alex Kuleshov
2014-11-23 19:42 ` Jeff King
2014-11-23 20:07 ` Eric Sunshine
2014-11-23 21:58 ` Junio C Hamano
2014-11-24 7:02 ` Alex Kuleshov
2014-11-24 7:37 ` Junio C Hamano
2014-11-24 8:12 ` Alex Kuleshov
2014-11-24 13:11 ` Alexander Kuleshov
2014-11-24 14:00 ` Alex Kuleshov
2014-11-24 14:07 ` [PATCH] change contract between system_path and it's callers 0xAX
2014-11-24 19:33 ` Re*: " Junio C Hamano
2014-11-24 19:53 ` Alex Kuleshov
2014-11-24 20:20 ` Junio C Hamano
2014-11-24 20:50 ` Junio C Hamano
2014-11-25 6:45 ` Alexander Kuleshov
2014-11-25 7:04 ` Alexander Kuleshov
2014-11-25 17:55 ` Junio C Hamano
2014-11-25 18:03 ` Alexander Kuleshov
2014-11-25 18:24 ` [PATCH 1/1] " Alexander Kuleshov
2014-11-25 21:13 ` Junio C Hamano [this message]
2014-11-26 3:53 ` Alexander Kuleshov
2014-11-26 9:42 ` Alexander Kuleshov
2014-11-26 14:00 ` Alexander Kuleshov
2014-11-26 17:53 ` Junio C Hamano
2014-11-28 13:09 ` Philip Oakley
2014-11-25 20:20 ` Re*: [PATCH] " Junio C Hamano
2014-11-25 17:59 ` Alexander Kuleshov
2014-11-23 18:28 ` GIT: [PATCH] exec_cmd: system_path memory leak fix Junio C Hamano
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=xmqqfvd7rnkb.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kuleshovmail@gmail.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.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 NNTP newsgroup(s).