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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jul 7, 2010, 08:13 UTC
Message-ID: <AANLkTimoNMYgP8-Wv0xZG0Ge7LpDZHblKSop8bozdfjY@mail.gmail.com>
In-Reply-To: <4C3341EA.7070901@drmicha.warpmail.net>

On Tue, Jul 6, 2010 at 16:47, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 16 quoted lines

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