The pack-objects (man git-pack-objects) died of signal 13 (broken pipe), because git was unable to inflate (uncompress) the object and it failed with error (error code -5 could mean out-of-mem or overwrite/overlap error).
Explanation
According to zlib manual, the errors are defined as follow:
#define Z_OK 0 #define Z_STREAM_END 1 #define Z_NEED_DICT 2 #define Z_ERRNO (-1) #define Z_STREAM_ERROR (-2) #define Z_DATA_ERROR (-3) #define Z_MEM_ERROR (-4) #define Z_BUF_ERROR (-5) #define Z_VERSION_ERROR (-6) where -5 means no progress is possible or if there was not enough room in the output buffer.
Z_BUF_ERRORif no progress is possible or if there was not enough room in the output buffer whenZ_FINISHis used. Note thatZ_BUF_ERRORis not fatal, andinflate()can be called again with more input and more output space to continue decompressing.
Here is what we can read in zlib FAQ:
Before making the call, make sure that
avail_inandavail_outare not zero. When setting the parameter flush equal toZ_FINISH, also make sure that avail_out is big enough to allow processing all pending input. Note that aZ_BUF_ERRORis not fatal--another call to deflate() or inflate() can be made with more input or output space. AZ_BUF_ERRORmay in fact be unavoidable depending on how the functions are used, since it is not possible to tell whether or not there is more output pending whenstrm.avail_outreturns with zero. See zlib Usage Example for a heavily annotated example.
Solution
This may be related to few things:
the object being pushed is too big so zlib is of memory, so you need more space in the output zlib buffer,
In this case, try increasing
http.postBuffer, e.g.git config http.postBuffer 134217728 # =~ 128MBAlternatively use
bfgto strip larger blobs, e.g.java -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.gityour object is corrupted, so run
git fsck --fullandgit gcPotential reason could be corrupted memory or storage device, so retry on clean repository or different computer.
could be a git bug, since it shouldn't abort on
Z_BUF_ERROR, but to provide more output space or more input, see: zLib inflate() hangs while uncompressing bufferYou may report a git bug report to the mailing list.
could be a gzip inflate issue it-self (e.g. Is this a bug in this gzip inflate method?)
could be an old kernel bug (<= 2.6.32-rc4), so upgrade your kernel
See: Bug#547503: git-core: "git clone" fails on armel
The only possibly relevant kernel change I could find was commit
5a3a29f(ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem, commit7929eb9upstream) from 2.6.31.1. So though I also have my doubts, we could be lucky.msg00049
Other useful commands to consider:
GIT_TRACE=1 git push origingit count-objects -Hvto check for excess of size limits
See also:
- Z_BUF_ERROR -5 while trying to decompress zlib data at SO
- zlib inflate returning a buffer error at SO
Here is failing relevant Git code (builtin/index-pack.c):
git_inflate_init(&stream); stream.next_out = buf; stream.avail_out = buf == fixed_buf ? sizeof(fixed_buf) : size; do { unsigned char *last_out = stream.next_out; stream.next_in = fill(1); stream.avail_in = input_len; status = git_inflate(&stream, 0); use(input_len - stream.avail_in); if (sha1) git_SHA1_Update(&c, last_out, stream.next_out - last_out); if (buf == fixed_buf) { stream.next_out = buf; stream.avail_out = sizeof(fixed_buf); } } while (status == Z_OK); if (stream.total_out != size || status != Z_STREAM_END) bad_object(offset, _("inflate returned %d"), status); git_inflate_end(&stream); and git_inflate() from zlib.c
status = inflate(&strm->z, (strm->z.avail_in != strm->avail_in) ? 0 : flush);