TypeError: StaticTuple can only point to StaticTuple, str, unicode, int, long, float, bool, or None not <type 'tuple'>

Bug #490600 reported by Gordon Tyler on 2009-12-01
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
High
John A Meinel

Bug Description

Using r4842 of bzr.dev, running bzr selftest, I get a lot of errors along the following lines:

Traceback (most recent call last):
  File "C:\dev\bzr\bzr.dev\bzrlib\tests\blackbox\test_log.py", line 949, in test_line_log_file
    self.prepare_tree()
  File "C:\dev\bzr\bzr.dev\bzrlib\tests\blackbox\test_log.py", line 831, in prepare_tree
    tree.commit('add file2')
  File "C:\dev\bzr\bzr.dev\bzrlib\decorators.py", line 194, in write_locked
    result = unbound(self, *args, **kwargs)
  File "C:\dev\bzr\bzr.dev\bzrlib\workingtree_4.py", line 197, in commit
    result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File "C:\dev\bzr\bzr.dev\bzrlib\decorators.py", line 194, in write_locked
    result = unbound(self, *args, **kwargs)
  File "C:\dev\bzr\bzr.dev\bzrlib\mutabletree.py", line 225, in commit
    *args, **kwargs)
  File "C:\dev\bzr\bzr.dev\bzrlib\commit.py", line 257, in commit
    possible_master_transports=possible_master_transports)
  File "C:\dev\bzr\bzr.dev\bzrlib\cleanup.py", line 117, in run
    self.cleanups, self.func, self, *args, **kwargs)
  File "C:\dev\bzr\bzr.dev\bzrlib\cleanup.py", line 147, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "C:\dev\bzr\bzr.dev\bzrlib\commit.py", line 395, in _commit
    self.builder.finish_inventory()
  File "C:\dev\bzr\bzr.dev\bzrlib\repository.py", line 215, in finish_inventory
    self.parents)
  File "C:\dev\bzr\bzr.dev\bzrlib\repofmt\groupcompress_repo.py", line 878, in add_inventory_by_delta
    inv_lines, check_content=False), result
  File "C:\dev\bzr\bzr.dev\bzrlib\repository.py", line 1084, in _inventory_add_lines
    check_content=check_content)[0]
  File "C:\dev\bzr\bzr.dev\bzrlib\groupcompress.py", line 1224, in add_lines
    nostore_sha=nostore_sha))[0]
  File "C:\dev\bzr\bzr.dev\bzrlib\groupcompress.py", line 1753, in _insert_record_stream
    flush()
  File "C:\dev\bzr\bzr.dev\bzrlib\groupcompress.py", line 1639, in flush
    self._index.add_records(nodes, random_id=random_id)
  File "C:\dev\bzr\bzr.dev\bzrlib\groupcompress.py", line 1913, in add_records
    self._add_callback(records)
  File "C:\dev\bzr\bzr.dev\bzrlib\btree_index.py", line 234, in add_nodes
    self.add_node(key, value, node_refs)
  File "C:\dev\bzr\bzr.dev\bzrlib\btree_index.py", line 166, in add_node
    node_refs, _ = self._check_key_ref_value(key, references, value)
  File "C:\dev\bzr\bzr.dev\bzrlib\index.py", line 208, in _check_key_ref_value
    node_refs.append(as_st(reference_list))
  File "C:\dev\bzr\bzr.dev\bzrlib\_static_tuple_py.py", line 72, in from_sequence
    return StaticTuple(*seq)
  File "C:\dev\bzr\bzr.dev\bzrlib\_static_tuple_py.py", line 42, in __init__
    ' None not %s' % (type(bit),))
TypeError: StaticTuple can only point to StaticTuple, str, unicode, int, long, float, bool, or None not <type 'tuple'>

Related branches

Andrew Bennetts (spiv) wrote :

I can reproduce this in a clean checkout with no C extensions built.

Changed in bzr:
importance: Undecided → High
status: New → Confirmed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> I can reproduce this in a clean checkout with no C extensions built.
>
> ** Changed in: bzr
> Importance: Undecided => High
>
> ** Changed in: bzr
> Status: New => Confirmed
>

 assigned jameinel

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksUe5gACgkQJdeBCYSNAANCugCgpon/dsWbhBqwpRFbzFJ/BqqL
Y/cAnRVimFy/vaZr5lp2iWJOutDeD1Bo
=yhxZ
-----END PGP SIGNATURE-----

