# [PATCH] commit-graph: fix memory leak when not writing graph 3 messages from 2023-12-18 to 2024-01-15. Participants: Patrick Steinhardt, Taylor Blau. Thread: https://gitlist.dev/t/60624 ## Patrick Steinhardt, 2023-12-18 10:02 Subject: [PATCH] commit-graph: fix memory leak when not writing graph Message-ID: <0feab5e7d5bc6275e2c7671cd8f6786ea86fd610.1702891190.git.ps@pks.im> URL: https://gitlist.dev/e/0feab5e7d5bc6275e2c7671cd8f6786ea86fd610.1702891190.git.ps%40pks.im ``` When `write_commit_graph()` bails out writing a split commit-graph early then it may happen that we have already gathered the set of existing commit-graph file names without yet determining the new merged set of files. This can result in a memory leak though because we only clear the preimage of files when we have collected the postimage. Fix this issue by dropping the condition altogether so that we always try to free both preimage and postimage filenames. As the context structure is zero-initialized this simplification is safe to do. Signed-off-by: Patrick Steinhardt --- commit-graph.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/commit-graph.c b/commit-graph.c index acac9bf6e1..afe0177ab2 100644 --- a/commit-graph.c +++ b/commit-graph.c @@ -2617,19 +2617,16 @@ int write_commit_graph(struct object_directory *odb, oid_array_clear(&ctx->oids); clear_topo_level_slab(&topo_levels); - if (ctx->commit_graph_filenames_after) { - for (i = 0; i < ctx->num_commit_graphs_after; i++) { - free(ctx->commit_graph_filenames_after[i]); - free(ctx->commit_graph_hash_after[i]); - } - - for (i = 0; i < ctx->num_commit_graphs_before; i++) - free(ctx->commit_graph_filenames_before[i]); + for (i = 0; i < ctx->num_commit_graphs_before; i++) + free(ctx->commit_graph_filenames_before[i]); + free(ctx->commit_graph_filenames_before); - free(ctx->commit_graph_filenames_after); - free(ctx->commit_graph_filenames_before); - free(ctx->commit_graph_hash_after); + for (i = 0; i < ctx->num_commit_graphs_after; i++) { + free(ctx->commit_graph_filenames_after[i]); + free(ctx->commit_graph_hash_after[i]); } + free(ctx->commit_graph_filenames_after); + free(ctx->commit_graph_hash_after); free(ctx); base-commit: 1a87c842ece327d03d08096395969aca5e0a6996 -- 2.43.GIT ``` ## Taylor Blau, 2024-01-05 19:11 Subject: Re: [PATCH] commit-graph: fix memory leak when not writing graph Message-ID: URL: https://gitlist.dev/e/ZZhUWu5pgBEYK409%40nand.local In-Reply-To: <0feab5e7d5bc6275e2c7671cd8f6786ea86fd610.1702891190.git.ps@pks.im> ``` On Mon, Dec 18, 2023 at 11:02:28AM +0100, Patrick Steinhardt wrote: > When `write_commit_graph()` bails out writing a split commit-graph early > then it may happen that we have already gathered the set of existing > commit-graph file names without yet determining the new merged set of > files. This can result in a memory leak though because we only clear the > preimage of files when we have collected the postimage. > > Fix this issue by dropping the condition altogether so that we always > try to free both preimage and postimage filenames. As the context > structure is zero-initialized this simplification is safe to do. Looks obviously good to me, thanks for finding and fixing. Thanks, Taylor ``` ## Patrick Steinhardt, 2024-01-15 07:08 Subject: Re: [PATCH] commit-graph: fix memory leak when not writing graph Message-ID: URL: https://gitlist.dev/e/ZaTaBN2Xc61sVvTJ%40tanuki In-Reply-To: ``` On Fri, Jan 05, 2024 at 02:11:22PM -0500, Taylor Blau wrote: > On Mon, Dec 18, 2023 at 11:02:28AM +0100, Patrick Steinhardt wrote: > > When `write_commit_graph()` bails out writing a split commit-graph early > > then it may happen that we have already gathered the set of existing > > commit-graph file names without yet determining the new merged set of > > files. This can result in a memory leak though because we only clear the > > preimage of files when we have collected the postimage. > > > > Fix this issue by dropping the condition altogether so that we always > > try to free both preimage and postimage filenames. As the context > > structure is zero-initialized this simplification is safe to do. > > Looks obviously good to me, thanks for finding and fixing. Cc'ing Junio so that this fix doesn't fall off the radar. I thought I saw the topic in "seen" once, but either I misremember or it got dropped from there. Patrick ```