Re: git-merge segfault in 1.6.6 and master

[Tim Olsen <tim@brooklynpenguin.com>]

Junio C Hamano wrote:
> Tim Olsen <tim@brooklynpenguin.com> writes:
>> Breakpoint 8, write_tree_from_memory (o=0x7fffffffd560) at
>> merge-recursive.c:210
>> (gdb) list
>> 205				struct cache_entry *ce = active_cache[i];
>> 206				if (ce_stage(ce))
>> 207					output(o, 0, "%d %.*s", ce_stage(ce),
>> 208					       (int)ce_namelen(ce), ce->name);
>> 209			}
>> 210			return NULL;
>> 211		}
>> 212	
>> 213		if (!active_cache_tree)
>> 214			active_cache_tree = cache_tree();
>> (gdb)
> 
> Are you saying write_tree_from_memory() is returning NULL?  That probably
> means that in the recursive (i.e. the step that first merges multiple
> common ancestors into one) case the merge is getting conflicts.  Do you
> see these "There are unmerged index entries" output?

write_tree_from_memory() is returning NULL.  Stepping through the
execution in gdb shows it returning NULL at line 210.

I do not see any output, however:

$ git merge origin/deployed
Segmentation fault
$

> In the recursive case (i.e. o->call_depth is non-zero), process_renames()
> and process_entry() are supposed to be forcing the conflicts resolved,
> recording the contents with conflict markers if necessary, before the
> control gets to that point, so it clearly is a bug very specific to the
> recursive merge implementation.

Setting breakpoints on process_renames() and process_entry() shows that
they are being executed.  Is there anything I can gather from their
execution that would help you?

Tim