threads / patch / 10753

patch, 11 partsgit-fetch: Release objects used by a prior transport

Subject: [PATCH 06/11] git-fetch: Release objects used by a prior transport

## tl;dr

3 messages between Nov 9, 2007 and Nov 11, 2007. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Shawn O. Pearce· Nov 9, 2007, 11:06 UTC · lore

Some transports allocate objects in the internal object hashtable during the fetch process (e.g. the HTTP commit walker and also the native protocol). These shouldn't be visible to another transport call running in the same fetch process when we fetch the tags during automated tag following. By deallocating the object table (if it has anything in it) we ensure the second transport execution will be from a clean slate.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 builtin-fetch.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
Show changes to builtin-fetch.c +4 −1
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 847db73..18f123e 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -337,7 +337,10 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
 
 static int fetch_refs(struct transport *transport, struct ref *ref_map)
 {
-	int ret = transport_fetch_refs(transport, ref_map);
+	int ret;
+
+	free_all_objects();
+	ret = transport_fetch_refs(transport, ref_map);
 	if (!ret)
 		store_updated_refs(transport->url, ref_map);
 	transport_unlock_pack(transport);
-- 
1.5.3.5.1622.g41d10
Junio C Hamano· Nov 9, 2007, 22:27 UTC · re: Shawn O. Pearce · lore

Re: [PATCH 06/11] git-fetch: Release objects used by a prior transport

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 29 quoted lines
> Some transports allocate objects in the internal object hashtable
> during the fetch process (e.g. the HTTP commit walker and also the
> native protocol).  These shouldn't be visible to another transport
> call running in the same fetch process when we fetch the tags during
> automated tag following.  By deallocating the object table (if it
> has anything in it) we ensure the second transport execution will
> be from a clean slate.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>  builtin-fetch.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index 847db73..18f123e 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> @@ -337,7 +337,10 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
>  
>  static int fetch_refs(struct transport *transport, struct ref *ref_map)
>  {
> -	int ret = transport_fetch_refs(transport, ref_map);
> +	int ret;
> +
> +	free_all_objects();
> +	ret = transport_fetch_refs(transport, ref_map);
>  	if (!ret)
>  		store_updated_refs(transport->url, ref_map);
>  	transport_unlock_pack(transport);
This sounds a very heavy-handed approach.

Is it the callers responsibility to know what function does call free_all_objects() and makes sure there is no pointer to objects obtained before the call that is used after the call returns?

Shawn O. Pearce· Nov 11, 2007, 05:29 UTC · re: Junio C Hamano · lore

Re: [PATCH 06/11] git-fetch: Release objects used by a prior transport

Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > diff --git a/builtin-fetch.c b/builtin-fetch.c
> > index 847db73..18f123e 100644
> > --- a/builtin-fetch.c
> > +++ b/builtin-fetch.c
> > @@ -337,7 +337,10 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
> >  
> >  static int fetch_refs(struct transport *transport, struct ref *ref_map)
> >  {
> > -	int ret = transport_fetch_refs(transport, ref_map);
> > +	int ret;
> > +
> > +	free_all_objects();
> > +	ret = transport_fetch_refs(transport, ref_map);
> >  	if (!ret)
> >  		store_updated_refs(transport->url, ref_map);
> >  	transport_unlock_pack(transport);
> 
> This sounds a very heavy-handed approach.
> 
> Is it the callers responsibility to know what function does call
> free_all_objects() and makes sure there is no pointer to objects
> obtained before the call that is used after the call returns?

Yea, I guess it is. That's part of the reason why this usage was put here in a static function of builtin-fetch. Its high enough up in the call stack that nobody above it cares. Where we would run into trouble would be if a transport decided to hang onto any pointers in its data structure between calls to the transport.

Lets just say we don't free the objects; the flags are still all messed up from any prior user. Its tricky to reuse the objects because we don't know what state an object is left in by someone that ran before us (e.g. an internal call to fetch-pack!). Its also tricky when they free the parent list but leave parsed=1; we can't rebuild the parent pointers!

-- 
Shawn.

← back to recent threads