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 (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
set variable nr_threads = 1
br 1111
cond 2 i == 6300
br 916
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 :-)


[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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to