Re: git-merge segfault in 1.6.6 and master

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2010, 22:21 UTC
Message-ID: <7vtyugzabq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B577C3F.7040608@brooklynpenguin.com>

Tim Olsen <tim@brooklynpenguin.com> writes:

> At the beginning of merge_recursive(), the local mrtree appears to be
> set to some globally defined mrtree which is not null:

No; that "assignment" is just to squelch warning from gcc. mrtree at that point is uninitialized.

Show 20 quoted lines

> In merge_trees(), mrtree is the argument **result.  It is at line 1255
> that write_tree_from_memory nulls out the pointee of result:
> ...
> Then in write_tree_from_memory() we find the offending return NULL at
> line 210:
>
> 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?

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.