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: Mando
Subject: Re: [Monotone-devel] monotone merge error
Date: Mon, 03 May 2010 21:16:28 -0500
User-agent: Thunderbird 2.0.0.24 (Macintosh/20100228)

Stephen Leake wrote:
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.

Thank you Stephen. If there's anything I can do from my end at this point just let me know.

-Mando




reply via email to

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