Re: [Monotone-devel] monotone merge error

[Stephen Leake]

Stephen Leake <address@hidden> writes:

> Thomas Keller <address@hidden> writes:
>
>> Am 05.05.10 09:13, schrieb Stephen Leake:
>>> Stephen Leake <address@hidden> writes:
>>> 
>>>> Stephen Leake <address@hidden> writes:
>>>>
>>>>> Mando Rodriguez <address@hidden> writes:
>>>>>
>>>>>> When attempting to perform a merge we get this :
>>>>>>
>>>>>> /
>>>>>> mtn: 2 heads on branch '0'
>>>>>> mtn: merge 1 / 1:
>>>>>> mtn: calculating best pair of heads to merge next
>>>>>> mtn: [left]  1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598
>>>>>> mtn: [right] 96c815a1768eb25e49bf74ba3d6e6236adefb30a
>>>>>> mtn: fatal: error: roster.cc:1826:
>>>>>> I(left_uncommon_ancestors.find(left_rid) !=
>>>>>> left_uncommon_ancestors.end())
>>>>>> mtn: this is almost certainly a bug in monotone.
>>>>>
>>>>> I may have time to look at it this weekend.
>>>>
>>>> I finally started looking into this.
>>>>
>>>> The immediate cause of the crash is an invariant failure in
>>>> roster.cc:2066 make_roster_for_merge:
>>>>
>>>>  I(left_uncommon_ancestors.find(left_rid) != 
>>>> left_uncommon_ancestors.end());
>>>>
>>>> I rearranged the MM and I lines there so left_uncommon_ancestors would
>>>> be dumped on --debug, and it is empty.
>>>>
>>>> ...
>>> 
>>> I've made some more progress. The database is inconsistent; the table
>>> "branch_leaves" has incorrect entries. I can't reproduce the error, but
>>> the fix is simple; run database::recalc_branch_leaves.
>>
>> As far as I remember this table is quite new and was added by Tim last
>> November to speed up certain things - maybe it would be a good idea if
>> he could have a look into the issue as well...?
>>
>>> I added 'mtn db recalc_branch_heads' (not committed), and after running
>>> it, 'mtn heads' correctly shows just one head.
>>> 
>>> We could add a check for this to 'mtn db check'; it could compute the
>>> branch leaves and compare to the current values in the branch_leaves table.
>>> 
>>> If no one objects, I'll check in the 'db recalc_branch_heads' command,
>>> and work on a new check in 'db check'.
>>
>> The check is definitely a good idea - 
>
> Ok.
>
>> if we want a separate recalc_branch_heads command is questionable -
>> for two reasons:
>>
>> 1) I fear we fix something whose original cause we still haven't
>> understood - as you correctly stated in one of your previous mails
>> "Before we discuss committing that change, we need to understand why mtn
>> thinks this graph has two heads, and how it got that way."
>
> Ok. But we need some workaround to fix the problem until we do find the
> real cause.
>
>> 2) If we cannot track the problem down and find any other way than
>> regenerating the branch leave cache to fix the problem, then I'd propose
>> we call recalc_branch_leaves as part of the `db regenerate_caches`
>> command (if it doesn't take so long to additionally recalculate them).
>
> That makes sense; "branch_leaves" is a cache, and if one cache is
> broken, it's likely others are. It took a noticable but not significant
> time to run 'recalc_branch_heads', but there's no reason not to include
> it in regenerate_caches.

I encountered this bug at work again this week. I have more clues about
what causes it, and I'll work on a reproducer.

In the meantime, I've implemented a check in 'db check', and a fix in
'db regenerate_caches'.

-- 
-- Stephe