Andrew Bennetts (spiv) wrote :

John, I think I just found the bug, see my patch in <lp:~spiv/bzr/static-tuple-pure-python-bug-490600>

Martin Pool (mbp) on 2009-12-01
Changed in bzr:
status: Confirmed → In Progress
assignee: nobody → Andrew Bennetts (spiv)
Russel Winder (russel) wrote :

OK guys, this has moved from "extremely serious" to "beyond a $$$$$$$ joke". I can't even get Bazaar with Bazaar now.

There followsa number of crash files from this evening attempt to update various Bazaar branches. Sadly Launchpad requires that I submit them individually, which $$$$$.

Russel Winder (russel) wrote :
Russel Winder (russel) wrote :
Russel Winder (russel) wrote :
Russel Winder (russel) wrote :
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russel Winder wrote:
> ** Attachment added: "bzr-20091201213919-14847.crash"
> http://launchpadlibrarian.net/36312862/bzr-20091201213919-14847.crash
>

Option 1: Compile your extensions. (make)

Option 2: update to the latest bzr.dev. It has 1 fix, I've already
proposed a second fix which seems to handle the rest of the cases.

Option 3: Use lp:~jameinel/bzr/2.1.0b4-490600-no-extensions until it
lands in bzr.dev. (Probably by tomorrow.)

Note that this has only been broken in bzr.dev since rev 4842, which
landed on Nov-30th, and we have one fix in rev 4846 on 12-01, and
another by 12-02. So it isn't like there has been a huge window of time
where not compiling the extensions was causing failures.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksVmlAACgkQJdeBCYSNAAOu8ACg2SfTG1xsrPEFtAY7UEmAUCLN
JgsAn18KZ0nDrtKh46ui4AH9MmrIcegI
=MX6O
-----END PGP SIGNATURE-----

Russel Winder (russel) wrote :

John,

Thanks for the prompt reply, much appreciated.

On Tue, 2009-12-01 at 22:36 +0000, John A Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Russel Winder wrote:
> > ** Attachment added: "bzr-20091201213919-14847.crash"
> > http://launchpadlibrarian.net/36312862/bzr-20091201213919-14847.crash
> >
>
> Option 1: Compile your extensions. (make)

