Emily M Klassen <forivall@xxxxxxxxx> writes:
> "git log --graph --no-graph" missed cleaning up the output_prefix and
> output_prefix_data pointers. This resulted in a segfault when using "--patch",
> "--name-status" or "--name-only", as the output_prefix_data continued to be in
> use after free()
>
> Signed-off-by: Emily M Klassen <forivall@xxxxxxxxx>
> ---
> I previously reported this a few hours ago, and ended up digging in and figuring
> it out. I'll make sure to bottom reply in the follow ups to this patch.
>
> revision.c | 2 ++
> 1 file changed, 2 insertions(+)
Reading the symptom in the proposed log message (which is very
clearly written, by the way), it seems that this is reproducible?
Can we have a test to make sure that the fix would not be broken
later?
> diff --git a/revision.c b/revision.c
> index 474fa1e767..84cb028e11 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2615,6 +2615,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> graph_clear(revs->graph);
> revs->graph = graph_init(revs);
> } else if (!strcmp(arg, "--no-graph")) {
> + revs->diffopt.output_prefix = NULL;
> + revs->diffopt.output_prefix_data = NULL;
> graph_clear(revs->graph);
> revs->graph = NULL;
> } else if (!strcmp(arg, "--encode-email-headers")) {
Interesting.
In response to "--graph" (the code we can see in the context before
this part), we clear the revs->graph and then call graph_init(revs)
for ourselves, and we do not have to futz with diffopt at all, and
it works OK because output_prefix_data and output_prefix would be
overwritten by the graph_init() to the value we want to use anyway.
But of course, after "--no-graph", nobody clears these two members
for us, so we'd need to clear them here.
It might make the API less error-prone if the "clear" function
cleared the .graph and diffopt->output_prefix{,_data} together
but among three existing callers of graph_clear(), only this caller
needs to clear these two members, so it probably would not matter.
So in short, this seems to be a good fix for the immediate issue,
and it is unlikely that we'd need any follow-up work.
