Stephen Leake <stephen_le...@stephe-leake.org> writes: > Thomas Keller <m...@thomaskeller.biz> writes: > >> Am 05.05.10 09:13, schrieb Stephen Leake: >>> Stephen Leake <stephen_le...@stephe-leake.org> writes: >>> >>>> Stephen Leake <stephen_le...@stephe-leake.org> writes: >>>> >>>>> Mando Rodriguez <mandorodrig...@gmail.com> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel