All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: git@vger.kernel.org
Subject: Re: "failed to read delta base object at..."
Date: Tue, 26 Aug 2008 16:55:52 -0400	[thread overview]
Message-ID: <20080826205552.GR4380@fieldses.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0808251616240.3363@nehalem.linux-foundation.org>

On Mon, Aug 25, 2008 at 04:59:26PM -0700, Linus Torvalds wrote:
> and the difference literally seems to be just a block of less than 160 
> bytes. But it's certainly not a single-bit error, and it's also not a disk 
> block or anything like that.
> 
> Looking at the first line that differs, they are:
> 
> 	-0003460 a0 14 8d 7d cd 12 75 81 2b c4 d9 71 27 62 ae b5
> 	+0003460 a0 14 8d 7d 22 00 00 00 6b 57 fe ff 55 57 fe ff
> 
> so the differences start at offset 03464. The last line is:
> 
> 	-0003700 47 f7 9b 3d b6 a5 99 5a cf 49 ef e0 3f 54 08 f4
> 	+0003700 ae 41 49 50 aa 40 fe ff cf 49 ef e0 3f 54 08 f4
> 
> so they re-join at 03708 (octal offsets because of 'od' behavior).  But in 
> between there seems to be nothing in common.
> 
> So the corrupt data looks like
> 
>                             22 00 00 00 6b 57 fe ff 55 57 fe ff
>         0003500 aa 57 fe ff b0 00 0e 00 d9 66 22 00 00 00 00 e0
>         0003520 19 9f fe ff ff ff d1 43 fe ff d1 43 fe ff 00 c0
>         0003540 bf fe f0 33 69 bf b2 33 69 bf 00 00 00 10 01 fe
>         0003560 bf fe 66 01 00 00 01 1f 37 17 2e 59 fe ff 00 00
>         0003600 00 00 c2 41 fe ff 00 00 01 1f 37 17 44 42 fe ff
>         0003620 00 01 fe ff 01 1f 37 07 d4 42 fe ff 02 01 a8 44
>         0003640 00 f8 bf fe 6b 57 fe ff 55 57 fe ff 97 57 fe ff
>         0003660 00 f8 bf fe 04 00 fe ff ab 45 fe ff 02 00 fe ff
>         0003700 ae 41 49 50 aa 40 fe ff 
> 
> and I don't see what the patern is, except that there's a lot of "fe ff" 
> in there.

and all aligned on 2-byte boundaries?  I don't see anything suggestive
there either.

> 148 bytes, no obvious source. It definitely does _not_ look like 
> compressed input (it's too regular to be something zlib spits out), nor is 
> it text. Nor is it valid x86 assembly, so it's not some code-segment data 
> either.
> 
> And as far as I can tell, that's the _only_ corruption in the whole file, 
> but I didn't really double-check.
> 
> Does anybody see a pattern?

Got me.  Thanks for taking a look at it.

--b.

  parent reply	other threads:[~2008-08-26 20:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-25 16:46 "failed to read delta base object at..." J. Bruce Fields
2008-08-25 18:58 ` Nicolas Pitre
2008-08-25 21:18   ` J. Bruce Fields
2008-08-25 19:01 ` Linus Torvalds
2008-08-25 21:31   ` J. Bruce Fields
2008-08-25 21:37     ` Linus Torvalds
2008-08-25 22:13       ` J. Bruce Fields
2008-08-25 23:59         ` Linus Torvalds
2008-08-26 20:43           ` Jason McMullan
2008-08-26 21:01             ` Jason McMullan
2008-08-27 17:05               ` Linus Torvalds
2008-08-27 19:17                 ` Nicolas Pitre
2008-08-27 19:48                   ` Linus Torvalds
2008-08-27 20:46                     ` Nicolas Pitre
2008-08-29  2:05                       ` [PATCH 0/3] don't let disk corruptions escape pack SHA1 checksum Nicolas Pitre
2008-08-29  2:07                         ` [PATCH 1/3] improve reliability of fixup_pack_header_footer() Nicolas Pitre
2008-08-29  2:07                           ` [PATCH 2/3] pack-objects: use fixup_pack_header_footer()'s validation mode Nicolas Pitre
2008-08-29  2:07                             ` [PATCH 3/3] index-pack: " Nicolas Pitre
2008-08-29  4:44                           ` [PATCH 1/3] improve reliability of fixup_pack_header_footer() Shawn O. Pearce
2008-08-29 13:08                             ` Nicolas Pitre
2008-08-29 14:30                               ` Shawn O. Pearce
2008-08-29 20:07                                 ` [PATCH 0/5] pack header rewriting improvements Nicolas Pitre
2008-08-29 20:07                                   ` [PATCH 1/5] pack-objects: improve returned information from write_one() Nicolas Pitre
2008-08-29 20:07                                     ` [PATCH 2/5] improve reliability of fixup_pack_header_footer() Nicolas Pitre
2008-08-29 20:08                                       ` [PATCH 3/5] pack-objects: use fixup_pack_header_footer()'s validation mode Nicolas Pitre
2008-08-29 20:08                                         ` [PATCH 4/5] index-pack: " Nicolas Pitre
2008-08-29 20:08                                           ` [PATCH 5/5] fixup_pack_header_footer(): use nicely aligned buffer sizes Nicolas Pitre
2008-08-31  7:10                                             ` Junio C Hamano
2008-08-29 20:14                                 ` [PATCH 1/3] improve reliability of fixup_pack_header_footer() Nicolas Pitre
2008-08-29  4:55                         ` [PATCH 0/3] don't let disk corruptions escape pack SHA1 checksum Shawn O. Pearce
2008-08-26 20:55           ` J. Bruce Fields [this message]
2008-08-27 20:14           ` "failed to read delta base object at..." 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

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

  git send-email \
    --in-reply-to=20080826205552.GR4380@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.