Re: regression in multi-threaded git-pack-index

szager@google.com (Stefan Zager) writes:

So after that fun detour into threading issues, I have actually managed to reproduce this problem on OS X even with the three in-flight patches already applied.

I reduced the issue to this file:

  http://thomasrast.ch/download/broken-pack

on which you can run this command in the repo that Stefan provided:

  git index-pack --keep --stdin -v --pack_header=2,50757 <broken-pack

I got the file by patching fetch-pack.c to pipe the pack to 'dd of=broken-pack' instead of index-pack, as I couldn't find any other way of getting at the data stream before index-pack ruins it.

The funny thing about it is that I get this on OS X:

  $ git index-pack --keep --stdin -v --pack_header=2,50757 <borked
  Receiving objects: 100% (50757/50757), 24.52 MiB | 23.91 MiB/s, done.
  Bus error: 10tas:  24% (10194/42272)

(notice the error) and also

  $ gdb --args $(which git)
  GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul  1 10:50:06 UTC 2011)
  Copyright 2004 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done

  (gdb) r index-pack --keep --stdin -v --pack_header=2,50757 <borked
  Starting program: /Users/trast/.local/bin/git index-pack --keep --stdin -v --pack_header=2,50757 <borked
  Reading symbols for shared libraries +++........................ done
  Receiving objects: 100% (50757/50757), 24.52 MiB | 13.06 MiB/s, done.
  Resolving deltas:  25% (10568/42272)   
  Program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_PROTECTION_FAILURE at address: 0x000000014484dfe8
  [Switching to process 96573 thread 0x10f]
  0x000000010017ee20 in use_pack (p=0x100500f30, w_cursor=0x14484e1a0, offset=69638148, left=0x0) at sha1_file.c:866
  866             if (!win || !in_window(win, offset)) {

This seems to be a SIGBUS triggered by stack overflow, largely based on the observation that

  (gdb) p &p
  $6 = (struct packed_git **) 0x144748058

I can't see anything wrong with the values as such, but if you have good ideas what I should ask of that debugger, I'm keeping the session around.

Furthermore, if I run the same command on linux in the provided repo, I get this instead:

  $ git index-pack --fix-thin --keep --stdin -v --pack_header=2,50757 <../broken-pack
  Receiving objects: 100% (50757/50757), 24.52 MiB | 18.84 MiB/s, done.
  Resolving deltas: 100% (42272/42272), completed with 8264 local objects.
  pack    1cd9880470ea812835edde58e8d7752818dc1ead

But when I do it with Peff's patch applied, I get:

  $ git index-pack --fix-thin --keep --stdin -v --pack_header=2,50757 <../broken-pack
  Empfange Objekte: 100% (50757/50757), 24.52 MiB | 17.92 MiB/s, done.
  git: builtin/index-pack.c:897: find_unresolved_deltas_1: Assertion `child->real_type == OBJ_OFS_DELTA' failed.
  Aborted

I think the patch is probably still good as it stands, but there's some underlying breakage going on that hides the problem if we don't clear that memory...

I'm still looking, but I wanted to get this -- and in particular the pack -- out for you to play with ;-)