git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 08/10] commit-graph: free write-context entries before overwriting
Date: Thu, 5 Oct 2023 13:51:42 -0400	[thread overview]
Message-ID: <ZR73rpsKiTBF/rYj@nand.local> (raw)
In-Reply-To: <20231003203055.GH7812@coredump.intra.peff.net>

On Tue, Oct 03, 2023 at 04:30:55PM -0400, Jeff King wrote:
> diff --git a/commit-graph.c b/commit-graph.c
> index 4aa2f294f1..744b7eb1a3 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -2065,9 +2065,11 @@ static int write_commit_graph_file(struct write_commit_graph_context *ctx)
>  			free(graph_name);
>  		}
>
> +		free(ctx->commit_graph_hash_after[ctx->num_commit_graphs_after - 1]);
>  		ctx->commit_graph_hash_after[ctx->num_commit_graphs_after - 1] = xstrdup(hash_to_hex(file_hash));
>  		final_graph_name = get_split_graph_filename(ctx->odb,
>  					ctx->commit_graph_hash_after[ctx->num_commit_graphs_after - 1]);
> +		free(ctx->commit_graph_filenames_after[ctx->num_commit_graphs_after - 1]);
>  		ctx->commit_graph_filenames_after[ctx->num_commit_graphs_after - 1] = final_graph_name;
>
>  		result = rename(ctx->graph_name, final_graph_name);

This hunk makes sense. It might be nice in the future to do something
like:

--- 8< ---
diff --git a/commit-graph.c b/commit-graph.c
index 5e8a3a5085..cadccbe276 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -59,7 +59,7 @@ void git_test_write_commit_graph_or_die(void)

 #define GRAPH_EXTRA_EDGES_NEEDED 0x80000000
 #define GRAPH_EDGE_LAST_MASK 0x7fffffff
-#define GRAPH_PARENT_NONE 0x70000000
+tdefine GRAPH_PARENT_NONE 0x70000000

 #define GRAPH_LAST_EDGE 0x80000000

@@ -1033,11 +1033,11 @@ struct write_commit_graph_context {
 	uint64_t progress_cnt;

 	char *base_graph_name;
-	int num_commit_graphs_before;
-	int num_commit_graphs_after;
-	char **commit_graph_filenames_before;
-	char **commit_graph_filenames_after;
-	char **commit_graph_hash_after;
+	struct {
+		size_t nr;
+		char **fname;
+		char **hash;
+	} graphs_before, graphs_after;
 	uint32_t new_num_commits_in_base;
 	struct commit_graph *new_base_graph;
--- >8 ---

...making the corresponding changes throughout the rest of the file. But
that is definitely out of scope here, and could easily be left for
another day.

#leftoverbits

Thanks,
Taylor

  reply	other threads:[~2023-10-05 17:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 20:25 [PATCH 0/10] some commit-graph leak fixes Jeff King
2023-10-03 20:26 ` [PATCH 01/10] t6700: mark test as leak-free Jeff King
2023-10-05 17:40   ` Taylor Blau
2023-10-03 20:26 ` [PATCH 02/10] commit-reach: free temporary list in get_octopus_merge_bases() Jeff King
2023-10-03 20:27 ` [PATCH 03/10] merge: free result of repo_get_merge_bases() Jeff King
2023-10-05 17:42   ` Taylor Blau
2023-10-03 20:27 ` [PATCH 04/10] commit-graph: move slab-clearing to close_commit_graph() Jeff King
2023-10-05 17:42   ` Taylor Blau
2023-10-03 20:29 ` [PATCH 05/10] commit-graph: free all elements of graph chain Jeff King
2023-10-03 20:30 ` [PATCH 06/10] commit-graph: delay base_graph assignment in add_graph_to_chain() Jeff King
2023-10-05 17:44   ` Taylor Blau
2023-10-03 20:30 ` [PATCH 07/10] commit-graph: free graph struct that was not added to chain Jeff King
2023-10-03 20:30 ` [PATCH 08/10] commit-graph: free write-context entries before overwriting Jeff King
2023-10-05 17:51   ` Taylor Blau [this message]
2023-10-05 21:03     ` Jeff King
2023-10-03 20:31 ` [PATCH 09/10] commit-graph: free write-context base_graph_name during cleanup Jeff King
2023-10-03 20:31 ` [PATCH 10/10] commit-graph: clear oidset after finishing write Jeff King
2023-10-04  1:33 ` Is SANITIZE=leak make test unreliable for anyone else? Eric W. Biederman
2023-10-04 13:21   ` Jeff King
2023-10-04 14:19     ` Eric W. Biederman
2023-10-04 14:47       ` Jeff King
2023-10-04 15:38         ` Eric W. Biederman
2023-10-05 17:52 ` [PATCH 0/10] some commit-graph leak fixes Taylor Blau
2023-10-06  0:39   ` 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=ZR73rpsKiTBF/rYj@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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).