From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Ronnie Sahlberg <sahlberg@google.com>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: [PATCH 3/5] fast-import: clean up pack_data pointer in end_packfile
Date: Sat, 23 Aug 2014 01:27:41 -0400 [thread overview]
Message-ID: <20140823052741.GC18075@peff.net> (raw)
In-Reply-To: <20140823052334.GA17813@peff.net>
We have a global pointer pack_data pointing to the current
pack we have open. Inside end_packfile we have two new
pointers, old_p and new_p. The latter points to pack_data,
and the former points to the new "installed" version of the
packfile we get when we hand the file off to the regular
sha1_file machinery. When then free old_p.
Presumably the extra old_p pointer was there so that we
could overwrite pack_data with new_p and still free old_p,
but we don't do that. We just leave pack_data pointing to
bogus memory, and don't overwrite it until we call
start_packfile again (if ever).
This can cause problems for our die routine, which calls
end_packfile to clean things up. If we die at the wrong
moment, we can end up looking at invalid memory in
pack_data left after the last end_packfile().
Instead, let's make sure we set pack_data to NULL after we
free it, and make calling endfile() again with a NULL
pack_data a noop (there is nothing to end).
We can further make things less confusing by dropping old_p
entirely, and moving new_p closer to its point of use.
Signed-off-by: Jeff King <peff@peff.net>
---
Noticed while running fast-import under valgrind to debug the next
commit. :)
fast-import.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index d73f58c..f25a4ae 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -946,10 +946,12 @@ static void unkeep_all_packs(void)
static void end_packfile(void)
{
- struct packed_git *old_p = pack_data, *new_p;
+ if (!pack_data)
+ return;
clear_delta_base_cache();
if (object_count) {
+ struct packed_git *new_p;
unsigned char cur_pack_sha1[20];
char *idx_name;
int i;
@@ -991,10 +993,11 @@ static void end_packfile(void)
pack_id++;
}
else {
- close(old_p->pack_fd);
- unlink_or_warn(old_p->pack_name);
+ close(pack_data->pack_fd);
+ unlink_or_warn(pack_data->pack_name);
}
- free(old_p);
+ free(pack_data);
+ pack_data = NULL;
/* We can't carry a delta across packfiles. */
strbuf_release(&last_blob.data);
--
2.1.0.346.ga0367b9
next prev parent reply other threads:[~2014-08-23 5:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 5:23 [PATCH 0/5] fix pack-refs pruning of refs/foo Jeff King
2014-08-23 5:26 ` [PATCH 1/5] git-prompt: do not look for refs/stash in $GIT_DIR Jeff King
2014-08-23 5:27 ` [PATCH 2/5] pack-refs: prune top-level refs like "refs/foo" Jeff King
2014-08-23 5:27 ` Jeff King [this message]
2014-08-25 17:16 ` [PATCH 3/5] fast-import: clean up pack_data pointer in end_packfile Ronnie Sahlberg
2014-08-25 18:55 ` Jeff King
2014-08-23 5:32 ` [PATCH 4/5] fast-import: fix buffer overflow in dump_tags Jeff King
2014-08-25 17:11 ` Ronnie Sahlberg
2014-08-23 5:33 ` [PATCH 5/5] fast-import: stop using lock_ref_sha1 Jeff King
2014-08-25 17:22 ` Ronnie Sahlberg
2014-08-23 7:29 ` [PATCH 0/5] fix pack-refs pruning of refs/foo Michael Haggerty
2014-08-23 7:46 ` Jeff King
2014-08-25 17:38 ` Ronnie Sahlberg
2014-08-25 18:56 ` Jeff King
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=20140823052741.GC18075@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=sahlberg@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.