git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: regression in 92392b4

From
Pierre Habouzit <madcoder@debian.org>
Date
Jul 22, 2008, 23:37 UTC
Message-ID
<20080722233716.GE11831@artemis.madism.org>
In-Reply-To
<20080722231745.GD11831@artemis.madism.org>
On Tue, Jul 22, 2008 at 11:17:45PM +0000, Pierre Habouzit wrote:
Show 41 quoted lines
>   Hi, here is a manual painful down-secting (opposed to a bisect ;P) I
> did, since git in next cannot fetch on a regular basis for me. The
> culprit seems to be commit  92392b4:
> 
>     ┌─(1:11)──<~/dev/scm/git 92392b4...>──
>     └[artemis] git fetch
>     remote: Counting objects: 461, done.
>     remote: Compressing objects: 100% (141/141), done.
>     remote: Total 263 (delta 227), reused 155 (delta 121)
>     Receiving objects: 100% (263/263), 95.55 KiB, done.
>     fatal: Out of memory, malloc failed
>     fatal: index-pack failed
>     [2]    16674 abort (core dumped)  git fetch
> 
>     ┌─(1:12)──<~/dev/scm/git 92392b4...>──
>     └[artemis] git checkout -m HEAD~1; make git-index-pack
>     Previous HEAD position was 92392b4... index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
>     HEAD is now at 03993e1... index-pack: Track the object_entry that creates each base_data
>     GIT_VERSION = 1.5.6.3.3.g03993
> 	CC index-pack.o
> 	LINK git-index-pack
> 
>     ┌─(1:12)──<~/dev/scm/git 03993e1...>──
>     └[artemis] git fetch
>     remote: Counting objects: 461, done.
>     remote: Compressing objects: 100% (141/141), done.
>     remote: Total 263 (delta 227), reused 155 (delta 121)
>     Receiving objects: 100% (263/263), 95.55 KiB, done.
>     Resolving deltas: 100% (227/227), completed with 153 local objects.
>     From git://git.kernel.org/pub/scm/git/git
>        5ba2c22..0868a30  html       -> origin/html
>        2857e17..abeeabe  man        -> origin/man
>        93310a4..95f8ebb  master     -> origin/master
>        559998f..e8bf351  next       -> origin/next
> 
> You can see the commit sha's in the prompt. 03993e1 is fine, 92392b4 is
> broken, I've absolutely no clue about what happens.
> 
> All I can say is that at some point in get_data_from_pack, obj[1].idx
> points to something that is *not* a sha so it's probably corrupted.
> (from index-pack.c).
  Though reading the code, we trust c->data NULL-iness to mean we have
no data, and there is one code path that fails to reset it. The problem
is I'm not able to reproduce the bug, because I foolishly didn't
backuped the git repository that exhibited the failure, so I cannot know
if that can be the problem:
--- snip ---
From c3749f7bc50c642c5d437b2746d4ba589b7d9739 Mon Sep 17 00:00:00 2001
From: Pierre Habouzit <madcoder@debian.org>
Date: Wed, 23 Jul 2008 01:35:11 +0200
Subject: [PATCH] index-pack: missing pointer reset to NULL.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
 index-pack.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index ac20a46..19c39e5 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -257,6 +257,7 @@ static void unlink_base_data(struct base_data *c)
 		base_cache = NULL;
 	if (c->data) {
 		free(c->data);
+		c->data = NULL;
 		base_cache_used -= c->size;
 	}
 }
-- 
1.6.0.rc0.153.ge8bf3.dirty
Previous: Johannes SchindelinNext: Björn Steinbrink
Message 7 of 24 in “regression in 92392b4”
  1. Pierre HabouzitJul 22, 2008
  2. Johannes SchindelinJul 22, 2008
  3. Shawn O. PearceJul 23, 2008
  4. Johannes SchindelinJul 23, 2008
  5. Pierre HabouzitJul 23, 2008
  6. Johannes SchindelinJul 23, 2008
  7. Pierre HabouzitJul 22, 2008
  8. Björn SteinbrinkJul 23, 2008
  9. Pierre HabouzitJul 23, 2008
  10. Pierre HabouzitJul 23, 2008
  11. Johannes SchindelinJul 23, 2008
  12. Björn SteinbrinkJul 23, 2008
  13. Pierre HabouzitJul 23, 2008
  14. Johannes SchindelinJul 23, 2008
  15. Pierre HabouzitJul 23, 2008
  16. Björn SteinbrinkJul 23, 2008
  17. index-pack: never prune base_cache.Pierre Habouzit, Jul 23, 2008
  18. Björn SteinbrinkJul 23, 2008
  19. Johannes SchindelinJul 23, 2008
  20. Pierre HabouzitJul 23, 2008
  21. Johannes SchindelinJul 23, 2008
  22. Björn SteinbrinkJul 23, 2008
  23. Johannes SchindelinJul 23, 2008
  24. Pierre HabouzitJul 23, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.