Re: [Gnu-arch-users] Serious problem here

[Ulf Ochsenfahrt]

> Ulf Ochsenfahrt wrote:
> > Hi!
> > 
> 
> ...
> 
> > # tla get address@hidden/cqs--mainline--0.2 cqs3
> > Password:
> > * ensuring library has
> address@hidden/cqs--mainline--0.2--patch-140
> > * searching ancestor revision in library in archive address@hidden
> > * found ancestor revision in library
> (address@hidden/cqs--mainline--0.2--patch-138)
> > * patching for this revision
> (address@hidden/cqs--mainline--0.2--patch-140)
> > * patching for revision
> address@hidden/cqs--mainline--0.2--patch-139
> >
>
/home/asuffield/arch/dists/tla/tla-1.3/src/tla/libarch/library-txn.c:492:botched
invariant
> >     !replay_status
> > PANIC: exiting on botched invariant
> > 
> 
> This invariant looks like as it was trying to create a local copy in the 
> revision library, there was an error, so it exited.
>
> It sounds like something happened such that your patch-139 is corrupt. 
> When you went to get patch-140, you had 138, so it had to go *through* 
> 139 to get there. Since 139 is broken, it can't make it to 140.

The really weired thing is, after I deleted my gfs revlib (only the cqs
thing), I could check out the latest revision again. Mind you, since I use a
revlib, I'm not doing cacherevs anymore, so it had to go through 139.
 
> > I deleted the last couple of revisions from both revlibs, but I still
> > can't check out that revision on my gf's pc anymore. 
> 
> Even deleting the last few, still means when doing a checkout you have 
> to apply patch-139.
> 
> Try this:
> 
> tla get address@hidden/cqs--mainline--0.2--patch-138 cqs-test
> tla get-changset address@hidden/cqs--mainline--0.2--patch-139 p-139
> cd cqs-test
> tla apply-changeset ../p-139
> 
> If that fails, then probably patch-139 is truly corrupt.

It doesn't seem like patch-139 is corrupt. Also, on the other machine, I
could still check out patch-140. No cacherev.

> ...
>  > I can check out on
> > my own. Now it gets even worse. I tried to do a star-merge into my
> > _public_ repository. And it did. It applied lots of patches _again_,
> > although most of them have already been merged in. Lots of conflicts -
> > of course (line-breaks inserted by me):
> > 
> > * star-merge by
> delta(address@hidden/cqs--mainline--
> > 0.2--patch-47,address@hidden/cqs--mainline--0.2--patch-140)[/home/
> > ulfjack/arch/REMOTE-PUBLIC/cqs]
> > 
> > tla logs -f address@hidden/cqs--mainline--0.2 says that it has
> > patch-logs up to and including 133.
> But you should have up to 140, correct?

I wanted to get 134-140 - the last time I star-merged I got up to and
including 133, but when I now did star-merge, it got me 47 up to something.

> > 
> > Any idea what went wrong? Could be several mistakes. Could have been my
> > fault (at least partially). Any idea how I could fix my repository?
> > 
> > Update: I deleted my gfs revlib and did a full checkout. Now star-merge
> > works again. Error in the revlib handling code? I still can't star-merge
> > into my public repository.
> 
> If you had a cachrev, then when she does a full checkout, she will never 
> try to get the broken patch-139.
> I don't know what would have gone wrong with the revision library.
> 
> Are you doing something like keeping your revlib in /tmp? I've seen 
> machines where /tmp is cleaned, such that files that aren't accessed for 
> a month are deleted. This could cause revision library corruption, which 
> should be detected, but I suppose may not be.

Nope. Its in /home/ulfjack/repository/library/ and the repository is in
/home/ulfjack/repository/2005/ (the old one is in .../2004/).

> > 
> > Update 2: I was able to manually merge my private changes into my
> > public repository. I could then do a sync-tree and now everything seems
> > to work again.
> > 
> > -- Ulf
> 
> I can't tell you much more without having seen the problem. And as it 
> happened in a private repository, probably it isn't out there to look 
> at. (I don't really have the time right now, either.)
> But hopefully I've given a couple of pointers of things to look for.

I cannot give you read access to my private repo, as that is on my home pc
(dialup and a firewall). The project I'm talking about is open source, so I
could give you a copy of that project (if that would help).

It seems like there are two problems here: My gfs inability to checkout 140
(which works now) and my inability to star-merge into my public repo.

I got the first one to work again and I think I've deleted too much evidence
to provide any more clues as to what went wrong. Now the second... If
anyones serious about finding out more, I _could_ get you an ssh connection
into my machine. Slow, but it should work. I still have the old tree
available where star-merge failed.

> John
> =:->

Cheers,

-- Ulf




> Yow.
> 
> Do you get this same botched invariant if you try with the version of
> tla you were using before?  Which version were you using when this was
> committed?

1.3-1, Debian unstable. Unfortunately, I don't have the old version anymore
- and I am not sure I could get it - Debian unstable packages get deleted
pretty quickly - it was a 1.2 tla though.

See http://packages.debian.org/unstable/devel/tla
(Only current until Andrew Suffield uploads a new package.)

Cheers,

-- Ulf

-- 
GMX im TV ... Die Gedanken sind frei ... Schon gesehen?
Jetzt Spot online ansehen: http://www.gmx.net/de/go/tv-spot