1

I was trying to push my changes today to remote repository and I get following error:

git push -u origin master
error: pack-objects died of signal 10

Commit and push yesterday worked fine, there were no changes in settings, nobody else committed or pushed to the repository and the commit is not huge, just about 10 files.

I am using MacOS Sierra - git version 2.9.3 (Apple Git-75), Repository is GitLab 8.13.5 (Git 2.7.4)

The whole repository is just 33MB so no large files are included (not even in the commit). I am using SSH to access the repository.

git config pack.threads 1 had no effect.

I also tried cloning remote to new location, editing one file, committing, pushing and that worked, so the problem should be with the specific commit.

Running git fsck is resulting in the same error:

git fsck
error: unable to open .git/objects/14: Interrupted system call
Checking object directories: 100% (256/256), done.
Bus error: 10

What is the problem?

Jan Richter
  • 1,976
  • 4
  • 29
  • 49

1 Answers1

3

This error:

error: unable to open .git/objects/14: Interrupted system call

is rather mysterious. This should be a directory and git fsck should be able to open it without being interrupted.1 You might run:

ls -ld .git/objects/14

to verify that it is a directory, and if so, ls -l .git/objects/14 to see what's in it (it should contain zero or more files with hash-IDs as names2).

The SIGBUS indicates some kind of internal bug in Git. C programs get SIGBUS or SIGSEGV when they attempt to use memory addresses they were never granted in the first place, or that are otherwise invalid (see Bus error vs Segmentation fault and note that the decision of which signal to deliver is both OS- and architecture-dependent, so that Linux on ARM, MIPS, or SPARC will behave differently from the same version of Linux on x86, for instance). It seems likely that whatever is causing Git to be unable to read the objects stored in the repository is leading to Git's subsequent crash, but Git—or at the least, git fsck—is not supposed to crash due to bad repositories. Using git fsck in particular is supposed to diagnose what's wrong with a bad repository. And in any case, getting EINTR when opening a directory is unusual, at least.

If the files are non-local (found over a network), you might move them to local (on-disk) storage and see if that at least makes the problem go away. This is not "fixing" the bug so much as simply "avoiding" it, but if that suffices.... :-)

1The one obvious path where this might not be the case is if the file or directory is not stored on the local disk, but rather over the network, such as on an AFP server.

2These names will be only 38 characters long, giving the remaining part of the hash ID after removing the leading 14. The 14 is implied by the fact that they are in .git/objects/14/.

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    Avoiding the problem did the trick. I should have pointed out that the directory was mounted over SSHFS and it actually is a CentOS 7 server. What I think could be the problem is that there were 2 unstaged files in the working copy with the same name "file.txt" and "File.txt" and my local drive is case insensitive so... probably? – Jan Richter Nov 19 '16 at 12:33
  • This suggests there might be a bug in the sshfs implementation: it should probably restart system calls on SIGALRM, rather than interrupting them. The files with differing case will give you a different headache on the Mac: to work around it, create a file system on your local disk that is case-sensitive. Note that there are some bugs in some MacOS releases in this area; see http://apple.stackexchange.com/questions/217915/how-to-create-a-case-sensitive-filesystem-in-10-11-1 – torek Nov 19 '16 at 12:43