From: Junio C Hamano <gitster@pobox•com>
To: Lukas Fleischer <git@cryptocrack•de>
Cc: git@vger•kernel.org, Jeff King <peff@peff•net>
Subject: Re: [PATCH] blame.c: fix garbled error message
Date: Mon, 12 Jan 2015 14:55:30 -0800 [thread overview]
Message-ID: <xmqqzj9n623h.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqq4mrv95qt.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Mon, 12 Jan 2015 11:08:26 -0800")
Junio C Hamano <gitster@pobox•com> writes:
> Lukas Fleischer <git@cryptocrack•de> writes:
>
>> The helper functions prepare_final() and prepare_initial() return a
>> pointer to a string that is a member of an object in the revs->pending
>> array. This array is later rebuilt when running prepare_revision_walk()
>> which potentially transforms the pointer target into a bogus string. Fix
>> this by maintaining a copy of the original string.
>>
>> Signed-off-by: Lukas Fleischer <git@cryptocrack•de>
>> ---
>> The bug manifests when running `git blame HEAD^ -- nonexistent.file`.
>
> Before 1da1e07c (clean up name allocation in prepare_revision_walk,
> 2014-10-15), these strings used to be non-volatile; they were instead
> leaked more or less deliberately. But these days, these strings are
> cleared, so your patch is absolutely the right thing to do.
>
> Thanks for catching and fixing. This fix needs to go to the 2.2.x
> maintenance track.
Sigh, but not so fast.
With the patch applied on top of 1da1e07c (or the result merged to
'next' for that matter), I see test breakages in many places "git
blame" is used, e.g. t7010. Did you run the test suite?
This is because it is perfectly normal for prepare_final() to return
NULL. Unconditionally running xstrdup() would of course fail.
>> Note that I could have reduced code churn a little by moving the
>> xstrdup() invocations to the call sites. However, I think that the
>> return value of these functions should not depend on the consistency of
>> a volatile data structure. On the other hand, you might also argue that
>> there currently are only two call sites and that the functions are
>> marked static, so if you prefer the less intrusive version, please let
>> me know.
>
> FWIW, I agree that this can be argued either way.
>
> If we had a common low-level API that is used by short-term users to
> grab these names, it would be reasonable to make it the callers'
> responsibility to strdup() the return values for safekeeping if they
> want to keep using them long after the function returns. But I
> agree that prepare_final/prepare_initial are not such a low-level
> common API functions. I do not care too much about who does the
> strdup(), either the callers of prepare_* or the callee.
>
>>
>> builtin/blame.c | 12 +++++++-----
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/builtin/blame.c b/builtin/blame.c
>> index 303e217..34d6f4f 100644
>> --- a/builtin/blame.c
>> +++ b/builtin/blame.c
>> @@ -2390,7 +2390,7 @@ static struct commit *fake_working_tree_commit(struct diff_options *opt,
>> return commit;
>> }
>>
>> -static const char *prepare_final(struct scoreboard *sb)
>> +static char *prepare_final(struct scoreboard *sb)
>> {
>> int i;
>> const char *final_commit_name = NULL;
>> @@ -2415,10 +2415,10 @@ static const char *prepare_final(struct scoreboard *sb)
>> sb->final = (struct commit *) obj;
>> final_commit_name = revs->pending.objects[i].name;
>> }
>> - return final_commit_name;
>> + return xstrdup(final_commit_name);
>> }
>>
>> -static const char *prepare_initial(struct scoreboard *sb)
>> +static char *prepare_initial(struct scoreboard *sb)
>> {
>> int i;
>> const char *final_commit_name = NULL;
>> @@ -2445,7 +2445,7 @@ static const char *prepare_initial(struct scoreboard *sb)
>> }
>> if (!final_commit_name)
>> die("No commit to dig down to?");
>> - return final_commit_name;
>> + return xstrdup(final_commit_name);
>> }
>>
>> static int blame_copy_callback(const struct option *option, const char *arg, int unset)
>> @@ -2489,7 +2489,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
>> struct origin *o;
>> struct blame_entry *ent = NULL;
>> long dashdash_pos, lno;
>> - const char *final_commit_name = NULL;
>> + char *final_commit_name = NULL;
>> enum object_type type;
>>
>> static struct string_list range_list;
>> @@ -2786,6 +2786,8 @@ parse_done:
>>
>> assign_blame(&sb, opt);
>>
>> + free(final_commit_name);
>> +
>> if (incremental)
>> return 0;
next prev parent reply other threads:[~2015-01-12 22:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-10 21:33 [PATCH] blame.c: fix garbled error message Lukas Fleischer
2015-01-12 19:08 ` Junio C Hamano
2015-01-12 20:40 ` Jeff King
2015-01-12 22:55 ` Junio C Hamano [this message]
2015-01-12 23:12 ` Jeff King
2015-01-13 0:11 ` Junio C Hamano
2015-01-13 1:54 ` Jeff King
2015-01-13 1:57 ` [PATCH 1/5] git-compat-util: add xstrdup_or_null helper Jeff King
2015-01-13 2:21 ` Jonathan Nieder
2015-01-13 2:23 ` Jeff King
2015-01-13 1:58 ` [PATCH 2/5] builtin/apply.c: use xstrdup_or_null instead of null_strdup Jeff King
2015-01-13 1:58 ` [PATCH 3/5] builtin/commit.c: use xstrdup_or_null instead of envdup Jeff King
2015-01-13 1:59 ` [PATCH 4/5] use xstrdup_or_null to replace ternary conditionals Jeff King
2015-01-13 1:59 ` [PATCH 5/5] blame.c: fix garbled error message Jeff King
2015-01-14 14:21 ` [PATCH] " Lukas Fleischer
2015-01-14 17:22 ` Junio C Hamano
2015-01-14 20:49 ` Jeff King
2015-01-14 21:54 ` Junio C Hamano
2015-01-12 23:18 ` Lukas Fleischer
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=xmqqzj9n623h.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@cryptocrack$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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