Re: regression in 92392b4
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Jul 23, 2008, 10:14 UTC
- Message-ID
- <20080723101415.GA23769@atjola.homenet>
- In-Reply-To
- <20080722231745.GD11831@artemis.madism.org>
On 2008.07.23 01:17:45 +0200, 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).
Here's how to reproduce:
#!/bin/bash
[ -d git-bug ] || \ git clone git://git.kernel.org/pub/scm/git/git git-bug cd git-bug
git update-ref refs/remotes/origin/html 5ba2c22 git update-ref refs/remotes/origin/man 2857e17 git update-ref refs/remotes/origin/maint 2d9c572 git update-ref refs/remotes/origin/master 93310a4 git update-ref refs/remotes/origin/next 559998f git update-ref refs/remotes/origin/pu 010581c8
git reset --hard origin/master
sleep 1
git reflog expire --expire=0 --all
git repack -A -d -f --depth=10 --window=10 git prune
git config core.deltaBaseCacheLimit 100
git fetch
The values for html, man, master and next are taken from Pierre's output, those for maint and pu are from a repo that works for reproducing the bug, just in case that future output of those branches manage to break the reproducability.
Might be, that any fetch will fail if deltaBaseCacheLimit is low enough, but I'm too lazy to test that as well, now that I realized it. My head seems not to be working correctly anyway, can't even manage to get a core dump... Stupid flu...
HTH Björn