Re: Segfault on merge with 1.6.2.1

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 30, 2009, 07:48 UTC
Message-ID: <alpine.DEB.1.00.0903300944350.7534@intel-tinevez-2-302>
In-Reply-To: <op.urk20nanso3nzr@sulidor.mdjohnson.us>

Hi,

On Sun, 29 Mar 2009, Michael Johnson wrote:

Show 48 quoted lines

> On Sun, 29 Mar 2009 07:17:00 -0500, Miklos Vajna <vmiklos@frugalware.org>
> wrote:
> 
> >On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson
> ><redbeard@mdjohnson.us> wrote:
> > >The 1.6.2.1 version just segfaults, but 1.5.6.5 says:
> > >
> > >/usr/bin/git-merge: line 438: 32335 Segmentation fault
> > >git-merge-$strategy $common -- "$head_arg" "$@"
> > >Merge with strategy recursive failed.
> > >
> > >In all cases, .git/index.lock is left behind.
> >
> >That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
> >directly without a fork. Could you try it in gdb and provide a
> >backtrace, please?
> 
> Well, I've got a backtrace, but I don't have debugging symbols, apparently.
> There is not a Debian package I can find that has them. I checked
> debug.debian.net, as well as the standard sid repository. So I will have to
> rebuild the package with debugging turned on. I will not be able to do that
> tonight, unfortunately. I will probably have a chance tomorrow evening.
> 
> Just in case it might be useful, though, here's the backtrace, without
> symbols.
> 
> Starting program: /usr/bin/git merge origin/dojo-1.3
> (no debugging symbols found)
> ... repeated multiple times ...
> [Thread debugging using libthread_db enabled]
> (no debugging symbols found)
> ... repeated multiple times
> [New Thread 0xb7a73b30 (LWP 21505)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7a73b30 (LWP 21505)]
> 0x080e5a6f in ?? ()
> (gdb) backtrace
> #0  0x080e5a6f in ?? ()
> #1  0x0893e000 in ?? ()
> #2  0x000f0000 in ?? ()
> #3  0xbf949098 in ?? ()
> #4  0x080e63ad in ?? ()
> #5  0x08977fcf in ?? ()
> #6  0x000f0000 in ?? ()
> #7  0xfff0ffff in ?? ()
> #8  0x08945dd8 in ?? ()
> #9  0x00000000 in ?? ()

This segfault sounds vaguely like something I tried to fix. Unfortunately, I cannot spend time on it right now, except send you the patch that could help the issue:

-- snipsnap --

>From 084909acbb576be4c4815e047ee4247b95c70cda Mon Sep 17 00:00:00 2001

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mon, 10 Nov 2008 23:25:31 +0100
Subject: [PATCH] merge-recursive: fail gracefully with directory/submodule conflicts

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 merge-recursive.c         |   15 ++++++++-------

diff --git a/merge-recursive.c b/merge-recursive.c
index 3e1bc3e..8ada5a9 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -519,14 +519,14 @@ static void update_file_flags(struct merge_options *o,
 		void *buf;
 		unsigned long size;
 
-		if (S_ISGITLINK(mode))
-			die("cannot read object %s '%s': It is a submodule!",
-			    sha1_to_hex(sha), path);
-
-		buf = read_sha1_file(sha, &type, &size);
+		if (S_ISGITLINK(mode)) {
+			buf = xstrdup(sha1_to_hex(sha));
+			size = strlen(buf);
+		} else
+			buf = read_sha1_file(sha, &type, &size);
 		if (!buf)
 			die("cannot read object %s '%s'", sha1_to_hex(sha), path);
-		if (type != OBJ_BLOB)
+		if (!S_ISGITLINK(mode) && type != OBJ_BLOB)
 			die("blob expected for %s '%s'", sha1_to_hex(sha), path);
 		if (S_ISREG(mode)) {
 			struct strbuf strbuf = STRBUF_INIT;
@@ -542,7 +542,8 @@ static void update_file_flags(struct merge_options *o,
 			free(buf);
 			goto update_index;
 		}
-		if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) {
+		if (S_ISGITLINK(mode) || S_ISREG(mode) ||
+				(!has_symlinks && S_ISLNK(mode))) {
 			int fd;
 			if (mode & 0100)
 				mode = 0777;