git blame crashes with internal error

git blame crashes with internal error

[Björn Steinbrink]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

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

[-- Attachment #2: testcase.sh --]
[-- Type: application/x-sh, Size: 842 bytes --]

Re: git blame crashes with internal error

[Andreas Ericsson]

Björn Steinbrink wrote:
> 
> 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.
> 

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

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git blame crashes with internal error

[David Kastrup]

Andreas Ericsson <ae@op5.se> writes:

> Björn Steinbrink wrote:
>>
>> 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.
>>
>
> Manual bisect? Ugh. This *is* the century of the competent developer
> tools, you know... ;-)

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: git blame crashes with internal error

[Björn Steinbrink]

On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> Björn Steinbrink wrote:
>> 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.
>
> Manual bisect? Ugh. This *is* the century of the competent developer
> tools, you know... ;-)

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

Re: git blame crashes with internal error

[Alex Riesen]

Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:
> 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
> 

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...

Re: git blame crashes with internal error

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Sun, Oct 14, 2007 at 02:56:31PM +0000, David Kastrup wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> > Björn Steinbrink wrote:
> >>
> >> 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.
> >>
> >
> > Manual bisect? Ugh. This *is* the century of the competent developer
> > tools, you know... ;-)
> 
> It's not a "bisect" when it crashes in all versions.

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

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git blame crashes with internal error

[Johannes Schindelin]

Hi,

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

> On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > Bj?rn Steinbrink wrote:
> >> 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.
> >
> > Manual bisect? Ugh. This *is* the century of the competent developer
> > tools, you know... ;-)
> 
> Then, how do I search for a good version with git bisect if I only have
> the one data-point "master is bad"?

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.

>From the commit message:

    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

Re: git blame crashes with internal error

[Alex Riesen]

Alex Riesen, Sun, Oct 14, 2007 18:37:02 +0200:
> Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:
> > 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
> > 
> 
> 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...
> 

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)

Re: git blame crashes with internal error

[Johannes Schindelin]

Hi,

On Sun, 14 Oct 2007, Alex Riesen wrote:

> Bj?rn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:
> > 
> > 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
> 
> 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.

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

Re: git blame crashes with internal error

[Björn Steinbrink]

On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> 
> > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > > Bj?rn Steinbrink wrote:
> > >> 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.
> > >
> > > Manual bisect? Ugh. This *is* the century of the competent developer
> > > tools, you know... ;-)
> > 
> > Then, how do I search for a good version with git bisect if I only have
> > the one data-point "master is bad"?
> 
> 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.
> 
> >From the commit message:
> 
>     This allows you to say:
> 
>         git bisect start
>         git bisect bad $bad
>         git bisect next

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>

> 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.

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

thanks,
Björn

Re: git blame crashes with internal error

[Johannes Schindelin]

Hi,

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

> On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:
> > 
> > On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> > 
> > > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:
> > > > Bj?rn Steinbrink wrote:
> > > >> 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.
> > > >
> > > > Manual bisect? Ugh. This *is* the century of the competent developer
> > > > tools, you know... ;-)
> > > 
> > > Then, how do I search for a good version with git bisect if I only have
> > > the one data-point "master is bad"?
> > 
> > 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.
> > 
> > >From the commit message:
> > 
> >     This allows you to say:
> > 
> >         git bisect start
> >         git bisect bad $bad
> >         git bisect next
> 
> 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.

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

Re: git blame crashes with internal error

[Linus Torvalds]

On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
> 
> git blame just decided to crash on me, when I tried to use it while
> resolving a merge conflict.

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

diff --git a/read-cache.c b/read-cache.c
index 56202d1..3b11aa7 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -149,6 +149,8 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
 		else if (ce_compare_gitlink(ce))
 			changed |= DATA_CHANGED;
 		return changed;
+	case 0:		/* Special case: unmerged file in index */
+		return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
 	default:
 		die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
 	}