SIGSEGV in merge recursive

This time it happens when merging one of my git trees into another:

$git-pull . git-upstream Trying really trivial in-index merge... fatal: Merge requires file-level merging Nope. git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7 Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7 Merging: 52d5052 Merge branch 'git-upstream' into git-lt-work d985fda Merge branch 'next' into git-upstream found 1 common ancestor(s): 777f684 Merge branch 'next' into git-upstream Auto-merging .gitignore /home/luben/bin/git-merge: line 441: 2889 Segmentation fault git-merge-$strategy $common -- "$head_arg" "$@" Merge with strategy recursive failed.

(git-upstream has already had "next" merged into it without a problem.)

And here is the backtrace:

$gdb ~/bin/git-merge-recursive GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7 Starting program: /home/luben/bin/git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7 Failed to read a valid object file image from memory. Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7 Merging: 52d5052 Merge branch 'git-upstream' into git-lt-work d985fda Merge branch 'next' into git-upstream found 1 common ancestor(s): 777f684 Merge branch 'next' into git-upstream Auto-merging .gitignore

Program received signal SIGSEGV, Segmentation fault.
0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8, 
    name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0, 
    name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore", 
    xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
warning: Source file is more recent than executable.
200                      */
(gdb) bt
#0  0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8, 
    name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0, 
    name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore", 
    xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
#1  0x0804a6c2 in merge_file (o=0xbff3accc, a=0xbff3ac74, b=0xbff3aca0, 
    branch1=0xbff3c928 "HEAD", 
    branch2=0xbff3c92d "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7")
    at merge-recursive.c:660
#2  0x0804c296 in merge_trees (head=0x80924c8, merge=0x80924e8, 
    common=0x8092508, branch1=<value optimized out>, 
    branch2=<value optimized out>, result=0xbff3add0) at merge-recursive.c:1067
#3  0x0804c9cd in merge (h1=0x80874c0, h2=0x8087544, 
    branch1=0xbff3c928 "HEAD", 
    branch2=0xbff3c92d "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7", 
    call_depth=0, ancestor=0x8087518, result=0xbff3ae24)
    at merge-recursive.c:1238
#4  0x0804cc78 in main (argc=3, argv=0xbff3aea4) at merge-recursive.c:1320

      Luben

Luben Tuikov <ltuikov@yahoo.com> writes:

Who says this?

What local mods are you running with?

--- Junio C Hamano <junkio@cox.net> wrote:

Not much -- the one-offs you've sent to git and me to fix various problems I've complained about, some scripts of mine which have nothing to do with merging. The log of the commits diff between next and git-lt-work doesn't show anything in the merge area -- only things I've been active in like gitweb, etc.

     Luben

Hi,

On Fri, 29 Dec 2006, Luben Tuikov wrote:

Again, who says this? I cannot find _anything_ in my local repo (with its own set of modifications, which do not hide such a message).

Given that there is a fix in master for a segfault, I have to admit that I believe you did not use _that_ version, but a git without that fix.

Besides, Alexandre hit an interesting bug, which is not at all easy to reproduce (except with three 70k files which I don't want to include in the test set). Since Alexandre provided _examples_ where I can _reproduce_ the problem, I will be working on that bug, and not yours.

Ciao, Dscho

* Johannes Schindelin:

It's a GDB message.

--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

GDB.  This message is not present when I run it manually from shell prompt.

A-ha! Since I never run master, after I read your message, I compiled master, installed it and tried the same merge/pull and it succeeded -- i.e. didn't segfault, but complained about unresolved conflicts (as it should).

So it appears that the fix is in "master", but not in "next".

Junio, can you confirm this?

    Luben

Luben Tuikov <ltuikov@yahoo.com> writes:

It was merged into 'next' with 1e48a691, about 2 hours after I merged the fix 5d6b151f to 'master'. Sometimes when I have a fix that is urgent enough, I push out only 'master' before merging and retesting it in 'next', so it is plausible that your fetch grabbed such a state.

--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

After compiling and installing "master" I was able to do the pull/merge. The only conflict was in .gitignore, and it was that same conflict that was causing the segfault. Normally (99% of the time) I pull "next" into branchA (git-upstream), then I pull branchA into branchB (git-lt-work). Both have various fixes, but I normally install and use branchB (git-lt-work).

It appears that that fix was in "next" which I hadn't already merged, and running with an old "next" didn't allow me to the the "merge" since the fix for it was in the "next" I was trying to merge...

Thus I needed to install "master" as is ("next" as is, would've worked just as well), which contains the fix for the merge, so that I can merge the branch which contains the fix ("next"/branchA).

I tested this and tried the exact same merge, with the newly merged and installed branchB/git-lt-work, and it did work.

So it's all good now.  Thanks!
   Luben