"index-pack died of signal 10" while doing git fetch --all on new mac

[Randy Smith]

I've tried to setup a chromium sandbox as per https://code.google.com/p/chromium/wiki/UsingNewGit, but when I do a "git fetch --all" I get:

rdsmith-macbookpro:../chrome/src [master] $ git fetch --all

Fetching origin

remote: Counting objects: 85879, done        

remote: Finding sources: 100% (78842/78842)        

remote: Getting sizes: 100% (1724/1724)        

remote: Compressing objects:  79% (1357/1717)        

remote: Total 78842 (delta 54229), reused 78730 (delta 54205)        

Receiving objects: 100% (78842/78842), 10.94 MiB | 10.26 MiB/s, done.

error: index-pack died of signal 10

fatal: index-pack failed

error: Could not fetch origin

rdsmith-macbookpro:../chrome/src [master] $ 

Any ideas what I might have misconfigured?  

Suggestions as to how to debug this would be welcome too--I've tried dtruss, and it gives up "because of systemic unresponsiveness" before I get to the failure.  I'm inclined to use strace on linux to figure out what subprocesses git fetch is setting up, and try to setup a similar configuration with index-pack under the debugger, but that's likely to be a reasonably large hassle, so I figured I'd ask first.

-- Randy

[Fred Akalin]

What is your version of git?

(The last time I saw this error was with an old version of git on cygwin.)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Randy Smith]

Maybe that's it.  I'm at 1.7.12.4, and my linux git version is 1.8.1.3.  I'll try upgrading (though that'll probably land me in more trouble, as noted in my other thread about upgrading svn resulting in a bad second kerberos install).

-- Randy

[Fred Akalin]

Interesting.  My OS X version is "git version 1.7.10.2 (Apple Git-33)" and that seems to work with my linux git version of 1.8.1.3.  I got my OS X git from XCode's command-line tools.

[Stefan Zager]

On Wed, Feb 27, 2013 at 1:32 PM, Fred Akalin <aka...@chromium.org> wrote:

Interesting.  My OS X version is "git version 1.7.10.2 (Apple Git-33)" and that seems to work with my linux git version of 1.8.1.3.  I got my OS X git from XCode's command-line tools.

I'm skeptical that this is a version incompatibility.  I'd be interested to see if you can reproduce the failure, and show that it is, in fact, a version incompatibility.

[Randy Smith]

