public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Tim Olsen <tim@brooklynpenguin•com>
Cc: git@vger•kernel.org, Miklos Vajna <vmiklos@frugalware•org>,
	Johannes Schindelin <johannes.schindelin@gmx•de>
Subject: Re: git-merge segfault in 1.6.6 and master
Date: Wed, 20 Jan 2010 11:13:01 -0800	[thread overview]
Message-ID: <7vocko3802.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <hj7abm$5vc$1@ger.gmane.org> (Tim Olsen's message of "Wed\, 20 Jan 2010 11\:17\:56 -0500")

Tim Olsen <tim@brooklynpenguin•com> writes:

> The following happens on 1.6.6 and master as of
> 5b15950ac414a8a2d4f5eb480712abcc9fe176d2.  The problem goes away if I
> use the resolve merge strategy instead.

Thanks.

Since you can build and run git yourself, can I ask you to run another
experiment with this one-liner patch applied?

diff --git a/builtin-merge.c b/builtin-merge.c
index 82e2a04..08a8f24 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -550,7 +550,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
 		return error("Unable to write index.");
 	rollback_lock_file(lock);
 
-	if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
+	if (0) {
 		int clean;
 		struct commit *result;
 		struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));

This disables the codepath that special-cases the calling convention for
these merge strategies, and was introduce by 18668f5 (builtin-merge: avoid
run_command_v_opt() for recursive and subtree, 2008-08-28 -- authors Cc'ed
to ask for help in diagnosing).

If this experiment "fixes" the failure for you, then it would be a sign
that the caller (not necessarily in the code in this "if()" block) may be
doing something wrong (or more likely, not doing enough) before calling
into merge_recursive().  I am suspecting that it is not parsing some
commit objects properly, e.g. using lookup_commit(SHA-1) and using the
result without calling parse_object() on it first, or something similar
that is silly but trivial to fix.

After the experiment, please revert the above one-liner.  I don't want to
use a work-around forever; we'd be better off finding where in the code it
goes wrong.  Looking at your gdb trace, I notice...

> (gdb) r
> Starting program: /usr/local/bin/git merge origin/deployed
> [Thread debugging using libthread_db enabled]
> ...
> #3  0x0000000000499523 in merge_trees (o=0x7fffffffd5b0, head=0x77b058,
> merge=0x77b030, common=0x0, result=0x7fffffffd548) at merge-recursive.c:1209
>         code = 8076320
>         clean = 13064

"common = NULL" means merged_common_ancestors->tree is NULL in the caller.
Somebody is passing a bogus commit in "ca" (aka common ancestors) list
when calling merge_recursive(), or forgetting to parse them before calling
it.  In your debugger could you find out where it comes from and what it
has before this call into merge_trees() is made?  Specifically, what the
"ca" list at 0x7b3c00 contains, and how "merged_common_ancestors" at
0x121e360 looks like. in this trace we see below:

> #4  0x0000000000499a46 in merge_recursive (o=0x7fffffffd5b0,
> h1=0x7932d0, h2=0x793240, ca=0x7b3c00, result=0x7fffffffd628) at
> merge-recursive.c:1343

  reply	other threads:[~2010-01-20 19:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-20 16:17 git-merge segfault in 1.6.6 and master Tim Olsen
2010-01-20 19:13 ` Junio C Hamano [this message]
2010-01-20 21:57   ` Tim Olsen
2010-01-20 22:21     ` Junio C Hamano
2010-01-21 16:37       ` Tim Olsen
2010-01-21 18:12         ` Junio C Hamano
2010-01-22  0:21           ` Junio C Hamano
2010-01-22  0:38             ` Junio C Hamano
2010-01-21 14:00     ` Miklos Vajna
2010-01-21 21:56       ` Tim Olsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vocko3802.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=johannes.schindelin@gmx$(echo .)de \
    --cc=tim@brooklynpenguin$(echo .)com \
    --cc=vmiklos@frugalware$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox