O pack-objects (man git-pack-objects ) morreu do sinal 13 ( canal quebrado ), porque git não conseguiu inflar (descompactar) o objeto e falhou com o erro (o código de erro -5 pode significar fora de -mem ou overwrite / overlap error ).
Explicação
De acordo com o manual do zlib , os erros são definidos da seguinte forma:
#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)
onde -5 significa que nenhum progresso é possível ou se não havia espaço suficiente no buffer de saída.
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.
Aqui está o que podemos ler em 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.
Solução
Isso pode estar relacionado a poucas coisas:
-
o objeto que está sendo empurrado é muito grande, então o zlib é de memória, então você precisa de mais espaço no buffer zlib de saída,
Nesse caso, tente aumentar
http.postBuffer, por exemplogit config http.postBuffer 134217728 # =~ 128MBComo alternativa, use
bfgpara remover bolhas maiores, por exemplojava -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.git -
seu objeto está corrompido, então execute
git fsck --fullegit gcO motivo potencial pode estar corrompido na memória ou no dispositivo de armazenamento, portanto, tente novamente em um repositório limpo ou em um computador diferente.
-
pode ser um bug git, pois não deve abortar em
Z_BUF_ERROR, mas para fornecer mais espaço de saída ou mais entrada, consulte: zLib infate () trava ao descompactar o bufferVocê pode relatar um relatório de bug git para a lista de discussão .
-
poderia ser um problema de inflar do gzip (por exemplo, Isso é um bug nesse método de inflar do gzip? )
-
pode ser um bug antigo do kernel (< = 2.6.32-rc4), então atualize seu kernel
Veja: Bug # 547503: git-core: "git clone" falha no 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
Outros comandos úteis a serem considerados:
-
GIT_TRACE=1 git push origin -
git count-objects -Hvpara verificar o excesso de limites de tamanho
Veja também:
- Z_BUF_ERROR -5 ao tentar descompactar dados do zlib em SO
- zlib infle retornando um erro de buffer em SO
Aqui está a falha do código Git relevante ( 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);
e git_inflate () do zlib.c
status = inflate(&strm->z,
(strm->z.avail_in != strm->avail_in)
? 0 : flush);