git blame crashes with internal error

Hi Junio,

git blame just decided to crash on me, when I tried to use it while resolving a merge conflict. Interesting is probably, that it crashes when given the filename of a file that is not _directly_ affected by the merge, but contains code that originates from a file that caused conlicts.

Error message is: fatal: internal error: ce_mode is 0

I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current master and all of them crashed. A small shell script to reproduce the problem is attached.

Thanks, Björn

Björn Steinbrink wrote:

Manual bisect? Ugh. This *is* the century of the competent developer tools, you know... ;-)

Andreas Ericsson <ae@op5.se> writes:

It's not a "bisect" when it crashes in all versions.

On Sun, Oct 14, 2007 at 02:56:31PM +0000, David Kastrup wrote:

  What What, git cannot bisect future versions ??? *g* what a
disappointment.

On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:

Then, how do I search for a good version with git bisect if I only have the one data-point "master is bad"?

All I tried when testing those 5 versions was trying to find a good version so that I can actually do an automatic bisect. And I stopped at 1.5.3 because I figured that my test-case is probably just pretty uncommon and was basically always broken.

Another manual "bisect" shows that 1.5.0 also crashes and as 1.4.0 doesn't even want to read my git git repository, I don't intend to go even further backwards in the history to find a good commit, unless someone tells me that it is a really good idea or how to automate finding a good commit in a sane way.

Björn

Hi,

On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:

AFAIK Junio introduced the option to start with just a bad commit, and no known "good" one.

Yep, just found it. Since v1.5.2-rc0~77^2(git-bisect: allow bisecting with only one bad commit.) it is supported.

    This allows you to say:

        git bisect start
        git bisect bad $bad
        git bisect next

I don't know if it is in the documentation (I rarely read it), so if it is missing, it would be nice if you could add the description there.

Ciao, Dscho

On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:

OK, using that approach, I bisected it, and even found a "guilty" commit, although it is pretty much useless:

1cfe77333f274c9ba9879c2eb61057a790eb050f is first bad commit
commit 1cfe77333f274c9ba9879c2eb61057a790eb050f
Author: Junio C Hamano <junkio@cox.net>
Date:   Tue Jan 30 01:11:08 2007 -0800

    git-blame: no rev means start from the working tree file.

    Warning: this changes the semantics.

    This makes "git blame" without any positive rev to start digging
    from the working tree copy, which is made into a fake commit
    whose sole parent is the HEAD.

    It also adds --contents <file> option to pretend as if the
    working tree copy has the contents of the named file.  You can
    use '-' to make the command read from the standard input.

    If you want the command to start annotating from the HEAD
    commit, you need to explicitly give HEAD parameter.

    Signed-off-by: Junio C Hamano <junkio@cox.net>

Nothing in there yet AFAICT. Will try to get a patch done tomorrow.

thanks, Björn

Hi,

On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:

I think it is not useless. It says exactly the same as I did, in another reply: git blame starts with your working tree. As such, it has to do some operations which happen to fail on unmerged files.

So the solution in your case _really_ is:

	git blame HEAD file2

Explanation: with that command line, you ask git blame to start with a 
given revision (instead of the working tree), which just so happens to be 
the HEAD revision.

Hth, Dscho

Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:

It is not crashing. It is just not handling unexpected situation properly:

    $ testcase.sh
    ...
    Switched to branch "foo"
    CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.
    Automatic merge failed; fix conflicts and then commit the result.
    fatal: internal error: ce_mode is 0
    $ git ls-files --cached --stage
    100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1       file1
    100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3       file1
    100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0       file2

See? There is an unresolved merge.

The question is, what's the problem...

Alex Riesen, Sun, Oct 14, 2007 18:37:02 +0200:

FWIW, backtrace. I'm giving up for today. Anyone?

(gdb) bt
#0  0x080b6ac5 in die_builtin (err=0x80f3b92 "internal error: ce_mode is %o", 
    params=0xbfd91c34 "") at usage.c:24
#1  0x080b6b84 in die (err=0x80f3b92 "internal error: ce_mode is %o")
    at usage.c:76
#2  0x080a3883 in ce_match_stat_basic (ce=0xb7f6a00c, st=0xbfd91cb8)
    at read-cache.c:153
#3  0x080a398f in ie_match_stat (istate=0x81342e0, ce=0xb7f6a00c, 
    st=0xbfd91cb8, options=0) at read-cache.c:208
#4  0x080c87f3 in reuse_worktree_file (name=0x814c698 "file1", 
    sha1=0x814c668 "r\023\2378\2256y�\031��\223\214G\235s�{Y\230�024\b", 
    want_file=0) at diff.c:1499
#5  0x080c8a6f in diff_populate_filespec (s=0x814c668, size_only=1)
    at diff.c:1565
#6  0x080d0ab2 in is_exact_match (src=0x814c668, dst=0x814ca20, contents_too=1)
    at diffcore-rename.c:108
#7  0x080d13aa in diffcore_rename (options=0xbfd91edc) at diffcore-rename.c:335
#8  0x080ccaef in diffcore_std (options=0xbfd91edc) at diff.c:3120
#9  0x08054c33 in find_rename (sb=0xbfd921e8, parent=0x81377c0, 
    origin=0x814c5e0) at builtin-blame.c:427
#10 0x080563a3 in pass_blame (sb=0xbfd921e8, origin=0x814c5e0, opt=0)
    at builtin-blame.c:1216
#11 0x08056d09 in assign_blame (sb=0xbfd921e8, revs=0xbfd92068, opt=0)
    at builtin-blame.c:1501
#12 0x0805942a in cmd_blame (argc=2, argv=0xbfd92404, prefix=0x0)
    at builtin-blame.c:2414
#13 0x0804b7d8 in run_command (p=0x80fa8d0, argc=2, argv=0xbfd92404)
    at git.c:284
#14 0x0804b97a in handle_internal_command (argc=2, argv=0xbfd92404)
    at git.c:398
#15 0x0804ba52 in main (argc=2, argv=0xbfd92404) at git.c:435
(gdb)

Hi,

On Sun, 14 Oct 2007, Alex Riesen wrote:

I _think_ that what blame does here is correct. It wants to handle the rename case, and because of the conflicts, it cannot determine the renames.

The proper thing to do now would be

	git blame HEAD file2

since you want to exclude the working tree from the blaming.

I agree that the error message is not really helping here, though. Since we are not really libified, I do not see an easy way to help here, either, short of git-blame checking for unmerged entries.

Ciao, Dscho

On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:

Yes. What's going on is that "ce_mode = 0" is a magic marker for an unmerged entry (set up by things like diff-lib.c:do_diff_cache() and builtin-read-tree.c:read_tree_unmerged()) and the ce_match_stat_basic() function gets upset about this.

I'm not entirely sure that the whole "ce_mode = 0" case is a good idea to begin with, and maybe the right thing to do is to remove that horrid freakish special case, but removing the internal error seems to be the simplest fix for now.

		Linus

---
 read-cache.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)