fatal: internal error in diff-resolve-rename-copy

fatal: internal error in diff-resolve-rename-copy

[Michael J Gruber]

Hi there,

can someone help me with understanding or debugging the following? With
"log -p --stat" I get that strange fatal error. (With GIT_FLUSH=0 it
appears upfront.)

Without "-p --stat" the log is displayed without a fatal error (same 3
commits), but with "-p" or "--stat" (or both) it's fatal.

I suspect the error is out right before the problematic commit, which is
shown with an empty diffstat.

I did this from a subdir, but the same happens from the root of the
worktree.

git show on the last commit "7896762" shows the creation of a binary
blob "Formular_Lehrverpflichtung_SS09.odt", and "show --stat" gives the
expected stat. What problem could log -p --stat have?

Michael

GIT_FLUSH=1 git log -p  --stat --follow   Formular\ Lehrverpflichtung\
SS\ 2009_FakIII.odt
commit b7a1918f2712fdd8f0de3fa08510ef5f2b9e4428
Author: Michael J Gruber <gruber@m>
Date:   Thu Feb 18 16:40:37 2010 +0100

    clean up
---
 .../Formular Lehrverpflichtung SS 2009_FakIII.odt  |  Bin 13951 ->
13951 bytes
 1 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/Formular Lehrverpflichtung SS 2009_FakIII.odt
b/LVVO/Formular Lehrverpflichtung SS 2009_FakIII.odt
similarity index 100%
rename from Formular Lehrverpflichtung SS 2009_FakIII.odt
rename to LVVO/Formular Lehrverpflichtung SS 2009_FakIII.odt

commit 223e14515f1d2f50d0985e8b2d100e47e0bdde81
Author: Michael J Gruber <gruber@m>
Date:   Wed Jul 8 16:39:10 2009 +0200

    make LVVO names uniform
---
 ...> Formular Lehrverpflichtung SS 2009_FakIII.odt |  Bin 13951 ->
13951 bytes
 1 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/Formular_Lehrverpflichtung_SS09.odt b/Formular
Lehrverpflichtung SS 2009_FakIII.odt
similarity index 100%
rename from Formular_Lehrverpflichtung_SS09.odt
rename to Formular Lehrverpflichtung SS 2009_FakIII.odt
fatal: internal error in diff-resolve-rename-copy

commit 78967623b839ec174e2ed3cb4bf30e27b4d38481
Author: Michael J Gruber <gruber@m>
Date:   Wed Jul 8 16:37:29 2009 +0200

    Lehrverpflichtung SS09
---

Re: fatal: internal error in diff-resolve-rename-copy

[Alex Riesen]

On Mon, Jul 5, 2010 at 14:05, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> can someone help me with understanding or debugging the following? With
> "log -p --stat" I get that strange fatal error. (With GIT_FLUSH=0 it
> appears upfront.)
>
> Without "-p --stat" the log is displayed without a fatal error (same 3
> commits), but with "-p" or "--stat" (or both) it's fatal.

Could you run the case under valgrind? (I suspect a corruption of diff
data structures)

Re: fatal: internal error in diff-resolve-rename-copy

[Michael J Gruber]

Alex Riesen venit, vidit, dixit 05.07.2010 20:20:
> On Mon, Jul 5, 2010 at 14:05, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> can someone help me with understanding or debugging the following? With
>> "log -p --stat" I get that strange fatal error. (With GIT_FLUSH=0 it
>> appears upfront.)
>>
>> Without "-p --stat" the log is displayed without a fatal error (same 3
>> commits), but with "-p" or "--stat" (or both) it's fatal.
> 
> Could you run the case under valgrind? (I suspect a corruption of diff
> data structures)

I have zero experience with valgrind. Running the reported command with
the same suppressions as the test suite does, but with full leak check,
I get the following report on stderr. Do you see anything suspicious in
there? Should I run valgrind with -v?

Michael

