threads / patch / 34185

patch, 2 partsbuiltin/checkout.c: don't leak memory in check_tracking_name

Subject: [PATCH 1/2] builtin/checkout.c: don't leak memory in check_tracking_name

## tl;dr

5 messages between Jun 18, 2013 and Jun 18, 2013. Diffs are folded; open one to read it.

replies: 4people: 4as markdown or json

Brandon Casey· Jun 18, 2013, 01:40 UTC · lore
From: Brandon Casey <drafnel@gmail.com>

remote_find_tracking() populates the query struct with an allocated string in the dst member. So, we do not need to xstrdup() the string, since we can transfer ownership from the query struct (which will go out of scope at the end of this function) to our callback struct, but we must free the string if it will not be used so we will not leak memory.

Let's do so.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
 builtin/checkout.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
Show changes to builtin/checkout.c +5 −2
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f5b50e5..3be0018 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -838,13 +838,16 @@ static int check_tracking_name(struct remote *remote, void *cb_data)
 	memset(&query, 0, sizeof(struct refspec));
 	query.src = cb->src_ref;
 	if (remote_find_tracking(remote, &query) ||
-	    get_sha1(query.dst, cb->dst_sha1))
+	    get_sha1(query.dst, cb->dst_sha1)) {
+		free(query.dst);
 		return 0;
+	}
 	if (cb->dst_ref) {
+		free(query.dst);
 		cb->unique = 0;
 		return 0;
 	}
-	cb->dst_ref = xstrdup(query.dst);
+	cb->dst_ref = query.dst;
 	return 0;
 }
 

-- 
1.8.2.415.g63cec41
Brandon Casey· Jun 18, 2013, 01:40 UTC · re: Brandon Casey · lore

[PATCH 2/2] t/t9802: explicitly name the upstream branch to use as a base

From: Brandon Casey <drafnel@gmail.com>

Prior to commit fa83a33b, the 'git checkout' DWIMery would create a new local branch if the specified branch name did not exist and it matched exactly one ref in the "remotes" namespace. It searched the "remotes" namespace for matching refs using a simple comparison of the trailing portion of the remote ref names. This approach could sometimes produce false positives or negatives.

Since fa83a33b, the DWIMery more strictly excludes the remote name from the ref comparison by iterating through the remotes that are configured in the .gitconfig file. This has the side-effect that any refs that exist in the "remotes" namespace, but do not match the destination side of any remote refspec, will not be used by the DWIMery.

This change in behavior breaks the tests in t9802 which relied on the old behavior of searching all refs in the remotes namespace, since the git-p4 script does not configure any remotes in the .gitconfig. Let's work around this in these tests by explicitly naming the upstream branch to base the new local branch on when calling 'git checkout'.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
 t/t9802-git-p4-filetype.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/t9802-git-p4-filetype.sh +2 −2
diff --git a/t/t9802-git-p4-filetype.sh b/t/t9802-git-p4-filetype.sh
index eeefa67..b0d1d94 100755
--- a/t/t9802-git-p4-filetype.sh
+++ b/t/t9802-git-p4-filetype.sh
@@ -95,7 +95,7 @@ test_expect_success 'gitattributes setting eol=lf produces lf newlines' '
 		git init &&
 		echo "* eol=lf" >.gitattributes &&
 		git p4 sync //depot@all &&
-		git checkout master &&
+		git checkout -b master p4/master &&
 		test_cmp "$cli"/f-unix-orig f-unix &&
 		test_cmp "$cli"/f-win-as-lf f-win
 	)
@@ -109,7 +109,7 @@ test_expect_success 'gitattributes setting eol=crlf produces crlf newlines' '
 		git init &&
 		echo "* eol=crlf" >.gitattributes &&
 		git p4 sync //depot@all &&
-		git checkout master &&
+		git checkout -b master p4/master &&
 		test_cmp "$cli"/f-unix-as-crlf f-unix &&
 		test_cmp "$cli"/f-win-orig f-win
 	)

-- 
1.8.2.415.g63cec41
Pete Wyckoff· Jun 18, 2013, 13:42 UTC · re: Brandon Casey · lore

Re: [PATCH 2/2] t/t9802: explicitly name the upstream branch to use as a base

bcasey@nvidia.com wrote on Mon, 17 Jun 2013 18:40 -0700:
Show 22 quoted lines
> From: Brandon Casey <drafnel@gmail.com>
> 
> Prior to commit fa83a33b, the 'git checkout' DWIMery would create a
> new local branch if the specified branch name did not exist and it
> matched exactly one ref in the "remotes" namespace.  It searched
> the "remotes" namespace for matching refs using a simple comparison
> of the trailing portion of the remote ref names.  This approach
> could sometimes produce false positives or negatives.
> 
> Since fa83a33b, the DWIMery more strictly excludes the remote name
> from the ref comparison by iterating through the remotes that are
> configured in the .gitconfig file.  This has the side-effect that
> any refs that exist in the "remotes" namespace, but do not match
> the destination side of any remote refspec, will not be used by
> the DWIMery.
> 
> This change in behavior breaks the tests in t9802 which relied on
> the old behavior of searching all refs in the remotes namespace,
> since the git-p4 script does not configure any remotes in the
> .gitconfig.  Let's work around this in these tests by explicitly
> naming the upstream branch to base the new local branch on when
> calling 'git checkout'.

Thanks for finding and fixing this. Great explanation. I tested it locally too.

Acked-by: Pete Wyckoff <pw@padd.com>
		-- Pete
Junio C Hamano· Jun 18, 2013, 16:17 UTC · re: Pete Wyckoff · lore

Re: [PATCH 2/2] t/t9802: explicitly name the upstream branch to use as a base

Pete Wyckoff <pw@padd.com> writes:
> Thanks for finding and fixing this.  Great explanation.  I
> tested it locally too.
>
> Acked-by: Pete Wyckoff <pw@padd.com>
Thanks, both.  Queued.
Jeff King· Jun 18, 2013, 06:15 UTC · re: Brandon Casey · lore

Re: [PATCH 1/2] builtin/checkout.c: don't leak memory in check_tracking_name

On Mon, Jun 17, 2013 at 06:40:49PM -0700, Brandon Casey wrote:
Show 10 quoted lines
> From: Brandon Casey <drafnel@gmail.com>
> 
> remote_find_tracking() populates the query struct with an allocated
> string in the dst member.  So, we do not need to xstrdup() the string,
> since we can transfer ownership from the query struct (which will go
> out of scope at the end of this function) to our callback struct, but
> we must free the string if it will not be used so we will not leak
> memory.
> 
> Let's do so.

Thanks, looks obviously correct. I wonder if other callers of remote_find_tracking make the same mistake. It looks like check_tracking_branch does. And add_branch_for_removal. and append_ref_to_tracked_list. Yeesh.

-Peff

← back to recent threads