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

[Alex Riesen <raa.lkml@gmail.com>]

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