Add DCHECKs to back reference deserialization.

Add DCHECKs to back reference deserialization.

R=jochen@chromium.org
BUG=chromium:441896
LOG=N

Committed: https://crrev.com/32ad0a3b3d19fd3b0218e4c83ba48356a88c93b0
Cr-Commit-Position: refs/heads/master@{#26531}

[Yang, 2015-02-07 05:51:36]

On 2015/02/06 15:13:00, Yang wrote:

I added even more checks and found a bug in the way we encode back references to
large objects. It could explain the observed bug. Back references to large
objects is encoded as index, but wrongly shifted by 3 bits (or 2 on 32-bit
platforms). Back reference to the first large object would be encoded correctly,
but back references to other large objects would be wrong and point to large
object pages that either do not exist, or have been allocated, but not yet
deserialized into.

VerifyBackReference adds a slight overhead to serialization (about 3-5%), but
let's have it in there at least for now. We can turn it into a DCHECK at some
later point if we are confident that this bug is gone.

[Yang, 2015-02-07 17:06:57]

On 2015/02/07 05:51:36, Yang wrote:
> On 2015/02/06 15:13:00, Yang wrote:
> 
> I added even more checks and found a bug in the way we encode back references
to
> large objects. It could explain the observed bug. Back references to large
> objects is encoded as index, but wrongly shifted by 3 bits (or 2 on 32-bit
> platforms). Back reference to the first large object would be encoded
correctly,
> but back references to other large objects would be wrong and point to large
> object pages that either do not exist, or have been allocated, but not yet
> deserialized into.
> 
> VerifyBackReference adds a slight overhead to serialization (about 3-5%), but
> let's have it in there at least for now. We can turn it into a DCHECK at some
> later point if we are confident that this bug is gone.

Nevermind. This does not fix an existing bug. I introduced one during
refactoring to add checks, and mistook it for an existing one. Nevertheless,
adding those checks should help.

[Yang, 2015-02-09 13:54:13]

On 2015/02/07 17:06:57, Yang wrote:
> On 2015/02/07 05:51:36, Yang wrote:
> > On 2015/02/06 15:13:00, Yang wrote:
> > 
> > I added even more checks and found a bug in the way we encode back
references
> to
> > large objects. It could explain the observed bug. Back references to large
> > objects is encoded as index, but wrongly shifted by 3 bits (or 2 on 32-bit
> > platforms). Back reference to the first large object would be encoded
> correctly,
> > but back references to other large objects would be wrong and point to large
> > object pages that either do not exist, or have been allocated, but not yet
> > deserialized into.
> > 
> > VerifyBackReference adds a slight overhead to serialization (about 3-5%),
but
> > let's have it in there at least for now. We can turn it into a DCHECK at
some
> > later point if we are confident that this bug is gone.
> 
> Nevermind. This does not fix an existing bug. I introduced one during
> refactoring to add checks, and mistook it for an existing one. Nevertheless,
> adding those checks should help.

I uploaded crrev.com/907013002, which should find data corruptions. Nevertheless
I'd like to add the check at least for debug mode.

[jochen (gone - plz use gerrit), 2015-02-09 14:28:17]

lgtm

[Yang, 2015-02-09 14:57:35]

The CQ bit was checked by yangguo@chromium.org

[commit-bot: I haz the power, 2015-02-09 14:58:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/909493002/100001

[commit-bot: I haz the power, 2015-02-09 15:19:29]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-02-09 15:19:36]

Patchset 6 (id:??) landed as
https://crrev.com/32ad0a3b3d19fd3b0218e4c83ba48356a88c93b0
Cr-Commit-Position: refs/heads/master@{#26531}