[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Break after kill_rev_locally
From: |
Ludovic Brenta |
Subject: |
Re: [Monotone-devel] Break after kill_rev_locally |
Date: |
Mon, 08 Oct 2007 20:44:46 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
"Ralf S. Engelschall" <address@hidden> writes:
> I today had to use "mtn db kill_rev_locally <rev>" where <rev> was the
> head of a branch. First, everything looked just fine. I freshly checked
> out a new workspace (now based on the previous revision on the branch
> which is now the new head), performed a "mtn log" to be sure that just
> the previous head revision got dropped, etc. Then I edited the sources
> and tried to commit the changes: Bang!
>
> | $ mtn ci -m "adjust key modify commands"
> | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys'
> | terminate called after throwing an instance of 'std::logic_error'
> | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated
> | mtn: fatal signal: Abort trap: 6
> | this is almost certainly a bug in monotone.
> | please send this error message, the output of 'mtn --full-version',
> | and a description of what you were doing to address@hidden
> | do not send a core dump, but if you have one,
> | please preserve it in case we ask you for information from it.
>
> The only way to rescue the situation was to restore the database from
> the last UFS snapshot (luckily no other changes happended in the
> meantime) in order to be able to proceed again.
>
> For me this looks like "mtn db kill_rev_locally <rev>" does not remove
> _all_ related information of <rev> and that some remaining/dangling
> information causes the subsequent commit to break. Hmm...
>
> Unfortunately, I was not able to repeat this with a simple test where I
> created a fresh database, performed three commits and killed the third
> commit.... :-(
I had the same, or a very similar symptom after killing the head of a
branch that happened to be a propagate (A to B) node. I then did "mtn
propagate B A" (which was what I really intended) and got an
exception. The killed revision and the new revision had the same
revision ID.
To correct the problem, I "sync"ed the offending database into a fresh
one and could then proceed with the propagate and commit.
--
Ludovic Brenta.