bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously.

Bug #528041 reported by Greg Grossmeier on 2010-02-25
146
This bug affects 22 people
Affects Status Importance Assigned to Milestone
Bazaar
High
Andrew Bennetts
2.1
High
Andrew Bennetts
2.2
High
Andrew Bennetts
bzr (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned

Bug Description

bzr 2.1.1 was released with an unknown regression with older servers. This is fixed in the stable release version 2.1.2 (bzr's equivalent of SRU's).

The symptom shows up when pushing from bzr 2.1.1 to bzr < 1.6 and will look roughly like:

Traceback:
   File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 3327, in _open
     return remote.RemoteBzrDir(transport, self)
   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 115, in __init__
     self._probe_bzrdir()
   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 130, in _probe_bzrdir
     medium._remember_remote_is_before((2, 1))
   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/medium.py", line 615, in _remember_remote_is_before
     % (version_tuple, self._remote_version_is_before))
 AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously.

This can be addressed by upgrading to 2.1.2.

Related branches

Martin Pool (mbp) wrote :

https://bugs.launchpad.net/bzr/+bug/528114 for the apport problem; thanks for reporting that.

description: updated
tags: added: hpss
Martin Pool (mbp) wrote :

I really think we should get rid of _remember_remote_is_before.

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Rainer Müller (raimue) wrote :

This seems to be similar to the problem in https://bugs.launchpad.net/bzr/+bug/418931

Just curious, can this bug be worked around by upgrading the remote's version of bzr to something newer (currently 1.5-1.1 [lenny]) ? Or do I have to wait for a fix for this specific issue?

I worked around this by switching to sftp instead of ssh+bzr.

Daniel

On Tue, Mar 16, 2010 at 10:48 AM, Greg Grossmeier <email address hidden> wrote:
> Just curious, can this bug be worked around by upgrading the remote's
> version of bzr to something newer (currently 1.5-1.1 [lenny]) ? Or do I
> have to wait for a fix for this specific issue?
>
> --
> bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously.
> https://bugs.launchpad.net/bugs/528041
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Bazaar Version Control System: Confirmed
>
> Bug description:
> I was pushing a branch to a remote location and encountered this exception.
>
> local bzr: 2.1.0-1 (lucid)
> remote bzr: 1.5-1.1 (lenny)
>
> [note: I tried to have apport submit the .crash file, but it gave me a "This problem report applies to a program which is not installed any more." error, obviously wrong]
>
> Traceback:
>  Traceback (most recent call last):
>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 853, in exception_to_return_code
>     return the_callable(*args, **kwargs)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1055, in run_bzr
>     ret = run(*run_argv)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 661, in run_argv_aliases
>     return self.run_direct(**all_cmd_args)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 665, in run_direct
>     return self._operation.run_simple(*args, **kwargs)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 122, in run_simple
>     self.cleanups, self.func, *args, **kwargs)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 156, in _do_with_cleanups
>     result = func(*args, **kwargs)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 1146, in run
>     use_existing_dir=use_existing_dir)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/push.py", line 83, in _show_push_branch
>     dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 878, in open_from_transport
>     return format.open(transport, _found=True)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 2088, in open
>     return self._open(transport)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 3327, in _open
>     return remote.RemoteBzrDir(transport, self)
>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 115, in __init__
>     self._probe_bzrdir()
>   File "/usr/lib/python2.6/dist-packages/bzrlib/remote.py", line 130, in _probe_bzrdir
>     medium._remember_remote_is_before((2, 1))
>   File "/usr/lib/python2.6/dist-packages/bzrlib/smart/medium.py", line 615, in _remember_remote_is_before
>     % (version_tuple, self._remote_version_is_before))
>  AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/bzr/+bug/528041/+subscribe
>

Martin Pool (mbp) wrote :

On 17 March 2010 01:48, Greg Grossmeier <email address hidden> wrote:
> Just curious, can this bug be worked around by upgrading the remote's
> version of bzr to something newer (currently 1.5-1.1 [lenny]) ? Or do I
> have to wait for a fix for this specific issue?

Yes, that will fix it.

As should using nosmart+bzr+ssh://host.... or sftp

--
Martin <http://launchpad.net/~mbp/>

Toshio Kuratomi (toshio) wrote :

Also affect packages in Fedora 13, due to release ~ 1 month -- https://bugzilla.redhat.com/show_bug.cgi?id=579214

Riccardo Murri (rmurri) wrote :

Just wanted to add that this affects also "pull" and "merge" from remote repo over bzr+ssh.

Using sftp:// or nosmart+bzr+ssh:// fixes it - thanks for suggesting this workaround!

Same setup as OP: local bzr is 2.1 (lucid), remote is 1.5 (lenny).

Ralf Schulze (ralf-schulze) wrote :

Same is happening for 'checkout' and 'branch' over bzr:// for me.

Local version: 2.11
Remote version: 1.5

Andrew Bennetts (spiv) wrote :

This appears to be happening because BzrDir.open_2.1 is often the first RPC tried, which means that underlying protocol version hasn't yet been determined either. If the server is older than bzr 1.6, that protocol version will turn out to be v2, and the client is smart enough to immediately realise that v2 implies the server must be older than 1.6. And of course the RPC will then fail because the server is too old to recognise the verb. Normally what happens is that the client then remembers that the server must be older than 2.1, and proceeds with the fallbacks. Unfortunately the simultaneous protocol-version probe has almost remembered that it is < 1.6, and this trips the AssertionError.

