Re: git-merge segfault in 1.6.6 and master

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 21, 2010, 18:12 UTC
Message-ID: <7viqavs4xc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B5882BD.3090908@brooklynpenguin.com>

Tim Olsen <tim@brooklynpenguin.com> writes:

Show 9 quoted lines

>> 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?

When they are called with non-zero o->call_depth, they are supposed to drop all the index entries that they handle down to stage #0 (even if the path had contents level conflict). For example, you see this bit in process_entry():

	} else if (a_sha && b_sha) {
		/* Case C: Added in both (check for same permissions) and */
		/* case D: Modified in both, but differently. */
		const char *reason = "content";
		...
		mfi = merge_file(o, &one, &a, &b,
				 o->branch1, o->branch2);

		clean_merge = mfi.clean;
		if (!mfi.clean) {
			if (S_ISGITLINK(mfi.mode))
				reason = "submodule";
			output(o, 1, "CONFLICT (%s): Merge conflict in %s",
					reason, path);
		}
		update_file(o, mfi.clean, mfi.sha, mfi.mode, path);
	} ...

and update_file() eventually calls update_file_flags() to make sure that the content in mfi.sha is at the stage #0 of path when o->call_depth is non-zero (or mfi.clean is true). process_renames() and process_entry() are humongous functions that handle full of different cases, but all codepaths must follow the rule not to leave non-stage #0 entries in the index before merge_trees() function calls write_tree_from_memory().

We've fixed a similar bug in c94736a (merge-recursive: don't segfault while handling rename clashes, 2009-07-30) and I think there were similar breakages we fixed over time in the same area, but the two functions being as huge as they are, I suspect you are hitting a codepath that hasn't been fixed.