* Segfault on merge with 1.6.2.1 @ 2009-03-28 16:19 Michael Johnson 2009-03-29 12:17 ` Miklos Vajna 0 siblings, 1 reply; 18+ messages in thread From: Michael Johnson @ 2009-03-28 16:19 UTC (permalink / raw) To: git 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 -- Michael D Johnson <redbeard@mdjohnson.us> redbeardcreator.deviantart.com "Marketing research...[has] shown that energy weapons that make sounds sell better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-28 16:19 Segfault on merge with 1.6.2.1 Michael Johnson @ 2009-03-29 12:17 ` Miklos Vajna 2009-03-30 2:39 ` Michael Johnson 0 siblings, 1 reply; 18+ messages in thread From: Miklos Vajna @ 2009-03-29 12:17 UTC (permalink / raw) To: Michael Johnson; +Cc: git [-- Attachment #1: Type: text/plain, Size: 519 bytes --] 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? [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-29 12:17 ` Miklos Vajna @ 2009-03-30 2:39 ` Michael Johnson 2009-03-30 7:48 ` Johannes Schindelin 2009-03-30 11:03 ` Miklos Vajna 0 siblings, 2 replies; 18+ messages in thread From: Michael Johnson @ 2009-03-30 2:39 UTC (permalink / raw) To: Miklos Vajna; +Cc: git 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 ?? () Thanks for the continuing help. Michael -- Michael D Johnson <redbeard@mdjohnson.us> redbeardcreator.deviantart.com "Marketing research...[has] shown that energy weapons that make sounds sell better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-30 2:39 ` Michael Johnson @ 2009-03-30 7:48 ` Johannes Schindelin 2009-03-30 11:03 ` Miklos Vajna 1 sibling, 0 replies; 18+ messages in thread From: Johannes Schindelin @ 2009-03-30 7:48 UTC (permalink / raw) To: Michael Johnson; +Cc: Miklos Vajna, git Hi, On Sun, 29 Mar 2009, Michael Johnson wrote: > 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; ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-30 2:39 ` Michael Johnson 2009-03-30 7:48 ` Johannes Schindelin @ 2009-03-30 11:03 ` Miklos Vajna 2009-03-31 7:14 ` Michael Johnson 1 sibling, 1 reply; 18+ messages in thread From: Miklos Vajna @ 2009-03-30 11:03 UTC (permalink / raw) To: Michael Johnson; +Cc: git [-- Attachment #1: Type: text/plain, Size: 634 bytes --] On Sun, Mar 29, 2009 at 09:39:49PM -0500, Michael Johnson <redbeard@mdjohnson.us> 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. 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. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-30 11:03 ` Miklos Vajna @ 2009-03-31 7:14 ` Michael Johnson 2009-04-01 5:43 ` Michael Johnson 2009-04-01 18:06 ` Clemens Buchacher 0 siblings, 2 replies; 18+ messages in thread From: Michael Johnson @ 2009-03-31 7:14 UTC (permalink / raw) To: Miklos Vajna; +Cc: git On Mon, 30 Mar 2009 06:03:35 -0500, Miklos Vajna <vmiklos@frugalware.org> wrote: > On Sun, Mar 29, 2009 at 09:39:49PM -0500, Michael Johnson > <redbeard@mdjohnson.us> 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. > > 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. > 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 -- Michael D Johnson <redbeard@mdjohnson.us> redbeardcreator.deviantart.com "Marketing research...[has] shown that energy weapons that make sounds sell better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-31 7:14 ` Michael Johnson @ 2009-04-01 5:43 ` Michael Johnson 2009-04-01 9:50 ` Miklos Vajna 2009-04-01 18:06 ` Clemens Buchacher 1 sibling, 1 reply; 18+ messages in thread From: Michael Johnson @ 2009-04-01 5:43 UTC (permalink / raw) To: Miklos Vajna; +Cc: git On Tue, 31 Mar 2009 02:14:21 -0500, Michael Johnson <redbeard@mdjohnson.us> wrote: > 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 :) 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 -- Michael D Johnson <redbeard@mdjohnson.us> redbeardcreator.deviantart.com "Marketing research...[has] shown that energy weapons that make sounds sell better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-04-01 5:43 ` Michael Johnson @ 2009-04-01 9:50 ` Miklos Vajna 0 siblings, 0 replies; 18+ messages in thread From: Miklos Vajna @ 2009-04-01 9:50 UTC (permalink / raw) To: Michael Johnson; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1036 bytes --] On Wed, Apr 01, 2009 at 12:43:38AM -0500, Michael Johnson <redbeard@mdjohnson.us> wrote: > 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. 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. ;-) > In short, I don't personally need a fix right now, but I can help figure > out what is broken with it. 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. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-03-31 7:14 ` Michael Johnson 2009-04-01 5:43 ` Michael Johnson @ 2009-04-01 18:06 ` Clemens Buchacher 2009-04-02 0:33 ` Michael Johnson 2009-04-05 0:46 ` Clemens Buchacher 1 sibling, 2 replies; 18+ messages in thread From: Clemens Buchacher @ 2009-04-01 18:06 UTC (permalink / raw) To: Michael Johnson; +Cc: Miklos Vajna, git On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote: > It would appear that the patch has already been applied to 1.6.2.1. 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-04-01 18:06 ` Clemens Buchacher @ 2009-04-02 0:33 ` Michael Johnson 2009-04-05 0:46 ` Clemens Buchacher 1 sibling, 0 replies; 18+ messages in thread From: Michael Johnson @ 2009-04-02 0:33 UTC (permalink / raw) To: Clemens Buchacher; +Cc: Miklos Vajna, git On Wed, 01 Apr 2009 13:06:27 -0500, Clemens Buchacher <drizzd@aon.at> wrote: > On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote: >> It would appear that the patch has already been applied to 1.6.2.1. > > I don't think it has. But judging from the stack trace this bug is > unrelated to the patch anyways. 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. > 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. It doesn't sound like anyone else is. So I'll send you a copy shortly, off list. Thanks for all the help, Michael -- Michael D Johnson <redbeard@mdjohnson.us> redbeardcreator.deviantart.com "Marketing research...[has] shown that energy weapons that make sounds sell better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-04-01 18:06 ` Clemens Buchacher 2009-04-02 0:33 ` Michael Johnson @ 2009-04-05 0:46 ` Clemens Buchacher 2009-04-05 0:46 ` [PATCH 1/3] add tests for merging with submodules Clemens Buchacher ` (2 more replies) 1 sibling, 3 replies; 18+ messages in thread From: Clemens Buchacher @ 2009-04-05 0:46 UTC (permalink / raw) To: git; +Cc: Miklos Vajna, Michael Johnson, Johannes Schindelin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 1/3] add tests for merging with submodules 2009-04-05 0:46 ` Clemens Buchacher @ 2009-04-05 0:46 ` Clemens Buchacher 2009-04-05 0:46 ` [PATCH 2/3] update cache for conflicting submodule entries Clemens Buchacher 2009-04-05 11:50 ` Segfault on merge with 1.6.2.1 Johannes Schindelin 2009-04-06 2:29 ` Michael Johnson 2 siblings, 1 reply; 18+ messages in thread From: Clemens Buchacher @ 2009-04-05 0:46 UTC (permalink / raw) To: git; +Cc: Miklos Vajna, Michael Johnson, Johannes Schindelin, Clemens Buchacher 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 diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh new file mode 100755 index 0000000..9778ad4 --- /dev/null +++ b/t/t7405-submodule-merge.sh @@ -0,0 +1,74 @@ +#!/bin/sh + +test_description='merging with submodules' + +. ./test-lib.sh + +# +# history +# +# a --- c +# / \ / +# root X +# \ / \ +# b --- d +# + +test_expect_success setup ' + + mkdir sub && + (cd sub && + git init && + echo original > file && + git add file && + test_tick && + git commit -m sub-root) && + git add sub && + test_tick && + git commit -m root && + + git checkout -b a master && + (cd sub && + echo A > file && + git add file && + test_tick && + git commit -m sub-a) && + git add sub && + test_tick && + git commit -m a && + + git checkout -b b master && + (cd sub && + echo B > file && + git add file && + test_tick && + git commit -m sub-b) && + git add sub && + test_tick && + git commit -m b + + git checkout -b c a && + git merge -s ours b && + + git checkout -b d b && + git merge -s ours a +' + +test_expect_failure 'merging with modify/modify conflict' ' + + git checkout -b test1 a && + test_must_fail git merge b && + test -f .git/MERGE_MSG && + git diff + +' + +test_expect_failure 'merging with a modify/modify conflict between merge bases' ' + + git reset --hard HEAD && + git checkout -b test2 c && + git merge d + +' + +test_done -- 1.6.2.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/3] update cache for conflicting submodule entries 2009-04-05 0:46 ` [PATCH 1/3] add tests for merging with submodules Clemens Buchacher @ 2009-04-05 0:46 ` Clemens Buchacher 2009-04-05 0:47 ` [PATCH 3/3] simplify output of conflicting merge Clemens Buchacher 0 siblings, 1 reply; 18+ messages in thread From: Clemens Buchacher @ 2009-04-05 0:46 UTC (permalink / raw) To: git; +Cc: Miklos Vajna, Michael Johnson, Johannes Schindelin, Clemens Buchacher 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(-) diff --git a/merge-recursive.c b/merge-recursive.c index 3e1bc3e..f1b120b 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1118,10 +1118,11 @@ static int process_entry(struct merge_options *o, clean_merge = mfi.clean; if (mfi.clean) update_file(o, 1, mfi.sha, mfi.mode, path); - else if (S_ISGITLINK(mfi.mode)) + else if (S_ISGITLINK(mfi.mode)) { output(o, 1, "CONFLICT (submodule): Merge conflict in %s " "- needs %s", path, sha1_to_hex(b.sha1)); - else { + update_file(o, 0, mfi.sha, mfi.mode, path); + } else { output(o, 1, "CONFLICT (%s): Merge conflict in %s", reason, path); diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh index 9778ad4..aa6c44c 100755 --- a/t/t7405-submodule-merge.sh +++ b/t/t7405-submodule-merge.sh @@ -63,7 +63,7 @@ test_expect_failure 'merging with modify/modify conflict' ' ' -test_expect_failure 'merging with a modify/modify conflict between merge bases' ' +test_expect_success 'merging with a modify/modify conflict between merge bases' ' git reset --hard HEAD && git checkout -b test2 c && -- 1.6.2.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 3/3] simplify output of conflicting merge 2009-04-05 0:46 ` [PATCH 2/3] update cache for conflicting submodule entries Clemens Buchacher @ 2009-04-05 0:47 ` Clemens Buchacher 2009-04-05 9:47 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Clemens Buchacher @ 2009-04-05 0:47 UTC (permalink / raw) To: git; +Cc: Miklos Vajna, Michael Johnson, Johannes Schindelin, Clemens Buchacher 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(-) diff --git a/merge-recursive.c b/merge-recursive.c index f1b120b..d6f0582 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1116,22 +1116,13 @@ static int process_entry(struct merge_options *o, o->branch1, o->branch2); clean_merge = mfi.clean; - if (mfi.clean) - update_file(o, 1, mfi.sha, mfi.mode, path); - else if (S_ISGITLINK(mfi.mode)) { - output(o, 1, "CONFLICT (submodule): Merge conflict in %s " - "- needs %s", path, sha1_to_hex(b.sha1)); - update_file(o, 0, mfi.sha, mfi.mode, path); - } else { + if (!mfi.clean) { + if (S_ISGITLINK(mfi.mode)) + reason = "submodule"; output(o, 1, "CONFLICT (%s): Merge conflict in %s", reason, path); - - if (o->call_depth) - update_file(o, 0, mfi.sha, mfi.mode, path); - else - update_file_flags(o, mfi.sha, mfi.mode, path, - 0 /* update_cache */, 1 /* update_working_directory */); } + update_file(o, mfi.clean, mfi.sha, mfi.mode, path); } else if (!o_sha && !a_sha && !b_sha) { /* * this entry was deleted altogether. a_mode == 0 means -- 1.6.2.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] simplify output of conflicting merge 2009-04-05 0:47 ` [PATCH 3/3] simplify output of conflicting merge Clemens Buchacher @ 2009-04-05 9:47 ` Junio C Hamano 0 siblings, 0 replies; 18+ messages in thread From: Junio C Hamano @ 2009-04-05 9:47 UTC (permalink / raw) To: Clemens Buchacher; +Cc: git, Miklos Vajna, Michael Johnson, Johannes Schindelin Will queue, forking from maint. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-04-05 0:46 ` Clemens Buchacher 2009-04-05 0:46 ` [PATCH 1/3] add tests for merging with submodules Clemens Buchacher @ 2009-04-05 11:50 ` Johannes Schindelin 2009-04-06 2:29 ` Michael Johnson 2 siblings, 0 replies; 18+ messages in thread From: Johannes Schindelin @ 2009-04-05 11:50 UTC (permalink / raw) To: Clemens Buchacher; +Cc: git, Miklos Vajna, Michael Johnson Hi, On Sun, 5 Apr 2009, Clemens Buchacher wrote: > 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. Thanks for working on this, Dscho ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-04-05 0:46 ` Clemens Buchacher 2009-04-05 0:46 ` [PATCH 1/3] add tests for merging with submodules Clemens Buchacher 2009-04-05 11:50 ` Segfault on merge with 1.6.2.1 Johannes Schindelin @ 2009-04-06 2:29 ` Michael Johnson 2009-04-06 6:41 ` Clemens Buchacher 2 siblings, 1 reply; 18+ messages in thread From: Michael Johnson @ 2009-04-06 2:29 UTC (permalink / raw) To: Clemens Buchacher, git; +Cc: Miklos Vajna, Johannes Schindelin On Sat, 04 Apr 2009 19:46:57 -0500, Clemens Buchacher <drizzd@aon.at> wrote: > 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. 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. > +# history > +# > +# a --- c > +# / \ / > +# root X > +# \ / \ > +# b --- d 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.? > 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. 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 -- Michael D Johnson <redbeard@mdjohnson.us> redbeardcreator.deviantart.com "Marketing research...[has] shown that energy weapons that make sounds sell better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Segfault on merge with 1.6.2.1 2009-04-06 2:29 ` Michael Johnson @ 2009-04-06 6:41 ` Clemens Buchacher 0 siblings, 0 replies; 18+ messages in thread From: Clemens Buchacher @ 2009-04-06 6:41 UTC (permalink / raw) To: Michael Johnson; +Cc: git, Miklos Vajna, Johannes Schindelin On Sun, Apr 05, 2009 at 09:29:33PM -0500, Michael Johnson wrote: >> +# history >> +# >> +# a --- c >> +# / \ / >> +# root X >> +# \ / \ >> +# b --- d > > 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 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-04-06 6:43 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-28 16:19 Segfault on merge with 1.6.2.1 Michael Johnson 2009-03-29 12:17 ` Miklos Vajna 2009-03-30 2:39 ` Michael Johnson 2009-03-30 7:48 ` Johannes Schindelin 2009-03-30 11:03 ` Miklos Vajna 2009-03-31 7:14 ` Michael Johnson 2009-04-01 5:43 ` Michael Johnson 2009-04-01 9:50 ` Miklos Vajna 2009-04-01 18:06 ` Clemens Buchacher 2009-04-02 0:33 ` Michael Johnson 2009-04-05 0:46 ` Clemens Buchacher 2009-04-05 0:46 ` [PATCH 1/3] add tests for merging with submodules Clemens Buchacher 2009-04-05 0:46 ` [PATCH 2/3] update cache for conflicting submodule entries Clemens Buchacher 2009-04-05 0:47 ` [PATCH 3/3] simplify output of conflicting merge Clemens Buchacher 2009-04-05 9:47 ` Junio C Hamano 2009-04-05 11:50 ` Segfault on merge with 1.6.2.1 Johannes Schindelin 2009-04-06 2:29 ` Michael Johnson 2009-04-06 6:41 ` Clemens Buchacher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).