==3379== Memcheck, a memory error detector
==3379== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3379== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==3379== Command: git log --stat --follow LVVO/Formular\
Lehrverpflichtung\ SS\ 2009_FakIII.odt
==3379==
fatal: internal error in diff-resolve-rename-copy
==3379==
==3379== HEAP SUMMARY:
==3379==     in use at exit: 1,611,768 bytes in 148 blocks
==3379==   total heap usage: 12,842 allocs, 12,694 frees, 29,235,398
bytes allocated
==3379==
==3379== 4 bytes in 1 blocks are definitely lost in loss record 4 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x311087FE01: strdup (in /lib64/libc-2.12.so)
==3379==    by 0x4C3838: xstrdup (wrapper.c:22)
==3379==    by 0x46BBE0: git_config_string (config.c:406)
==3379==    by 0x46D082: git_config_from_file (config.c:185)
==3379==    by 0x46D4D5: git_config (config.c:802)
==3379==    by 0x491DAF: git_pager (pager.c:61)
==3379==    by 0x491DF4: setup_pager (pager.c:76)
==3379==    by 0x4041B8: handle_internal_command (git.c:262)
==3379==    by 0x4043C1: main (git.c:467)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:strdup
   fun:xstrdup
   fun:git_config_string
   fun:git_config_from_file
   fun:git_config
   fun:git_pager
   fun:setup_pager
   fun:handle_internal_command
   fun:main
}
==3379== 16 bytes in 1 blocks are possibly lost in loss record 13 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4C36E5: xmalloc (wrapper.c:34)
==3379==    by 0x46A6CD: commit_list_insert (commit.c:320)
==3379==    by 0x46B031: parse_commit_buffer (commit.c:272)
==3379==    by 0x46B22F: parse_commit (commit.c:309)
==3379==    by 0x4A9A2A: add_parents_to_list (revision.c:517)
==3379==    by 0x4A9E40: get_revision_1 (revision.c:2016)
==3379==    by 0x4A9EEA: get_revision_internal (revision.c:2121)
==3379==    by 0x4AA150: get_revision (revision.c:2202)
==3379==    by 0x4315DD: cmd_log_walk (log.c:264)
==3379==    by 0x43172B: cmd_log (log.c:515)
==3379==    by 0x4041E0: handle_internal_command (git.c:269)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:xmalloc
   fun:commit_list_insert
   fun:parse_commit_buffer
   fun:parse_commit
   fun:add_parents_to_list
   fun:get_revision_1
   fun:get_revision_internal
   fun:get_revision
   fun:cmd_log_walk
   fun:cmd_log
   fun:handle_internal_command
}
==3379== 27 bytes in 1 blocks are definitely lost in loss record 25 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4A051D7: realloc (vg_replace_malloc.c:476)
==3379==    by 0x4C364D: xrealloc (wrapper.c:80)
==3379==    by 0x4B53C7: strbuf_grow (strbuf.c:70)
==3379==    by 0x4B5733: strbuf_add (strbuf.c:183)
==3379==    by 0x49406F: expand_user_path (path.c:328)
==3379==    by 0x46C0C0: git_config_pathname (config.c:414)
==3379==    by 0x46D082: git_config_from_file (config.c:185)
==3379==    by 0x46D4D5: git_config (config.c:802)
==3379==    by 0x491DAF: git_pager (pager.c:61)
==3379==    by 0x491DF4: setup_pager (pager.c:76)
==3379==    by 0x4041B8: handle_internal_command (git.c:262)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:realloc
   fun:xrealloc
   fun:strbuf_grow
   fun:strbuf_add
   fun:expand_user_path
   fun:git_config_pathname
   fun:git_config_from_file
   fun:git_config
   fun:git_pager
   fun:setup_pager
   fun:handle_internal_command
}
==3379== 46 bytes in 1 blocks are definitely lost in loss record 33 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x311087FE01: strdup (in /lib64/libc-2.12.so)
==3379==    by 0x4C3838: xstrdup (wrapper.c:22)
==3379==    by 0x4BD99F: diff_tree_sha1 (tree-diff.c:377)
==3379==    by 0x4897EA: log_tree_commit (log-tree.c:542)
==3379==    by 0x4315BA: cmd_log_walk (log.c:265)
==3379==    by 0x43172B: cmd_log (log.c:515)
==3379==    by 0x4041E0: handle_internal_command (git.c:269)
==3379==    by 0x4043C1: main (git.c:467)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:strdup
   fun:xstrdup
   fun:diff_tree_sha1
   fun:log_tree_commit
   fun:cmd_log_walk
   fun:cmd_log
   fun:handle_internal_command
   fun:main
}
==3379== 51 bytes in 1 blocks are definitely lost in loss record 37 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4C36E5: xmalloc (wrapper.c:34)
==3379==    by 0x4AD45F: prefix_path (setup.c:10)
==3379==    by 0x4AD5EA: get_pathspec (setup.c:147)
==3379==    by 0x4A8BD0: setup_revisions (revision.c:1594)
==3379==    by 0x431113: cmd_log_init (log.c:78)
==3379==    by 0x431723: cmd_log (log.c:514)
==3379==    by 0x4041E0: handle_internal_command (git.c:269)
==3379==    by 0x4043C1: main (git.c:467)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:xmalloc
   fun:prefix_path
   fun:get_pathspec
   fun:setup_revisions
   fun:cmd_log_init
   fun:cmd_log
   fun:handle_internal_command
   fun:main
}
==3379== 65 bytes in 1 blocks are definitely lost in loss record 40 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4A051D7: realloc (vg_replace_malloc.c:476)
==3379==    by 0x4C364D: xrealloc (wrapper.c:80)
==3379==    by 0x4B53C7: strbuf_grow (strbuf.c:70)
==3379==    by 0x4B5B5A: strbuf_addf (strbuf.c:201)
==3379==    by 0x4816DF: system_path (exec_cmd.c:37)
==3379==    by 0x481801: setup_path (exec_cmd.c:104)
==3379==    by 0x4043B0: main (git.c:533)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:realloc
   fun:xrealloc
   fun:strbuf_grow
   fun:strbuf_addf
   fun:system_path
   fun:setup_path
   fun:main
}
==3379== 192 bytes in 1 blocks are definitely lost in loss record 56 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4A051D7: realloc (vg_replace_malloc.c:476)
==3379==    by 0x4C364D: xrealloc (wrapper.c:80)
==3379==    by 0x476812: diff_q (diff.c:3297)
==3379==    by 0x476869: diff_queue (diff.c:3311)
==3379==    by 0x477125: diff_addremove (diff.c:4150)
==3379==    by 0x4BD082: show_entry (tree-diff.c:255)
==3379==    by 0x4BD168: show_entry (tree-diff.c:217)
==3379==    by 0x4BD4A5: diff_tree (tree-diff.c:299)
==3379==    by 0x4BD79A: diff_tree_sha1 (tree-diff.c:414)
==3379==    by 0x4897EA: log_tree_commit (log-tree.c:542)
==3379==    by 0x4315BA: cmd_log_walk (log.c:265)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:realloc
   fun:xrealloc
   fun:diff_q
   fun:diff_queue
   fun:diff_addremove
   fun:show_entry
   fun:show_entry
   fun:diff_tree
   fun:diff_tree_sha1
   fun:log_tree_commit
   fun:cmd_log_walk
}
==3379== 384 bytes in 2 blocks are definitely lost in loss record 58 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4A051D7: realloc (vg_replace_malloc.c:476)
==3379==    by 0x4C364D: xrealloc (wrapper.c:80)
==3379==    by 0x476812: diff_q (diff.c:3297)
==3379==    by 0x476869: diff_queue (diff.c:3311)
==3379==    by 0x477125: diff_addremove (diff.c:4150)
==3379==    by 0x4BD082: show_entry (tree-diff.c:255)
==3379==    by 0x4BD4A5: diff_tree (tree-diff.c:299)
==3379==    by 0x4BD79A: diff_tree_sha1 (tree-diff.c:414)
==3379==    by 0x4897EA: log_tree_commit (log-tree.c:542)
==3379==    by 0x4315BA: cmd_log_walk (log.c:265)
==3379==    by 0x43172B: cmd_log (log.c:515)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:realloc
   fun:xrealloc
   fun:diff_q
   fun:diff_queue
   fun:diff_addremove
   fun:show_entry
   fun:diff_tree
   fun:diff_tree_sha1
   fun:log_tree_commit
   fun:cmd_log_walk
   fun:cmd_log
}
==3379== 545 bytes in 2 blocks are possibly lost in loss record 60 of 76
==3379==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3379==    by 0x4C36E5: xmalloc (wrapper.c:34)
==3379==    by 0x4C377E: xmallocz (wrapper.c:56)
==3379==    by 0x4AE627: unpack_sha1_file (sha1_file.c:1170)
==3379==    by 0x4B2200: read_object (sha1_file.c:2074)
==3379==    by 0x4B226E: read_sha1_file_repl (sha1_file.c:2088)
==3379==    by 0x46B1E7: parse_commit (cache.h:721)
==3379==    by 0x4A9A2A: add_parents_to_list (revision.c:517)
==3379==    by 0x4A9E40: get_revision_1 (revision.c:2016)
==3379==    by 0x4A9EEA: get_revision_internal (revision.c:2121)
==3379==    by 0x4AA150: get_revision (revision.c:2202)
==3379==    by 0x4315DD: cmd_log_walk (log.c:264)
==3379==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:xmalloc
   fun:xmallocz
   fun:unpack_sha1_file
   fun:read_object
   fun:read_sha1_file_repl
   fun:parse_commit
   fun:add_parents_to_list
   fun:get_revision_1
   fun:get_revision_internal
   fun:get_revision
   fun:cmd_log_walk
}
==3379== LEAK SUMMARY:
==3379==    definitely lost: 769 bytes in 8 blocks
==3379==    indirectly lost: 0 bytes in 0 blocks
==3379==      possibly lost: 561 bytes in 3 blocks
==3379==    still reachable: 1,610,438 bytes in 137 blocks
==3379==         suppressed: 0 bytes in 0 blocks
==3379== Reachable blocks (those to which a pointer was found) are not
shown.
==3379== To see them, rerun with: --leak-check=full --show-reachable=yes
==3379==
==3379== For counts of detected and suppressed errors, rerun with: -v
==3379== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 6 from 6)

Re: fatal: internal error in diff-resolve-rename-copy

[Alex Riesen]

On Tue, Jul 6, 2010 at 16:47, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Alex Riesen venit, vidit, dixit 05.07.2010 20:20:
>> On Mon, Jul 5, 2010 at 14:05, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>>> can someone help me with understanding or debugging the following? With
>>> "log -p --stat" I get that strange fatal error. (With GIT_FLUSH=0 it
>>> appears upfront.)
>>>
>>> Without "-p --stat" the log is displayed without a fatal error (same 3
>>> commits), but with "-p" or "--stat" (or both) it's fatal.
>>
>> Could you run the case under valgrind? (I suspect a corruption of diff
>> data structures)
>
> I have zero experience with valgrind. Running the reported command with
> the same suppressions as the test suite does, but with full leak check,
> I get the following report on stderr. Do you see anything suspicious in
> there? Should I run valgrind with -v?

No, I afraid it wont help. Memory access errors are always reported and these
("use of uninitialized value", in particular) were what I hoped to see here.

In this case something left the diff_filepair unset after allocation (hence the
"internal error". Should have been "Oops, we have a bug"): value 0 (as
seen in the check_pair_status, where the message comes from) is just
what the structure gets initialized by allocation.

Unless the repository is private (otherwise I'd like to take a look at it),
I'd suggest to put a breakpoint at the message point and try to figure
out how come the diff_filepair->status was left unset or why the diff
code is interested in its value (maybe it shouldn't be, in this case).