On 2008.07.23 12:37:00 +0100, Johannes Schindelin wrote: > Hi, > > On Wed, 23 Jul 2008, Pierre Habouzit wrote: > > > On Wed, Jul 23, 2008 at 10:49:04AM +0000, Johannes Schindelin wrote: > > > > > On Wed, 23 Jul 2008, Björn Steinbrink wrote: > > > > > > > On 2008.07.23 01:17:45 +0200, Pierre Habouzit wrote: > > > > > 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: > > > > > > Funny. That does not reproduce the bug here at all. > > > > > > But then, it is unsurprising, since both Pierre and me did something > > > similar yesterday, fetching _just_ the pre-fetch refs into a freshly > > > initted Git repository, and then fetching from kernel.org. > > > > > > Tested on x86_64. > > > > I can reproduce on x86_64 here. > > Well, I cannot. However, I get some pread issue on i686. To be nice to > kernel.org, I downloaded the pack in question: > > http://pacific.mpi-cbg.de/git/thin-pack.pack > > You should be able to reproduce the behavior by piping this into > > git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263 OK, that gave me a seemingly sane backtrace. What seems to happen (AFA my limited knowledge tells me): In fix_unresolved_deltas, we read base_obj from an existing pack, other than the one we're reading. We then link that object to the base cache. Then in resolve_delta, we create the "result" base_data object and link that one, too. Now this triggers the pruning, and because the cache is so small, we prune the object that we read from the existing pack! Fast forward a few function calls, we end up in get_base_data trying to re-read the data for that object, but this time from the pack that we got on stdin. And boom it goes. Does that make any sense to you? Björn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
