Segfault on merge with 1.6.2.1

Greetings.

I'm trying to figure out what's going on with a merge I'm trying to do. As far as I know, it's a fairly standard situation, just merging two branches. But I get a segfault each time. This occurs with 1.5.6.5 and 1.6.2.1. The earlier version is on a Debian Etch box with backports.debian.org. The latter is Debian Sid. I also tried on a Windows box with MSysGit 1.6.2.1-preview20090322.exe.

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.

I'm using the default configuration, with only a few basic options in my person .gitconfig.

Unfortunately, I cannot post the archive, but I can tar the archive and share that with individuals, if need be.

The problems started with a weird merge by another developer a while ago that somehow reapplied earlier commits. It looked like he had done some commits that wiped some earlier commits but then a commit or two latter the old commits were added back. When I tried to merge the resulting master into my working branch it segfaulted. I didn't have time (or the immediate need) to look into it then and it's been forgotten until now (when, of course, it needs to be done in the next few days :( ).

I have run git gc and also pruned a couple of minor dangling objects. Running git fsck --full reveals no problems. The largest file is about 6MiB.

I've asked on #git, and drizzd there suggested I try here. At this point I'm completely at a loss.

Any help would be greatly appreciated.

Thanks, Michael

On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson <redbeard@mdjohnson.us> wrote:

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?

On Sun, 29 Mar 2009 07:17:00 -0500, Miklos Vajna <vmiklos@frugalware.org> wrote:

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

Thanks for the continuing help.

Michael

Hi,

On Sun, 29 Mar 2009, Michael Johnson wrote:

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: 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 ++++++++-------

On Sun, Mar 29, 2009 at 09:39:49PM -0500, Michael Johnson <redbeard@mdjohnson.us> wrote:

Okay, no rush. In case Dscho's patch does not fix your problem, please rebuild git with debug symbols enabled and send a normal trace.

Thanks.

On Mon, 30 Mar 2009 06:03:35 -0500, Miklos Vajna <vmiklos@frugalware.org> wrote:

It would appear that the patch has already been applied to 1.6.2.1.

That said, here's my backtrace. I've tried tracing through to figure out where the problem is occurring, but my gdb-foo is non-existent, I'm wating for some GUIs to install, and I'm ready for some sleep :| So if I haven't heard back by tomorrow evening, I'll be running one of the frontends for gdb until I have something traced down :)

If you need any more information, please let me know.

Thanks, Michael

(gdb) run merge origin/dojo-1.3 Starting program: /usr/bin/git merge origin/dojo-1.3 [Thread debugging using libthread_db enabled] [New Thread 0xb7b1bb30 (LWP 2651)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b1bb30 (LWP 2651)]
0x080fa828 in parse_tree (item=0x0) at tree.c:250
250		if (item->object.parsed)
(gdb) backtrace
#0  0x080fa828 in parse_tree (item=0x0) at tree.c:250
#1  0x080cc40b in init_tree_desc_from_tree (desc=0xbfdf53ac, tree=0x0) at  
merge-recursive.c:161
#2  0x080cc4d4 in git_merge_trees (index_only=1, common=0x8fa5df8,  
head=0x0, merge=0x8fa5718) at merge-recursive.c:186
#3  0x080cf28e in merge_trees (o=0xbfdf54d0, head=0x0, merge=0x8fa5718,  
common=0x8fa5df8, result=0xbfdf5448)
     at merge-recursive.c:1170
#4  0x080cf75f in merge_recursive (o=0xbfdf54d0, h1=0x8ffc200,  
h2=0x8f992f0, ca=0x0, result=0xbfdf548c)
     at merge-recursive.c:1294
#5  0x080cf6c7 in merge_recursive (o=0xbfdf54d0, h1=0x8f99050,  
h2=0x8f98ff0, ca=0x8f97b98, result=0xbfdf551c)
     at merge-recursive.c:1280
#6  0x08080d75 in try_merge_strategy (strategy=0x811b9b0 "recursive",  
common=0x8fd40f0, head_arg=0x811be14 "HEAD")
     at builtin-merge.c:566
#7  0x08082446 in cmd_merge (argc=1, argv=0xbfdf5808, prefix=0x0) at  
builtin-merge.c:1111
#8  0x0804bb5f in run_builtin (p=0x8130400, argc=2, argv=0xbfdf5808) at  
git.c:244
#9  0x0804bcf3 in handle_internal_command (argc=2, argv=0xbfdf5808) at  
git.c:388
#10 0x0804bdf0 in run_argv (argcp=0xbfdf5780, argv=0xbfdf5784) at git.c:434
#11 0x0804bf82 in main (argc=2, argv=0xbfdf5808) at git.c:505

On Tue, 31 Mar 2009 02:14:21 -0500, Michael Johnson <redbeard@mdjohnson.us> wrote:

