monotone-devel
[Top][All Lists]
Advanced

[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: Mon, 03 May 2010 21:14:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

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.

Looking at 'mtn log --brief --last n', for each head, and then
simplifying and labeling nodes gives:

left:
c     1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598
|\
| u     266a4f486fd3503424e1e558332bec51bc17f712
| |\    
| | r     ec7da22edc629b04ce7b0cd3862fb50236e19f31
| |     
b |       172bd0acc03f891dde296528024f72531ac84c1a
|/      
a       06295712fb59e06d01239f05890ad0a490312069


right:
o   96c815a1768eb25e49bf74ba3d6e6236adefb30a
|
o   4c266f17df2cdba283bf9bf0770825f906aed897
|
o   e82de3ec38d0321c7be3b130ba8280bf7541e602
|
o   5d6506cf34c5dbdec9d9731c43f6b78f67157679
|
o   4e14186a0d7d8d0efd27f51a55fcc4ebd1600f9a
|
o   d7d1ab44d04d8b53273fcb9df7832850da5209f4
|
o   77489ecf84f97cc6662eb7576a7ed82a3100045e
|
o   372fe376a270b343cd692c66dd92296dd4da6741
|
o   3a18a688e356f9c6eb9e832eb1718be2c41e3ac8
|
o   ef341768bf7d402e3e2116c97ebcc20800003e3c
|
e   a469ce6603ecce7e7a104c43ebc98059229d0c02
|
d     d2265b955663e96d240d1fad6ec169b94a50fe01
|\
c |     1d8d9ecda9ed7bd5b34dfbb48d4ce0d61e071598
|\ \
| u |     266a4f486fd3503424e1e558332bec51bc17f712
| |\ \
| | | t   9a88375010db0c057604cc2c7eff177b1ffe669b 
| | | |
| .---s   545eb2667e5af895058bf19fefac06ba816a186b 
|/| |/
| | r     ec7da22edc629b04ce7b0cd3862fb50236e19f31 
| |
b |       172bd0acc03f891dde296528024f72531ac84c1a 
|/
a       06295712fb59e06d01239f05890ad0a490312069   


As you can see, 'c' is the left head, but is also an ancestor of the
right head. I don't understand why mtn thinks there are two heads here.
I have not attempted to trace the logic of 'mtn heads' to find out yet.

I did trace the execution of graph.cc: get_uncommon_ancestors, and it
looks correct; it produces no left_uncommon_ancestors (since there are
in fact none in this graph).

In any case, simply removing the invariant in roster.cc works; it
introduces no failures in the test suite (there are 13 failures on head,
but no new ones for this change).

Before we discuss committing that change, we need to understand why mtn
thinks this graph has two heads, and how it got that way.

I'll look at 'mtn heads' tomorrow.

-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]