git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christoph Michelbach <michelbach94@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems
Date: Wed, 06 Jul 2016 20:02:48 +0200	[thread overview]
Message-ID: <1467828168.6286.5.camel@gmail.com> (raw)
In-Reply-To: <CACsJy8BDQbanGsf=3z3K-OuH0++EuqQFEB22udXJT+WZnFKSBg@mail.gmail.com>

I now created a repo on a 64 bit system (same command as before), then
duplicated it. One copy I applied git gc to on the 64 bit host system,
the other copy I gave to my 32 bit virtual machine to apply git gc to
it.

The 64 bit host uses git from the Ubuntu repositories, the 32 bit
virtual machine uses git 2.9 from github with the patches applied.

git gc worked without problems on the host but I got

frank@frank-virtual-16-04-32-bit:~/g$ git gc
Counting objects: 6, done.
Compressing objects: 100% (3/3), done.
error: bad packed object CRC for
f595ad71c1a1ecc312ddcb32a84a4bfc4a2ed1c8
Writing objects: 100% (6/6), done.
Total 6 (delta 0), reused 0 (delta 0)
error: failed to validate delta base reference at offset 342896 from
.git/objects/pack/pack-630b5a3f28cd9d02a546462bf0d0bc640ffde784.pack
error: bad offset for revindex
error: failed to read object 4246d27f8e0149d45687b0cc23bc29a67f1f0c79
at offset 342887 from .git/objects/pack/pack-
630b5a3f28cd9d02a546462bf0d0bc640ffde784.pack
fatal: packed object 4246d27f8e0149d45687b0cc23bc29a67f1f0c79 (stored
in .git/objects/pack/pack-
630b5a3f28cd9d02a546462bf0d0bc640ffde784.pack) is corrupt
error: failed to run prune
frank@frank-virtual-16-04-32-bit:~/g$ 

on the virtual machine.

Not including the mailing list in CC wasn't intended.

-- 
With kind regards
Christoph Michelbach

On Wed, 2016-07-06 at 17:23 +0200, Duy Nguyen wrote:
> On Wed, Jul 6, 2016 at 12:14 AM, Christoph Michelbach
> <michelbach94@gmail.com> wrote:
> > 
> > I now tried git gc again and it failed (in a different way, though;
> > and
> > the error message only appeared once git gc terminated).
> > 
> > Full input and output:
> > 
> > christoph@virt-16-04-32-bit:~$ mkdir test && cd test && git init &&
> > touch someFile && git add someFile && git commit -m "Initial
> > commit."
> > && dd if=/dev/urandom of=bigBinaryFile bs=1MB count=4294 && git add
> > bigBinaryFile && git commit -m "Introduced big biary file."
> > Initialized empty Git repository in /home/christoph/test/.git/
> > [master (root-commit) 20507ef] Initial commit.
> >  1 file changed, 0 insertions(+), 0 deletions(-)
> >  create mode 100644 someFile
> > 4294+0 records in
> > 4294+0 records out
> > 4294000000 bytes (4.3 GB, 4.0 GiB) copied, 435.236 s, 9.9 MB/s
> > [master 88e5dbb] Introduced big biary file.
> >  1 file changed, 0 insertions(+), 0 deletions(-)
> >  create mode 100644 bigBinaryFile
> > christoph@virt-16-04-32-bit:~/test$ git gc
> > Counting objects: 6, done.
> > Compressing objects: 100% (3/3), done.
> > Writing objects: 100% (6/6), done.
> > Total 6 (delta 0), reused 1 (delta 0)
> > error: inflate: data stream error (incorrect header check)
> > error: failed to read object
> > 705f438ccb845871ffba9d4b56f16ac763652937
> Sigh.. I'll try again :) BTW if you have a 64-bit machine too, try
> create the repo with it (so we are sure the repo is not corrupted in
> the first place) then you can run tests like this on 32-bit systems.
> The previous "bad crc" message was a fault in the code, not the data.
> 
> PS. I have just let gc run till the end (last time I tried
> pack-objects, which is only part of gc) and got a(nother) error.
> Checking... BTW, you should send these mails to git@ as well, no need
> for private message exchange.

  parent reply	other threads:[~2016-07-06 18:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 22:38 [bug] Reliably Reproducible Bad Packing of Objects Christoph Michelbach
2016-07-02  9:10 ` Duy Nguyen
2016-07-02 14:35   ` Duy Nguyen
2016-07-05 17:05 ` [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems Nguyễn Thái Ngọc Duy
2016-07-05 17:05   ` [PATCH 1/5] pack-objects: pass length to check_pack_crc() without truncation Nguyễn Thái Ngọc Duy
2016-07-12 17:16     ` Junio C Hamano
2016-07-05 17:05   ` [PATCH 2/5] sha1_file.c: use type off_t* for object_info->disk_sizep Nguyễn Thái Ngọc Duy
2016-07-12 17:20     ` Junio C Hamano
2016-07-12 19:26     ` Junio C Hamano
2016-07-05 17:05   ` [PATCH 3/5] index-pack: correct "len" type in unpack_data() Nguyễn Thái Ngọc Duy
2016-07-05 20:25     ` Johannes Sixt
2016-07-06 15:25       ` Duy Nguyen
2016-07-06 16:04         ` Junio C Hamano
2016-07-06 16:08           ` Junio C Hamano
2016-07-05 17:05   ` [PATCH 4/5] index-pack: report correct bad object offsets even if they are large Nguyễn Thái Ngọc Duy
2016-07-12 17:24     ` Junio C Hamano
2016-07-12 19:27     ` Junio C Hamano
2016-07-05 17:05   ` [PATCH 5/5] index-pack: correct "offset" type in unpack_entry_data() Nguyễn Thái Ngọc Duy
2016-07-05 18:11   ` [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems Christoph Michelbach
     [not found]   ` <1467756891.4798.1.camel@gmail.com>
     [not found]     ` <CACsJy8BDQbanGsf=3z3K-OuH0++EuqQFEB22udXJT+WZnFKSBg@mail.gmail.com>
2016-07-06 18:02       ` Christoph Michelbach [this message]
2016-07-06 18:54         ` Duy Nguyen
2016-07-10 10:41   ` Duy Nguyen
2016-07-10 10:42   ` [PATCH 6/5] pack-objects: do not truncate result in-pack object size " Nguyễn Thái Ngọc Duy
2016-07-10 10:45   ` [PATCH 7/5] fsck: use streaming interface for large blobs in pack Nguyễn Thái Ngọc Duy
2016-07-12 18:39     ` Junio C Hamano
2016-07-12 19:06       ` Junio C Hamano
2016-07-12 17:07   ` [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems Junio C Hamano
2016-07-12 18:48     ` Junio C Hamano
2016-07-12 20:38   ` Junio C Hamano
2016-07-13  6:01     ` Duy Nguyen
2016-07-13 15:43   ` [PATCH v2 0/7] " Nguyễn Thái Ngọc Duy
2016-07-13 15:43     ` [PATCH v2 1/7] pack-objects: pass length to check_pack_crc() without truncation Nguyễn Thái Ngọc Duy
2016-07-13 15:43     ` [PATCH v2 2/7] sha1_file.c: use type off_t* for object_info->disk_sizep Nguyễn Thái Ngọc Duy
2016-07-13 15:44     ` [PATCH v2 3/7] index-pack: correct "len" type in unpack_data() Nguyễn Thái Ngọc Duy
2016-07-13 15:44     ` [PATCH v2 4/7] index-pack: report correct bad object offsets even if they are large Nguyễn Thái Ngọc Duy
2016-07-13 15:44     ` [PATCH v2 5/7] index-pack: correct "offset" type in unpack_entry_data() Nguyễn Thái Ngọc Duy
2016-07-13 15:44     ` [PATCH v2 6/7] pack-objects: do not truncate result in-pack object size on 32-bit systems Nguyễn Thái Ngọc Duy
2016-07-13 15:44     ` [PATCH v2 7/7] fsck: use streaming interface for large blobs in pack Nguyễn Thái Ngọc Duy
2016-07-13 16:16     ` [PATCH v2 0/7] Number truncation with 4+ GB files on 32-bit systems Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1467828168.6286.5.camel@gmail.com \
    --to=michelbach94@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).