"missing referenced chk root" while merging gcc into gcc-linaro

Bug #1021537 reported by Michael Hope on 2012-07-06
16
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned

Bug Description

I get the attached crash when merging the GCC 4.7 release branch into the Linaro GCC release branch. This causes significant pain each month as we need to do a manual, error prone diff/patch instead.

To reproduce:
 * mkdir gcc; cd gcc
 * bzr init-repo .
 * bzr branch lp:gcc-linaro/4.7
 * bzr branch --standalone lp:gcc/4.7 gcc-4.7
 * bzr branch --hardlink 4.7 merge-from-fsf
 * cd merge-from-fsf
 * bzr merge ../gcc-4.7

bzr also fails with the shared repo unless you add the --standalone.

This process works fine on 4.6 and 4.5.

Related branches

Michael Hope (michaelh1) wrote :
Michael Hope (michaelh1) wrote :

jelmer talked with ams about this on IRC: http://irclogs.ubuntu.com/2012/03/14/%23bzr.txt

Joey Stanford (joey) on 2012-07-06
tags: added: bzr linaro
Joey Stanford (joey) wrote :

<jelmer> there is invalid data in one of the two branches caused by an old bzr-svn bug

<jelmer> joey: if you don't care about the actual history of gcc-linaro, then the simplest thing to do would be to take the last revision from lp:gcc that was merged into lp:gcc-linaro, "rsync --delete -avz" over the existing contents from lp:gcc-linaro and commit it in a single commit

<joey> hmm I'd have to talk to michael hope about that. It may be possible for us to start a new series as part of normal ops and then fix it that way

Joey Stanford (joey) wrote :

<joey> jelmer: gotcha. If we can't resync because we need history, is there another method we can use?

<jelmer> joey: I think you would have to replay the history and make sure text revisions are recorded consistently with the way they are in lp:gcc

Jelmer Vernooij (jelmer) on 2012-07-25
Changed in bzr:
importance: Undecided → Medium
assignee: nobody → Jelmer Vernooij (jelmer)
status: New → Triaged
Jelmer Vernooij (jelmer) wrote :

So, it turns out we do already have *a* way of fixing broken repositories like this by replaying all data and recording the text revisions properly. This is fairly well hidden, and can be done by running "bzr reconcile --canonicalize-chks" in the affected repository(s).

Unfortunately this command is quite slow - on my machine it took 4 hours for the gcc repo just to get to rev 100, which is only a tiny fraction of the 115544 revisions in the repository overall.

Martin Packman (gz) wrote :

Seems like 'quite slow' is something of an understatement. Do we want a followup bug for making it less pathological?

Changed in bzr:
milestone: none → 2.6b3
status: Triaged → Fix Released
Vincent Ladeuil (vila) wrote :

> Seems like 'quite slow' is something of an understatement. Do we want a followup bug for making it less pathological?

Yes.

Jelmer Vernooij (jelmer) wrote :

In addition, it looks like 'bzr reconcile --canonicalize-chks' doesn't seem to fix all instances of this problem. Just confirmed this with glyph for the twisted repository.

Changed in bzr:
status: Fix Released → Triaged
assignee: Jelmer Vernooij (jelmer) → nobody
milestone: 2.6b3 → none
Michael Hope (michaelh1) wrote :

I'm afraid the current fix isn't usable if it's that slow. Jelmer's numbers suggest the repair would take six months.

Vincent Ladeuil (vila) on 2013-07-06
Changed in bzr:
milestone: none → 2.6b3
status: Triaged → Fix Released
status: Fix Released → Confirmed
milestone: 2.6b3 → none
Vincent Ladeuil (vila) on 2013-07-27
Changed in bzr:
milestone: none → 2.6b3
assignee: nobody → Jelmer Vernooij (jelmer)
status: Confirmed → Fix Released
status: Fix Released → Confirmed
assignee: Jelmer Vernooij (jelmer) → nobody
milestone: 2.6b3 → none
Jelmer Vernooij (jelmer) on 2017-11-09
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers