Hi guys,
I wanted post you patch here for this bug, but I can't find primary
source of this problem [0], because I don't understand some ideas in the
code. So what I investigate:
Bug is reprodusible since git version 1.8.3.1 (may earlier 1.8.xx, but I
don't test it) to actual upstream version.
This problem "doesn't exists" in version 1.7.xx - or more precisely is
not reproducible. "May" this is reproducible
since commit "7218a215" - in this commit was added assert in file
"builtin/index-pack.c" (actual line is 918), but I didn't test this.
This assert tests if object's (child) real type == OBJ_REF_DELTA. This
will failure for object with real_type == OBJ_TREE (set as parent's
type) and type == OBJ_REF_DELTA. Here some prints of important variables
before failure assert() (from older version but I think that values are
still actual in this case):
------------------------------
(gdb) p base->ref_first
$9 = 3223
(gdb) p deltas[3223]
$10 = {
base = {
sha1 = "\274\070k\343K\324x\037q\273h\327*n\n\356\061$ \036",
offset = 2267795834784135356
},
obj_no = 11152
}
(gdb) p *child
$11 = {
idx = {
sha1 = "J\242i\251\261\273\305\067\236%CE\022\257\252\342[;\tD",
crc32 = 2811659028,
offset = 10392153
},
size = 30,
hdr_size = 22,
type = OBJ_REF_DELTA,
real_type = OBJ_TREE,
delta_depth = 0,
base_object_no = 5458
}
(gdb) p objects[5458]
$13 = {
idx = {
sha1 = "\274\070k\343K\324x\037q\273h\327*n\n\356\061$ \036",
crc32 = 3724458534,
offset = 6879168
},
size = 236,
hdr_size = 2,
type = OBJ_TREE,
real_type = OBJ_TREE,
delta_depth = 0,
base_object_no = 0
}
---------------------------------------
"base_object_no" is static 5458. "base->ref_first" child's object are
dynamic. If you want stop process in same position my recommendation for
gdb (if you use gdb) when you will be in file index-pack.c:
br 1093
cont
set variable nr_threads = 1
br 1111
cond 2 i == 6300
cont
br 916
cont
-----------
compilated without any optimisation, line numbers modified for commit
"6c4ab27f2378ce67940b4496365043119d7ffff2"
Condition i == 6300 ---> last iteration before failure has dynamic rank
in range 6304 to 6309 in the most cases (that's weird for me, when count
of downloaded objects is statically 12806, may wrong search of children?)
-----------------------------------
Here I am lost. I don't know really what I can do next here, because I
don't understand some ideas in code. e.g. searching of child - functions
find_delta(), find_delta_children(). Calculation on line 618:
----
int next = (first+last) / 2;
----
I still don't understand. I didn't find description of this searching
algorithm in tech. documentation but I didn't read all yet. However I
think that source of problems could be somewhere in these two functions.
When child is found, its real_type is set to parent's type in function
resolve_delta() on the line 865 and then lasts wait for failure. I don't
think that problem is in repository itself [1], but it is possible.
Any next ideas/hints or explanation of these functions? I began study
source code and mechanisms of the git this week, so don't beat me yet
please :-)
Regards,
Petr
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1099919
[1] git clone https://code.google.com/p/mapsforge/ mapsforge.git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html