Subject: [BUG] Assertion failed: (child->real_type == OBJ_REF_DELTA), function find_unresolved_deltas_1, file builtin/index-pack.c

From: Martin von Gagern <[email-masked]>
Date: Fri, 01 Aug 2014 14:24:27 +0200

Hi!

See also https://code.google.com/p/support/issues/detail?id=31571

Executing the command

git clone https://code.google.com/p/mapsforge/

fails with the error message

Assertion failed: (child->real_type == OBJ_REF_DELTA),
function find_unresolved_deltas_1, file builtin/index-pack.c

Bisecting the code I found that 7218a215efc7ae46f7ca8d82 (from 2011,
first released in git 1.7.7) is the first bad commit. It is also the one
to introduce that assertion.

The idea behind that commit seems simple: instead of just sorting by
base hash, also sort by type. Then when iterating over the matching
objects, we can rely on the type and don't have to check that.

So far, so good. But the problem here is that the sorting is based on
the "type" attribute, while the assertion and the case distinction it
replaces was based on "real_type". I guess that at the point where the
sorting takes place, these two should be identical. But once
resolve_delta gets called, the real_type is changed to that of the base
object. Which means that the original case distinction did more than
just drop deltas of the wrong type: it also prevented resolution of
already-resolved deltas. Therefore the change caused stuff to fail which
used to work before. In this particular instance, the real_type changed
from OBJ_REF_DELTA to OBJ_TREE which caused the assertion to fail.

I'm not sure whether this kind of duplicate resolution is something
normal or indicates some breakage in the repository in question. If it
is considered normal (although rare, otherwise others would have
complained by now), then someone should likely turn the assertion back
into a normal conditional. If this is a broken repository, then I think
it should be reported as such, since in my book a failed assertion
indicates a problem with the program itself, not its input data.

Thank you very much,
 Martin von Gagern