{"thread":{"id":"10282","subject":"git blame crashes with internal error","startedAt":"2007-10-14T14:36:28Z","lastAt":"2007-10-15T15:39:23Z","messageCount":12,"participants":["Björn Steinbrink","Andreas Ericsson","David Kastrup","Alex Riesen","Pierre Habouzit","Johannes Schindelin","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55720","messageId":"20071014143628.GA22568@atjola.homenet","threadId":"10282","inReplyTo":null,"subject":"git blame crashes with internal error","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-14T14:36:28Z","receivedAt":"2007-10-14T14:36:28Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"Hi Junio,\n\ngit blame just decided to crash on me, when I tried to use it while\nresolving a merge conflict. Interesting is probably, that it crashes\nwhen given the filename of a file that is not _directly_ affected by the\nmerge, but contains code that originates from a file that caused\nconlicts.\n\nError message is:\nfatal: internal error: ce_mode is 0\n\nI tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\nmaster and all of them crashed. A small shell script to reproduce the\nproblem is attached.\n\nThanks,\nBjörn\n"},{"id":"55721","messageId":"47122D02.9060204@op5.se","threadId":"10282","inReplyTo":"20071014143628.GA22568@atjola.homenet","subject":"Re: git blame crashes with internal error","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T14:51:46Z","receivedAt":"2007-10-14T14:51:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Björn Steinbrink wrote:\n> \n> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n> master and all of them crashed. A small shell script to reproduce the\n> problem is attached.\n> \n\nManual bisect? Ugh. This *is* the century of the competent developer\ntools, you know... ;-)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"55722","messageId":"85hcktn3s0.fsf@lola.goethe.zz","threadId":"10282","inReplyTo":"47122D02.9060204@op5.se","subject":"Re: git blame crashes with internal error","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-14T14:56:31Z","receivedAt":"2007-10-14T14:56:31Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Björn Steinbrink wrote:\n>>\n>> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n>> master and all of them crashed. A small shell script to reproduce the\n>> problem is attached.\n>>\n>\n> Manual bisect? Ugh. This *is* the century of the competent developer\n> tools, you know... ;-)\n\nIt's not a \"bisect\" when it crashes in all versions.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55726","messageId":"20071014152327.GA24003@atjola.homenet","threadId":"10282","inReplyTo":"47122D02.9060204@op5.se","subject":"Re: git blame crashes with internal error","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-14T15:23:27Z","receivedAt":"2007-10-14T15:23:27Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:\n> Björn Steinbrink wrote:\n>> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n>> master and all of them crashed. A small shell script to reproduce the\n>> problem is attached.\n>\n> Manual bisect? Ugh. This *is* the century of the competent developer\n> tools, you know... ;-)\n\nThen, how do I search for a good version with git bisect if I only have\nthe one data-point \"master is bad\"?\n\nAll I tried when testing those 5 versions was trying to find a good\nversion so that I can actually do an automatic bisect. And I stopped at\n1.5.3 because I figured that my test-case is probably just pretty\nuncommon and was basically always broken.\n\nAnother manual \"bisect\" shows that 1.5.0 also crashes and as 1.4.0\ndoesn't even want to read my git git repository, I don't intend to go\neven further backwards in the history to find a good commit, unless\nsomeone tells me that it is a really good idea or how to automate\nfinding a good commit in a sane way.\n\nBjörn\n"},{"id":"55735","messageId":"20071014163702.GA2776@steel.home","threadId":"10282","inReplyTo":"20071014143628.GA22568@atjola.homenet","subject":"Re: git blame crashes with internal error","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-14T16:37:02Z","receivedAt":"2007-10-14T16:37:02Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:\n> Hi Junio,\n> \n> git blame just decided to crash on me, when I tried to use it while\n> resolving a merge conflict. Interesting is probably, that it crashes\n> when given the filename of a file that is not _directly_ affected by the\n> merge, but contains code that originates from a file that caused\n> conlicts.\n> \n> Error message is:\n> fatal: internal error: ce_mode is 0\n> \n\nIt is not crashing. It is just not handling unexpected situation\nproperly:\n\n    $ testcase.sh\n    ...\n    Switched to branch \"foo\"\n    CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.\n    Automatic merge failed; fix conflicts and then commit the result.\n    fatal: internal error: ce_mode is 0\n    $ git ls-files --cached --stage\n    100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1       file1\n    100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3       file1\n    100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0       file2\n\nSee? There is an unresolved merge.\n\nThe question is, what's the problem...\n"},{"id":"55737","messageId":"20071014165036.GJ1198@artemis.corp","threadId":"10282","inReplyTo":"85hcktn3s0.fsf@lola.goethe.zz","subject":"Re: git blame crashes with internal error","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-14T16:50:36Z","receivedAt":"2007-10-14T16:50:36Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Oct 14, 2007 at 02:56:31PM +0000, David Kastrup wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n> > Björn Steinbrink wrote:\n> >>\n> >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n> >> master and all of them crashed. A small shell script to reproduce the\n> >> problem is attached.\n> >>\n> >\n> > Manual bisect? Ugh. This *is* the century of the competent developer\n> > tools, you know... ;-)\n> \n> It's not a \"bisect\" when it crashes in all versions.\n\n  What What, git cannot bisect future versions ??? *g* what a\ndisappointment.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"55748","messageId":"Pine.LNX.4.64.0710141830050.25221@racer.site","threadId":"10282","inReplyTo":"20071014152327.GA24003@atjola.homenet","subject":"Re: git blame crashes with internal error","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T17:32:44Z","receivedAt":"2007-10-14T17:32:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:\n\n> On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:\n> > Bj?rn Steinbrink wrote:\n> >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n> >> master and all of them crashed. A small shell script to reproduce the\n> >> problem is attached.\n> >\n> > Manual bisect? Ugh. This *is* the century of the competent developer\n> > tools, you know... ;-)\n> \n> Then, how do I search for a good version with git bisect if I only have\n> the one data-point \"master is bad\"?\n\nAFAIK Junio introduced the option to start with just a bad commit, and no \nknown \"good\" one.\n\nYep, just found it.  Since v1.5.2-rc0~77^2(git-bisect: allow bisecting \nwith only one bad commit.) it is supported.\n\n>From the commit message:\n\n    This allows you to say:\n\n        git bisect start\n        git bisect bad $bad\n        git bisect next\n\nI don't know if it is in the documentation (I rarely read it), so if it is \nmissing, it would be nice if you could add the description there.\n\nCiao,\nDscho\n"},{"id":"55749","messageId":"20071014173355.GB2776@steel.home","threadId":"10282","inReplyTo":"20071014163702.GA2776@steel.home","subject":"Re: git blame crashes with internal error","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-14T17:33:55Z","receivedAt":"2007-10-14T17:33:55Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Alex Riesen, Sun, Oct 14, 2007 18:37:02 +0200:\n> Björn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:\n> > Hi Junio,\n> > \n> > git blame just decided to crash on me, when I tried to use it while\n> > resolving a merge conflict. Interesting is probably, that it crashes\n> > when given the filename of a file that is not _directly_ affected by the\n> > merge, but contains code that originates from a file that caused\n> > conlicts.\n> > \n> > Error message is:\n> > fatal: internal error: ce_mode is 0\n> > \n> \n> It is not crashing. It is just not handling unexpected situation\n> properly:\n> \n>     $ testcase.sh\n>     ...\n>     Switched to branch \"foo\"\n>     CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.\n>     Automatic merge failed; fix conflicts and then commit the result.\n>     fatal: internal error: ce_mode is 0\n>     $ git ls-files --cached --stage\n>     100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1       file1\n>     100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3       file1\n>     100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0       file2\n> \n> See? There is an unresolved merge.\n> \n> The question is, what's the problem...\n> \n\nFWIW, backtrace. I'm giving up for today. Anyone?\n\n(gdb) bt\n#0  0x080b6ac5 in die_builtin (err=0x80f3b92 \"internal error: ce_mode is %o\", \n    params=0xbfd91c34 \"\") at usage.c:24\n#1  0x080b6b84 in die (err=0x80f3b92 \"internal error: ce_mode is %o\")\n    at usage.c:76\n#2  0x080a3883 in ce_match_stat_basic (ce=0xb7f6a00c, st=0xbfd91cb8)\n    at read-cache.c:153\n#3  0x080a398f in ie_match_stat (istate=0x81342e0, ce=0xb7f6a00c, \n    st=0xbfd91cb8, options=0) at read-cache.c:208\n#4  0x080c87f3 in reuse_worktree_file (name=0x814c698 \"file1\", \n    sha1=0x814c668 \"r\\023\\2378\\2256y�\\031��\\223\\214G\\235s�{Y\\230�024\\b\", \n    want_file=0) at diff.c:1499\n#5  0x080c8a6f in diff_populate_filespec (s=0x814c668, size_only=1)\n    at diff.c:1565\n#6  0x080d0ab2 in is_exact_match (src=0x814c668, dst=0x814ca20, contents_too=1)\n    at diffcore-rename.c:108\n#7  0x080d13aa in diffcore_rename (options=0xbfd91edc) at diffcore-rename.c:335\n#8  0x080ccaef in diffcore_std (options=0xbfd91edc) at diff.c:3120\n#9  0x08054c33 in find_rename (sb=0xbfd921e8, parent=0x81377c0, \n    origin=0x814c5e0) at builtin-blame.c:427\n#10 0x080563a3 in pass_blame (sb=0xbfd921e8, origin=0x814c5e0, opt=0)\n    at builtin-blame.c:1216\n#11 0x08056d09 in assign_blame (sb=0xbfd921e8, revs=0xbfd92068, opt=0)\n    at builtin-blame.c:1501\n#12 0x0805942a in cmd_blame (argc=2, argv=0xbfd92404, prefix=0x0)\n    at builtin-blame.c:2414\n#13 0x0804b7d8 in run_command (p=0x80fa8d0, argc=2, argv=0xbfd92404)\n    at git.c:284\n#14 0x0804b97a in handle_internal_command (argc=2, argv=0xbfd92404)\n    at git.c:398\n#15 0x0804ba52 in main (argc=2, argv=0xbfd92404) at git.c:435\n(gdb)\n"},{"id":"55752","messageId":"Pine.LNX.4.64.0710141843480.25221@racer.site","threadId":"10282","inReplyTo":"20071014163702.GA2776@steel.home","subject":"Re: git blame crashes with internal error","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T17:51:07Z","receivedAt":"2007-10-14T17:51:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Alex Riesen wrote:\n\n> Bj?rn Steinbrink, Sun, Oct 14, 2007 16:36:28 +0200:\n> > \n> > git blame just decided to crash on me, when I tried to use it while \n> > resolving a merge conflict. Interesting is probably, that it crashes \n> > when given the filename of a file that is not _directly_ affected by \n> > the merge, but contains code that originates from a file that caused \n> > conlicts.\n> > \n> > Error message is: fatal: internal error: ce_mode is 0\n> \n> It is not crashing. It is just not handling unexpected situation \n> properly:\n> \n>     $ testcase.sh\n>     ...\n>     Switched to branch \"foo\"\n>     CONFLICT (delete/modify): file1 deleted in HEAD and modified in master. Version master of file1 left in tree.\n>     Automatic merge failed; fix conflicts and then commit the result.\n>     fatal: internal error: ce_mode is 0\n>     $ git ls-files --cached --stage\n>     100644 72139f38953679bd19b3a7938c479d73c1aa7b59 1       file1\n>     100644 3181f904ce3f9364b08524edd262a7a2ac766c9c 3       file1\n>     100644 24e1ea80d6dcc497f60597b2a6d7cf65ecaa958a 0       file2\n> \n> See? There is an unresolved merge.\n\nI _think_ that what blame does here is correct.  It wants to handle the \nrename case, and because of the conflicts, it cannot determine the \nrenames.\n\nThe proper thing to do now would be\n\n\tgit blame HEAD file2\n\nsince you want to exclude the working tree from the blaming.\n\nI agree that the error message is not really helping here, though.  Since \nwe are not really libified, I do not see an easy way to help here, either, \nshort of git-blame checking for unmerged entries.\n\nCiao,\nDscho\n"},{"id":"55768","messageId":"20071014201813.GA26872@atjola.homenet","threadId":"10282","inReplyTo":"Pine.LNX.4.64.0710141830050.25221@racer.site","subject":"Re: git blame crashes with internal error","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-14T20:18:13Z","receivedAt":"2007-10-14T20:18:13Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:\n> \n> > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:\n> > > Bj?rn Steinbrink wrote:\n> > >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n> > >> master and all of them crashed. A small shell script to reproduce the\n> > >> problem is attached.\n> > >\n> > > Manual bisect? Ugh. This *is* the century of the competent developer\n> > > tools, you know... ;-)\n> > \n> > Then, how do I search for a good version with git bisect if I only have\n> > the one data-point \"master is bad\"?\n> \n> AFAIK Junio introduced the option to start with just a bad commit, and no \n> known \"good\" one.\n> \n> Yep, just found it.  Since v1.5.2-rc0~77^2(git-bisect: allow bisecting \n> with only one bad commit.) it is supported.\n> \n> >From the commit message:\n> \n>     This allows you to say:\n> \n>         git bisect start\n>         git bisect bad $bad\n>         git bisect next\n\nOK, using that approach, I bisected it, and even found a \"guilty\"\ncommit, although it is pretty much useless:\n\n1cfe77333f274c9ba9879c2eb61057a790eb050f is first bad commit\ncommit 1cfe77333f274c9ba9879c2eb61057a790eb050f\nAuthor: Junio C Hamano <junkio@cox.net>\nDate:   Tue Jan 30 01:11:08 2007 -0800\n\n    git-blame: no rev means start from the working tree file.\n\n    Warning: this changes the semantics.\n\n    This makes \"git blame\" without any positive rev to start digging\n    from the working tree copy, which is made into a fake commit\n    whose sole parent is the HEAD.\n\n    It also adds --contents <file> option to pretend as if the\n    working tree copy has the contents of the named file.  You can\n    use '-' to make the command read from the standard input.\n\n    If you want the command to start annotating from the HEAD\n    commit, you need to explicitly give HEAD parameter.\n\n    Signed-off-by: Junio C Hamano <junkio@cox.net>\n\n> I don't know if it is in the documentation (I rarely read it), so if it is \n> missing, it would be nice if you could add the description there.\n\nNothing in there yet AFAICT. Will try to get a patch done tomorrow.\n\nthanks,\nBjörn\n"},{"id":"55770","messageId":"Pine.LNX.4.64.0710142118590.25221@racer.site","threadId":"10282","inReplyTo":"20071014201813.GA26872@atjola.homenet","subject":"Re: git blame crashes with internal error","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T20:21:00Z","receivedAt":"2007-10-14T20:21:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:\n\n> On 2007.10.14 18:32:44 +0100, Johannes Schindelin wrote:\n> > \n> > On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:\n> > \n> > > On 2007.10.14 16:51:46 +0200, Andreas Ericsson wrote:\n> > > > Bj?rn Steinbrink wrote:\n> > > >> I tried all git releases from 1.5.3 to 1.5.3.4 as well as the current\n> > > >> master and all of them crashed. A small shell script to reproduce the\n> > > >> problem is attached.\n> > > >\n> > > > Manual bisect? Ugh. This *is* the century of the competent developer\n> > > > tools, you know... ;-)\n> > > \n> > > Then, how do I search for a good version with git bisect if I only have\n> > > the one data-point \"master is bad\"?\n> > \n> > AFAIK Junio introduced the option to start with just a bad commit, and no \n> > known \"good\" one.\n> > \n> > Yep, just found it.  Since v1.5.2-rc0~77^2(git-bisect: allow bisecting \n> > with only one bad commit.) it is supported.\n> > \n> > >From the commit message:\n> > \n> >     This allows you to say:\n> > \n> >         git bisect start\n> >         git bisect bad $bad\n> >         git bisect next\n> \n> OK, using that approach, I bisected it, and even found a \"guilty\"\n> commit, although it is pretty much useless:\n> \n> 1cfe77333f274c9ba9879c2eb61057a790eb050f is first bad commit\n> commit 1cfe77333f274c9ba9879c2eb61057a790eb050f\n> Author: Junio C Hamano <junkio@cox.net>\n> Date:   Tue Jan 30 01:11:08 2007 -0800\n> \n>     git-blame: no rev means start from the working tree file.\n\nI think it is not useless.  It says exactly the same as I did, in another \nreply:  git blame starts with your working tree.  As such, it has to do \nsome operations which happen to fail on unmerged files.\n\nSo the solution in your case _really_ is:\n\n\tgit blame HEAD file2\n\nExplanation: with that command line, you ask git blame to start with a \ngiven revision (instead of the working tree), which just so happens to be \nthe HEAD revision.\n\nHth,\nDscho\n"},{"id":"55877","messageId":"alpine.LFD.0.999.0710150831410.6887@woody.linux-foundation.org","threadId":"10282","inReplyTo":"20071014143628.GA22568@atjola.homenet","subject":"Re: git blame crashes with internal error","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-15T15:39:23Z","receivedAt":"2007-10-15T15:39:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:\n> \n> git blame just decided to crash on me, when I tried to use it while\n> resolving a merge conflict.\n\nYes. What's going on is that \"ce_mode = 0\" is a magic marker for an \nunmerged entry (set up by things like diff-lib.c:do_diff_cache() and \nbuiltin-read-tree.c:read_tree_unmerged()) and the ce_match_stat_basic() \nfunction gets upset about this.\n\nI'm not entirely sure that the whole \"ce_mode = 0\" case is a good idea to \nbegin with, and maybe the right thing to do is to remove that horrid \nfreakish special case, but removing the internal error seems to be the \nsimplest fix for now.\n\n\t\tLinus\n\n---\n read-cache.c |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex 56202d1..3b11aa7 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -149,6 +149,8 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)\n \t\telse if (ce_compare_gitlink(ce))\n \t\t\tchanged |= DATA_CHANGED;\n \t\treturn changed;\n+\tcase 0:\t\t/* Special case: unmerged file in index */\n+\t\treturn MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;\n \tdefault:\n \t\tdie(\"internal error: ce_mode is %o\", ntohl(ce->ce_mode));\n \t}\n"}]}