Oh, the failure is quite reproducible :-{.  And, unfortunately, it did not go away when I upgraded to 1.8.1.3.  So you're probably right that it's not a version incompatibility.  

Other thoughts/suggestions for debugging the problem welcome .....

-- Randy

 

[Stefan Zager]

Well, I looked through the git-pack-index code for fail paths, and there are plenty of them.  Curiously, though, I don't see any that would exit with a status of 10.

Might need to file a bug against git.

In the meantime, would you mind archiving your src/.git directory and placing it somewhere world-readable (or at least google-readable)?  I'd like to try and reproduce it locally.

Thanks,

Stefan

[Stefan Zager]

On Wed, Feb 27, 2013 at 2:20 PM, Roland McGrath <mcgr...@google.com> wrote:

Signal 10 (SIGBUS), not exit status 10.
It's a bad pointer.

Oh!  That's different (and worse).  Thanks for pointing that out.

Stefan 

[Randy Smith]

On Wed, Feb 27, 2013 at 5:13 PM, Stefan Zager <sza...@google.com> wrote:

On Wed, Feb 27, 2013 at 1:43 PM, Randy Smith <rds...@google.com> wrote:

On Wed, Feb 27, 2013 at 4:35 PM, Stefan Zager <sza...@google.com> wrote:

On Wed, Feb 27, 2013 at 1:32 PM, Fred Akalin <aka...@chromium.org> wrote:

Interesting.  My OS X version is "git version 1.7.10.2 (Apple Git-33)" and that seems to work with my linux git version of 1.8.1.3.  I got my OS X git from XCode's command-line tools.

I'm skeptical that this is a version incompatibility.  I'd be interested to see if you can reproduce the failure, and show that it is, in fact, a version incompatibility.

Oh, the failure is quite reproducible :-{.  And, unfortunately, it did not go away when I upgraded to 1.8.1.3.  So you're probably right that it's not a version incompatibility.  

Other thoughts/suggestions for debugging the problem welcome .....

Well, I looked through the git-pack-index code for fail paths, and there are plenty of them.  Curiously, though, I don't see any that would exit with a status of 10.

Might need to file a bug against git.

I still consider operator error (of *some* interesting sort) a more likely explanation than a bug in git, though I'll admit that a SIGBUS deep inside a utility program is an impressive bit of operator error :-}.

 

In the meantime, would you mind archiving your src/.git directory and placing it somewhere world-readable (or at least google-readable)?  I'd like to try and reproduce it locally.

Pointer sent separately; thanks!  I think I'll try to do the same repro on linux; if I *do* get a repro, I'll be in a much better position to debug it there.

-- Randy

 

Thanks,

Stefan

[vas...@chromium.org]

I got the same error today. Git version 1.8.1.3. Any ideas how to fix?

[Randy Smith]

On Wed, Mar 13, 2013 at 9:33 AM, <vas...@chromium.org> wrote:

I got the same error today. Git version 1.8.1.3. Any ideas how to fix?

Nope.  I've been working on it in the background, and Stefan and I are getting together later this week to try some peer debugging.  

What I've found so far:

* The crash is a result of a stack blowout from a recursion in unpack_entry (sha1_file.c in git).  

* I believe the pathway for that recursion (based on reverse compiling the machine code and reading the source) is:

unpack_entry

 unpack_delta_entry (inlined) # Based on *type, object header type

   cache_or_unpack_entry (inlined) # No condition

     unpack_entry  # No data, packed_git

       # pointers don't match, offsets

 # don't match.

* Offhand, this strikes me as suggesting that the incoming packed data is corrupted, but it's coming from the remote, so that doesn't seem likely.

I suspect that there's some obvious machine misconfiguration that I'll kick myself for once I figure it out, but I haven't done so yet :-J.  

What's the machine configuration you're seeing it on?  If it's a mac, is it base operating system, or have you added things to it?

-- Randy

[vas...@chromium.org]

I have Mac 10.8.2. It's new machine. I just installed git and XCode.

[Youngki Chang]

I have the same problem too. I am using OSX 10.8.2 and git 1.8.1.3. Since yesterday when I try 'gclient sync', it gives me the errors:

dhcp-172-23-176-99:src youngki$ gclient sync

Error: Command git remote update returned non-zero exit status 1 in /Users/youngki/chromium2/src

Fetching origin

error: index-pack died of signal 10

fatal: index-pack failed

error: Could not fetch origin

'git fetch' gives the similar error too.

dhcp-172-23-176-99:src youngki$ git fetch

remote: Counting objects: 3580, done

remote: Finding sources: 100% (2313/2313)

remote: Getting sizes: 100% (2067/2067)

remote: Compressing objects:  97% (777/799)

remote: Total 2313 (delta 1542), reused 1717 (delta 1228)

Receiving objects: 100% (2313/2313), 739.97 KiB, done.

error: index-pack died of signal 10 

fatal: index-pack failed

When I try 'git fetch' under '/third_party/WebKit', it works without issues..

[Stefan Zager]

Randy and I were able to bisect this to a change in the git client code (https://github.com/gitster/git):

b8a2486f1524947f232f657e9f2ebf44e3e7a243

It adds multi-threading to the git-pack-index command.  I notified the git developers:

http://www.mail-archive.com/g...@vger.kernel.org/msg20180.html

The work-around from the bug description ('git config pack.threads 1') seems to work for our test case, so if you encounter this problem, give it a try.

Stefan

On Wed, Mar 13, 2013 at 9:33 AM, <vas...@chromium.org> wrote: