git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

From
CMChristoph Michelbach <michelbach94@gmail.com>
Date
Jul 6, 2016, 18:02 UTC
Message-ID
<1467828168.6286.5.camel@gmail.com>
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.
Previous: Junio C HamanoNext: Duy Nguyen
Message 38 of 39 in “[bug] Reliably Reproducible Bad Packing of Objects”
  1. Christoph MichelbachJun 24, 2016
  2. Duy NguyenJul 2, 2016
  3. Duy NguyenJul 2, 2016
  4. 0/5 Number truncation with 4+ GB files on 32-bit systemsNguyễn Thái Ngọc Duy, Jul 5, 2016
  5. 1/5 pack-objects: pass length to check_pack_crc() without truncationNguyễn Thái Ngọc Duy, Jul 5, 2016
  6. Junio C HamanoJul 12, 2016
  7. 5/5 index-pack: correct "offset" type in unpack_entry_data()Nguyễn Thái Ngọc Duy, Jul 5, 2016
  8. 4/5 index-pack: report correct bad object offsets even if they are largeNguyễn Thái Ngọc Duy, Jul 5, 2016
  9. Junio C HamanoJul 12, 2016
  10. Junio C HamanoJul 12, 2016
  11. 2/5 sha1_file.c: use type off_t* for object_info->disk_sizepNguyễn Thái Ngọc Duy, Jul 5, 2016
  12. Junio C HamanoJul 12, 2016
  13. Junio C HamanoJul 12, 2016
  14. 3/5 index-pack: correct "len" type in unpack_data()Nguyễn Thái Ngọc Duy, Jul 5, 2016
  15. Johannes SixtJul 5, 2016
  16. Duy NguyenJul 6, 2016
  17. Junio C HamanoJul 6, 2016
  18. Junio C HamanoJul 6, 2016
  19. Christoph MichelbachJul 5, 2016
  20. Duy NguyenJul 10, 2016
  21. 6/5 pack-objects: do not truncate result in-pack object size on 32-bit systemsNguyễn Thái Ngọc Duy, Jul 10, 2016
  22. 7/5 fsck: use streaming interface for large blobs in packNguyễn Thái Ngọc Duy, Jul 10, 2016
  23. Junio C HamanoJul 12, 2016
  24. Junio C HamanoJul 12, 2016
  25. Junio C HamanoJul 12, 2016
  26. Junio C HamanoJul 12, 2016
  27. Junio C HamanoJul 12, 2016
  28. Duy NguyenJul 13, 2016
  29. 0/7 Number truncation with 4+ GB files on 32-bit systemsNguyễn Thái Ngọc Duy, Jul 13, 2016
  30. 4/7 index-pack: report correct bad object offsets even if they are largeNguyễn Thái Ngọc Duy, Jul 13, 2016
  31. 3/7 index-pack: correct "len" type in unpack_data()Nguyễn Thái Ngọc Duy, Jul 13, 2016
  32. 2/7 sha1_file.c: use type off_t* for object_info->disk_sizepNguyễn Thái Ngọc Duy, Jul 13, 2016
  33. 5/7 index-pack: correct "offset" type in unpack_entry_data()Nguyễn Thái Ngọc Duy, Jul 13, 2016
  34. 7/7 fsck: use streaming interface for large blobs in packNguyễn Thái Ngọc Duy, Jul 13, 2016
  35. 6/7 pack-objects: do not truncate result in-pack object size on 32-bit systemsNguyễn Thái Ngọc Duy, Jul 13, 2016
  36. 1/7 pack-objects: pass length to check_pack_crc() without truncationNguyễn Thái Ngọc Duy, Jul 13, 2016
  37. Junio C HamanoJul 13, 2016
  38. Christoph MichelbachJul 6, 2016
  39. Duy NguyenJul 6, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.