I tried tracing it manually with KDbg tonight. But either I'm too tired (and my patience is low), or I'm just not capable of understanding it. I hope it's the former, since I was able to follow the basic flow well enough. But I still wasn't terribly happy with the front end. It's obvious that gdb is awesome, I'm just not ready for it yet :)

Anyway, I decided to try an experiment, as I had mentioned to someone that if I couldn't get this bug tracked down, I'd have to do the merge manually. So... I figured out the common ancestor (I used git show-branch, but I'm betting there's an easier way), and merged the ancestor + 1 of the other branch into my HEAD. It segfaulted. So, I tried the resolve strategy at the same point. Amazingly, it worked. And a default recursive merge handled the rest.

That means my current problem is resolved, but I'm guessing a segfault on a default merge is still a bad thing, so I'll try to keep up on this. I do have a copy of the repository before the merge (several, right now, actually), so I can try fixes. If I'm lucky I'll have some time to work on it myself. But it will be at least two weeks before I actually have the time to personally track down the problem without help. However, I should be able to assist someone else fairly easily.

In short, I don't personally need a fix right now, but I can help figure out what is broken with it.

Thanks, Michael

On Wed, Apr 01, 2009 at 12:43:38AM -0500, Michael Johnson <redbeard@mdjohnson.us> wrote:

I initially replied to this thread as I wasn't sure if it's a bug in merge-recursive or builtin-merge itself. I'm not that familiar with merge-recursive, that's why I didn't reply so far. ;-)

If you don't need rename detection, you can merge with '-s resolve', I think that would do what you need and it avoids the problematic codepath.

On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote:

I don't think it has. But judging from the stack trace this bug is unrelated to the patch anyways.

If nobody else is dealing with this I'd like to have a look at it. Could you please send me a copy of the repo.

Thanks, Clemens

On Wed, 01 Apr 2009 13:06:27 -0500, Clemens Buchacher <drizzd@aon.at> wrote:

When I tried to appy the patch I got a conflict (I applied it directly to Debian's source package for git-core). When I compared the code to the patch it appeared it had been applied. Of course, I'm far from an expert at applying patches, so I might have misread the direction of the patch.

It doesn't sound like anyone else is. So I'll send you a copy shortly, off list.

Thanks for all the help, Michael

Hi,

The segmentation fault is caused by a null pointer dereference which happens during recursive merge with a submodule conflict between two merge bases. This is fixed by the following patches.

However, there are other problems with merging submodules. For example, git diff aborts with "fatal: read error 'sub'" for conflicting submodules. I have also added a test for this.

Dscho has already started working on related issues. I have therefore skipped t7404, which is already used in Dscho's work.

Clemens

 merge-recursive.c          |   16 ++-------
 t/t7405-submodule-merge.sh |   74 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+), 12 deletions(-)

[PATCH 1/3] add tests for merging with submodules [PATCH 2/3] update cache for conflicting submodule entries [PATCH 3/3] simplify output of conflicting merge

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
 t/t7405-submodule-merge.sh |   74 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100755 t/t7405-submodule-merge.sh

When merging merge bases during a recursive merge we do not want to leave any unmerged entries. Otherwise we cannot create a temporary tree for the recursive merge to work with.

We failed to do so in case of a submodule conflict between merge bases, causing a NULL pointer dereference in the next step of the recursive merge.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
 merge-recursive.c          |    5 +++--
 t/t7405-submodule-merge.sh |    2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

This simplifies the code without changing the semantics and removes the unhelpful "needs $sha1" part of the conflicting submodule message.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
 merge-recursive.c |   17 ++++-------------
 1 files changed, 4 insertions(+), 13 deletions(-)

Will queue, forking from maint.  Thanks.

Hi,

On Sun, 5 Apr 2009, Clemens Buchacher wrote:

Thanks for working on this, Dscho

On Sat, 04 Apr 2009 19:46:57 -0500, Clemens Buchacher <drizzd@aon.at> wrote:

Amazingly I follow that. And the tracing I was doing now makes sense. I saw the null pointer dereference, but couldn't figure out why. The submodule conflict explains some things about what was going on in the tree.

This also explains a lot. Is there any way to get this sort of simplified representation from the existing tools? I would think gitk would show it, but would I be able to recognize it.?

I believe there's a GSoC proposal that would help with this... from what I read of it, it could prove very helpful to my workflow.

Anyway, thanks for all the help. I'll merge the patches in locally and see if they work for me when I get a bit of time. I'm sure they will... it's just for my own peace of mind.

Thanks again, Michael

On Sun, Apr 05, 2009 at 09:29:33PM -0500, Michael Johnson wrote:

I simply tagged everything that showed up in "git merge-base --all" and then I did "gitk --all --simplify-by-decoration". That shows pretty much the graph above.