Can't do that cleanly as far as I know (and Martin tells me) as I have
my bzr.dev shared by Ubuntu 32-bit and 64-bit, Mac OS X and Solaris.
NFS mounts -- but you probably knew this given my loud irritation at
Linux and mmap and TDB and bzr-svn/bzr-git (not anything that
bzr-svn/bzr-git can do about it though :-(

> Option 2: update to the latest bzr.dev. It has 1 fix, I've already
> proposed a second fix which seems to handle the rest of the cases.

This is what set me off, I am trying to update Bazaar bzr.dev and it is
not able to update because of the problem.

Interestingly I only get the StaticTuple problem when I update (I use
bound branches) If I try and pull I get:

        |> bzr pull
        Using saved parent location: http://bazaar-vcs.org/bzr/bzr.dev/
        bzr: ERROR: Cannot lock LockDir(lp-46125584:///~bzr-pqm/bzr/bzr.dev/.bzr/branchlock): Transport operation not possible: readonly transport
        |>

> Option 3: Use lp:~jameinel/bzr/2.1.0b4-490600-no-extensions until it
> lands in bzr.dev. (Probably by tomorrow.)

Hummm... I think something drastic may be needed, even
using /usr/bin/bzr to update or pull gives the same problems so I have
no version of Bazaar that is going to allow me to update my Bazaar
mirror. Looks like I'll have to ditch it and create a new shared
repository, mirror and working branch when the problem is fixed.

Though I may just not be thinking straight!

> Note that this has only been broken in bzr.dev since rev 4842, which
> landed on Nov-30th, and we have one fix in rev 4846 on 12-01, and
> another by 12-02. So it isn't like there has been a huge window of time
> where not compiling the extensions was causing failures.

I had been trying to keep my bzr.dev updated at least once per day, so
far it has never been a problem, just now it seems this is a bad
policy :-( Anyway I am confident everything will become OK, so no
long-term problem, just a short-term panic as I need to use Bazaar in my
Python training course tomorrow!

--
Russel.
=============================================================================
Dr Russel Winder Partner
                                            xmpp: <email address hidden>
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:<email address hidden>
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

2009/12/2 Russel Winder <email address hidden>:
> Can't do that cleanly as far as I know (and Martin tells me) as I have
> my bzr.dev shared by Ubuntu 32-bit and 64-bit, Mac OS X and Solaris.
> NFS mounts -- but you probably knew this given my loud irritation at
> Linux and mmap and TDB and bzr-svn/bzr-git (not anything that
> bzr-svn/bzr-git can do about it though :-(

If you run 'setup.py install --home ~' then I think it will install
the extensions into per-architecture directories under ~/lib, so they
will stay up to date. You will need to re-run this after each update
of bzr.dev. If it doesn't work, please either ask or file a bug as
appropriate.

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

Russel Winder wrote:
> This is what set me off, I am trying to update Bazaar bzr.dev and it is
> not able to update because of the problem.

Can you revert to a working revision? "bzr revert -r 4841", according to
what jam said.

> Interestingly I only get the StaticTuple problem when I update (I use
> bound branches) If I try and pull I get:
>
> |> bzr pull
> Using saved parent location: http://bazaar-vcs.org/bzr/bzr.dev/
> bzr: ERROR: Cannot lock LockDir(lp-46125584:///~bzr-pqm/bzr/bzr.dev/.bzr/branchlock): Transport operation not possible: readonly transport
> |>

That's right. Since you're using a bound branch, you're trying to pull
*to* http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/ (from
http://bazaar-vcs.org/bzr/bzr.dev/, its parent branch), which is
obviously not possible, since HTTP is read-only.
--
Matt Nordhoff

Martin,

Thanks for chipping in on this, I really appreciate it.

On Wed, 2009-12-02 at 00:21 +0000, Martin Pool wrote:
> 2009/12/2 Russel Winder <email address hidden>:
> > Can't do that cleanly as far as I know (and Martin tells me) as I have
> > my bzr.dev shared by Ubuntu 32-bit and 64-bit, Mac OS X and Solaris.
> > NFS mounts -- but you probably knew this given my loud irritation at
> > Linux and mmap and TDB and bzr-svn/bzr-git (not anything that
> > bzr-svn/bzr-git can do about it though :-(
>
> If you run 'setup.py install --home ~' then I think it will install
> the extensions into per-architecture directories under ~/lib, so they
> will stay up to date. You will need to re-run this after each update
> of bzr.dev. If it doesn't work, please either ask or file a bug as
> appropriate.

OK, that would solve the "technical" issue of having the checkout of
bzr.dev shared by many different architectures and yet still compiled.
However, the problem that remains is a "management" one, in that every
time I updated I would then have to login to each machine and run the
compilation (though I guess I could script such a compilation for all
the permanently connected machines). The huge advantage of not
compiling is that it works on all architectures just by updating on the
server and (I think this is the real "killer" point) I can Unison
synchronize the server copy to the laptops and back again in the full
knowledge that Bazaar will Just Work (tm) on all my machines.

NB I appreciate I get a performance hit by not compiling but the ease of
management across 7 machines outweighs this.

PS Matt's suggestion coming up prompted me to "do the right thing" and
I am now up to date with revision 4850.

Thanks.

--
Russel.
=============================================================================
Dr Russel Winder Partner
                                            xmpp: <email address hidden>
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:<email address hidden>
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

Vincent Ladeuil (vila) on 2009-12-02
Changed in bzr:
assignee: Andrew Bennetts (spiv) → John A Meinel (jameinel)
status: In Progress → Fix Committed
milestone: none → 2.1.0b4
Vincent Ladeuil (vila) on 2009-12-02
Changed in bzr:
status: Fix Committed → Fix Released
Russel Winder (russel) wrote :

As far as I can tell, I am not having any of the earlier problems with any of the repositories that were problematic, so I think this released fix is successful.

Thanks.

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