Re: What's cooking in git.git (Sep 2016, #03; Fri, 9)

2 messages, 2 authors, 2016-09-12 · open the first message on its own page

Re: What's cooking in git.git (Sep 2016, #03; Fri, 9)

From: Junio C Hamano <hidden>
Date: 2016-09-12 19:10:27

Jeff King [off-list ref] writes:
I happened to notice today that this topic needs a minor tweak:

-- >8 --
Subject: [PATCH] add_delta_base_cache: use list_for_each_safe

We may remove elements from the list while we are iterating,
which requires using a second temporary pointer. Otherwise
stepping to the next element of the list might involve
looking at freed memory (which generally works in practice,
as we _just_ freed it, but of course is wrong to rely on;
valgrind notices it).
I failed to notice it, too.  Thanks.
quoted hunk
Signed-off-by: Jeff King <redacted>
---
 sha1_file.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index a57b71d..132c861 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2187,11 +2187,11 @@ static void add_delta_base_cache(struct packed_git *p, off_t base_offset,
 	void *base, unsigned long base_size, enum object_type type)
 {
 	struct delta_base_cache_entry *ent = xmalloc(sizeof(*ent));
-	struct list_head *lru;
+	struct list_head *lru, *tmp;
 
 	delta_base_cached += base_size;
 
-	list_for_each(lru, &delta_base_cache_lru) {
+	list_for_each_safe(lru, tmp, &delta_base_cache_lru) {
 		struct delta_base_cache_entry *f =
 			list_entry(lru, struct delta_base_cache_entry, lru);
 		if (delta_base_cached <= delta_base_cache_limit)

Re: What's cooking in git.git (Sep 2016, #03; Fri, 9)

From: Jeff King <hidden>
Date: 2016-09-12 21:46:34

On Mon, Sep 12, 2016 at 12:10:13PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
I happened to notice today that this topic needs a minor tweak:

-- >8 --
Subject: [PATCH] add_delta_base_cache: use list_for_each_safe

We may remove elements from the list while we are iterating,
which requires using a second temporary pointer. Otherwise
stepping to the next element of the list might involve
looking at freed memory (which generally works in practice,
as we _just_ freed it, but of course is wrong to rely on;
valgrind notices it).
I failed to notice it, too.  Thanks.
After staring at this, I was wondering how the _original_ ever worked.
Because the problem is in the linked-list code, which I did not really
change (I switched it to LIST_HEAD(), but the code is equivalent).

The answer is that in the original, there was no free() in the original
code when we released an entry; it just went back to the (static) pool.

So the bug is in the conversion to hashmap, where we start allocating
(and freeing) the entries individually.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help