[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] CRASH: invariant violation
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] CRASH: invariant violation |
Date: |
Sun, 24 Jul 2005 06:38:34 -0700 |
User-agent: |
Mutt/1.5.9i |
On Fri, Jul 22, 2005 at 01:14:15AM +0200, Michael Lauer wrote:
> Hi friendly monotone developers,
>
> I was doing a merge when I got a crash with an "invariant violation".
>
> You should be able to reproduce it with the database I put up @
> http://www.vanille.de/temp/monotone-crash.db
>
> I ran the merge again to get you the full output with -debug @
> http://www.vanille.de/temp/monotone-crash.log
>
> monotone --full-version is up @
> http://www.vanille.de/temp/monotone-crash.version
>
> I hope this bug report is useful to you.
> Any idea what to do to "repair" the database or let the merge complete?
This appears to be an example of "Richard's bug" described in [1],
where the merge algorithm loses track of file identity and generates
invalid changesets. There are a bunch of complicated file
rearrangements being merged, and a huge long interconnected ancestry
that really triggers the pathological behavior in LCA+DOM, which
causes it to use an ancient common ancestor; it's about the ideal case
to trigger this kind of problem.
Using a nearer ancestor may help. For instance, if I do
$ monotone explicit_merge 8f9ea859fc4bba48f6e30c3109216cb34cb4b904 \
dd976b55d26325d6987d02c791bc9c6f3472ae66 \
eea3d1cfa60979c91e14fa30d7c9644d58fba40b org.openembedded.dev
then it merges cleanly and without error.
-- Nathaniel
--
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."