[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] monotone merge error
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] monotone merge error |
Date: |
Wed, 05 May 2010 19:01:22 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt) |
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.
--
-- Stephe