From: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
To: luke@diamand.org
Cc: christian.couder@gmail.com, git@vger.kernel.org,
newren@gmail.com, pclouds@gmail.com,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] unpack-trees.c: fix writing "link" index ext with null base oid
Date: Sat, 9 Feb 2019 18:23:28 +0700 [thread overview]
Message-ID: <20190209112328.26317-1-pclouds@gmail.com> (raw)
In-Reply-To: <CAE5ih79JYrcV9cxMBU88Hq=HHQOOyzpkq+kT2zAgDzs=ao+PMg@mail.gmail.com>
Since commit 7db118303a (unpack_trees: fix breakage when o->src_index !=
o->dst_index - 2018-04-23) and changes in merge code to use separate
index_state for source and destination, when doing a merge with split
index activated, we may run into this line in unpack_trees():
o->result.split_index = init_split_index(&o->result);
This is by itself not wrong. But this split index information is not
fully populated (and it's only so when move_cache_to_base_index() is
called, aka force splitting the index, or loading index_state from a
file). Both "base_oid" and "base" in this case remain null.
So when writing the main index down, we link to this index with null
oid (default value after init_split_index()), which also means "no split
index" internally. This triggers an incorrect base index refresh:
warning: could not freshen shared index '.../sharedindex.0{40}'
This patch makes sure we will not refresh null base_oid (because the
file is never there). It also makes sure not to write "link" extension
with null base_oid in the first place (no point having it at
all). Read code already has protection against null base_oid.
There is also another side fix in remove_split_index() that causes a
crash when doing "git update-index --no-split-index" when base_oid in
the index file is null. In this case we will not load
istate->split_index->base but we dereference it anyway and are rewarded
with a segfault. This should not happen anymore, but it's still wrong to
dereference a potential NULL pointer, especially when we do check for
NULL pointer in the next code.
Reported-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I considered adding a test, but since the problem is a warning, not
sure how to catch that. And a test would not be able to verify all
changes in this patch anyway.
read-cache.c | 5 +++--
split-index.c | 34 ++++++++++++++++++----------------
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 0e0c93edc9..d6fb09984f 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2894,7 +2894,8 @@ static int do_write_index(struct index_state *istate, struct tempfile *tempfile,
return -1;
}
- if (!strip_extensions && istate->split_index) {
+ if (!strip_extensions && istate->split_index &&
+ !is_null_oid(&istate->split_index->base_oid)) {
struct strbuf sb = STRBUF_INIT;
err = write_link_extension(&sb, istate) < 0 ||
@@ -3189,7 +3190,7 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
ret = write_split_index(istate, lock, flags);
/* Freshen the shared index only if the split-index was written */
- if (!ret && !new_shared_index) {
+ if (!ret && !new_shared_index && !is_null_oid(&si->base_oid)) {
const char *shared_index = git_path("sharedindex.%s",
oid_to_hex(&si->base_oid));
freshen_shared_index(shared_index, 1);
diff --git a/split-index.c b/split-index.c
index 5820412dc5..a9d13611a4 100644
--- a/split-index.c
+++ b/split-index.c
@@ -440,24 +440,26 @@ void add_split_index(struct index_state *istate)
void remove_split_index(struct index_state *istate)
{
if (istate->split_index) {
- /*
- * When removing the split index, we need to move
- * ownership of the mem_pool associated with the
- * base index to the main index. There may be cache entries
- * allocated from the base's memory pool that are shared with
- * the_index.cache[].
- */
- mem_pool_combine(istate->ce_mem_pool, istate->split_index->base->ce_mem_pool);
+ if (istate->split_index->base) {
+ /*
+ * When removing the split index, we need to move
+ * ownership of the mem_pool associated with the
+ * base index to the main index. There may be cache entries
+ * allocated from the base's memory pool that are shared with
+ * the_index.cache[].
+ */
+ mem_pool_combine(istate->ce_mem_pool,
+ istate->split_index->base->ce_mem_pool);
- /*
- * The split index no longer owns the mem_pool backing
- * its cache array. As we are discarding this index,
- * mark the index as having no cache entries, so it
- * will not attempt to clean up the cache entries or
- * validate them.
- */
- if (istate->split_index->base)
+ /*
+ * The split index no longer owns the mem_pool backing
+ * its cache array. As we are discarding this index,
+ * mark the index as having no cache entries, so it
+ * will not attempt to clean up the cache entries or
+ * validate them.
+ */
istate->split_index->base->cache_nr = 0;
+ }
/*
* We can discard the split index because its
--
2.20.1.682.gd5861c6d90
next prev parent reply other threads:[~2019-02-09 11:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 10:25 could not freshen shared index ..../sharedindex.0000000000000000000000000000000000000000' Luke Diamand
2019-02-06 13:17 ` Christian Couder
2019-02-08 10:02 ` Duy Nguyen
2019-02-08 16:38 ` Luke Diamand
2019-02-09 5:00 ` Duy Nguyen
2019-02-09 9:57 ` Luke Diamand
2019-02-09 10:36 ` Duy Nguyen
2019-02-09 11:23 ` Nguyễn Thái Ngọc Duy [this message]
2019-02-09 14:14 ` [PATCH] unpack-trees.c: fix writing "link" index ext with null base oid Luke Diamand
2019-02-12 5:43 ` Elijah Newren
2019-02-12 16:49 ` Junio C Hamano
2019-02-12 9:36 ` Ævar Arnfjörð Bjarmason
2019-02-13 9:51 ` [PATCH v2] read-cache.c: " Nguyễn Thái Ngọc Duy
2019-02-13 12:14 ` Ævar Arnfjörð Bjarmason
2019-02-08 17:23 ` could not freshen shared index ..../sharedindex.0000000000000000000000000000000000000000' Junio C Hamano
2019-02-09 4:56 ` Duy Nguyen
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=20190209112328.26317-1-pclouds@gmail.com \
--to=pclouds@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=luke@diamand.org \
--cc=newren@gmail.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.