The fix is to remove the AssertionError: this is an essentially harmless condition. Developers may be interested to know when it happens, because it indicates somewhere where we could be more efficient in our network conversation, but there's no good reason for bzr to actually stop at this point. So I'm making a branch that quietly logs this event (and optionally warns developers about it if they set the -Dhpss debug flag).

(In this specific case it would be more optimal at the point that we find out that the protocol is v2 to not even try the RPC, but that's not easy to do in the current code without ugly hacks and saving a single round-trip when talking to such old servers is not particularly important anyway.)

Changed in bzr:
assignee: nobody → Andrew Bennetts (spiv)
status: Confirmed → In Progress
Andrew Bennetts (spiv) wrote :

Oh, and I consider this bug to be High rather than Medium importance due to the steady trickle of duplicates, so I'm setting the Importance field accordingly.

Changed in bzr:
importance: Medium → High
Andrew Bennetts (spiv) on 2010-04-30
Changed in bzr:
milestone: none → 2.1.2
status: In Progress → Fix Released
nirav (niro-hiro) wrote :

original poster here: thanks! sftp worked well.

Martin Pool (mbp) wrote :

From https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/583769 - we should get the fix for this into lucid-updates.

Martin Pool (mbp) wrote :

We need to make a 2.1.2, which should have this fixed, then ask for it to go into lucid-updates.

Changed in bzr:
milestone: 2.1.2 → 2.2b3
Changed in bzr (Ubuntu):
status: New → Confirmed
description: updated
Robert Collins (lifeless) wrote :

Hmm, sadly history is disjoint from bzr's, prepping a branch anyway.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bzr - 2.2.0-1

---------------
bzr (2.2.0-1) unstable; urgency=low

  * New upstream release.
   + Adds support for setting timestamps to originating revisions.
     Closes: #473450
   + Removes remaining string exception. Closes: #585193, LP: #586926
   + Add C extension to work around Python issue 1628205. LP: #583941,
     Closes: #577110
   + Avoids showing progress bars when --quiet is used. Closes: #542105,
     LP: #320035
   + No longer creates ~/.bazaar as root when run under sudo. LP: #376388
   + 'bzr commit' now supports -p as alternative for --show-diff. LP: #571467
   + 'bzr add' no longer adds .THIS/.BASE/.THEIRS files unless
     explicitly requested. LP: #322767
   + When parsing patch files, Bazaar now supports diff lines before each
     patch. LP: #502076
   + WorkingTrees now no longer requires using signal.signal, so can
     be used in a threaded environment. LP: #521989
   + An assertion error is no longer triggered when pushing to a pre-1.6
     Bazaar server. LP: #528041
  * Bump standards version to 3.9.1.

bzr (2.2.0~b4-1) experimental; urgency=low

  * New upstream beta.
  * Bump standards version to 3.9.0.
  * Drop build dependency on zlib.

bzr (2.2.0~b2-1) experimental; urgency=low

  * New upstream release.
  * Recommend python-launchpadlib. Closes: #568937

bzr (2.1.2-1.1) unstable; urgency=low

  * Non-maintainer upload.
  * Fix access via http_proxy. Closes: #588430
 -- Jelmer Vernooij <email address hidden> Sat, 07 Aug 2010 00:54:52 +0200

Changed in bzr (Ubuntu):
status: Confirmed → Fix Released
Martin Pitt (pitti) wrote :

SRU ack for http://bazaar.launchpad.net/~lifeless/ubuntu/lucid/bzr/2.1.2-sru/revision/15. It's a bit unfortunate that the diff is so large, but most is just changed source line comments in the pyx stuff. The other changes seem to be testcase'd nicely. Please upload.

Changed in bzr (Ubuntu Lucid):
status: New → Confirmed

Thanks Pitti,

We don't have the generated .c files in the upstream tree. I wonder
why they're showing up in that diff, and if they could easily be
removed.

Martin Pool (mbp) on 2010-09-20
tags: added: sru

Accepted bzr into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in bzr (Ubuntu Lucid):
status: Confirmed → Fix Committed
tags: added: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bzr - 2.1.4-0ubuntu1

---------------
bzr (2.1.4-0ubuntu1) lucid-proposed; urgency=low

  * Update watch file to use 2.1 series.
  * New upstream release.
   + Fix file descriptors leaks in dirstate compiled extension. LP: #583486
   + Refuse to stack on repositories in incompatible formats. LP: #562380
   + Don't delete nested trees/repos. LP: #572098
   + Fix 'bzr switch' crash when a 'ConfigurableFileMerger' is used. LP: #559436
   + Fix compatibility with older smart servers. LP: #528041
   + Fix symlinks addition. LP: #192859
   + Properly unversion children of unversioned directories. LP: #494221
   + Lock configuration files in '~/.bazaar' for updates. LP: #525571
   + Fix 'bzr commit <symlink>'. LP: #128562
   + Fix `lp:` urls when behind an http proxy. LP: #558343
   + Stop using edge.launchpad.net. LP: #583667
 -- Max Bowsher <email address hidden> Tue, 17 May 2011 09:54:17 +0100

Changed in bzr (Ubuntu Lucid):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.