From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:04
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(-)
From: Alex Riesen <hidden> Date: 2016-06-15 22:49:05
On Mon, Jul 5, 2010 at 14:05, Michael J Gruber [off-list ref] 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)
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:05
Alex Riesen venit, vidit, dixit 05.07.2010 20:20:
On Mon, Jul 5, 2010 at 14:05, Michael J Gruber [off-list ref] wrote:
quoted
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)
From: Alex Riesen <hidden> Date: 2016-06-15 22:49:05
On Tue, Jul 6, 2010 at 16:47, Michael J Gruber [off-list ref] wrote:
Alex Riesen venit, vidit, dixit 05.07.2010 20:20:
quoted
On Mon, Jul 5, 2010 at 14:05, Michael J Gruber [off-list ref] wrote:
quoted
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).