bzr error: Bad message kind byte: '\\x1d'

repeatable

joey@booffalo:~/oem-presentations$ bzr push -v
Using saved push location: bzr+ssh://bazaar.launchpad.net/~oem-solutions-group/oem-process/oem-presentations/
Connection to bazaar.launchpad.net closed by remote host.m
bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Generic bzr smart protocol error: Bad message kind byte: 'K'")

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    attaching the crash file
        /home/joey/.cache/crash/bzr-20100305120025-3098.crash
    and including a description of the problem.

    The crash file is plain text and you can inspect or edit it to remove
    private information.
joey@booffalo:~/oem-presentations$ ?field.comment=repeatable

joey@booffalo:~/oem-presentations$ bzr push -v
Using saved push location: bzr+ssh://bazaar.launchpad.net/~oem-solutions-group/oem-process/oem-presentations/
Connection to bazaar.launchpad.net closed by remote host.m
bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Generic bzr smart protocol error: Bad message kind byte: 'K'")

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    attaching the crash file
        /home/joey/.cache/crash/bzr-20100305120025-3098.crash
    and including a description of the problem.

    The crash file is plain text and you can inspect or edit it to remove
    private information.
joey@booffalo:~/oem-presentations$

I did the following to a file rename and the problem went away

mv CanonicalOEMEngineeringOverview_v0\ .8.odp CanonicalOEMEngineeringOverview.odp

After you renamed that file, did you get any other messages (like a warning or error from the server?) or did it just totally work?

This looks a bit like the server is for some reason writing filenames into the rpc stream.

Wow, how big is the branch? I'm grabbing it to do some local testing and 260 megs in it's still going...

I'm unsure as the best way forward. Joey, can you push the branch to another local machine using the bzr+ssh protocol to see what the smartserver says?

I can push r40 of the branch up to a local launchpad instance without problems. I guess if this happens again, please save a copy of the branch/repo as it is so we can play with it...

On Sun, Mar 7, 2010 at 20:33, Martin Pool <email address hidden> wrote:
> After you renamed that file, did you get any other messages (like a
> warning or error from the server?) or did it just totally work?

Nope, it totally worked without errors. Upload speed was good too.

On Sun, Mar 7, 2010 at 21:36, Michael Hudson
<email address hidden> wrote:
> I can push r40 of the branch up to a local launchpad instance without
> problems.  I guess if this happens again, please save a copy of the
> branch/repo as it is so we can play with it...

Try this.

1) Grab the branch
2) copy out the file
3) bzr remove the file, commit, push to a test branch
4) rename the file, add, commit, and push

If anything is going to trigger the error, that would.

I'm a bit skeptical that the file rename is the key issue here: many other projects have filenames with spaces and dots, and it's not really the sort of error I would expect to get if there was an encoding problem with filename. It's just as likely that something about adding another commit, regardless of what was changed in it, is what worked around the problem.

Rather than guessing at the cause, I would try reproducing this by taking a branch from 2 revisions before the rename (r39), putting that on a smart server, and trying to push just r40 to it, which as far as I can tell is as close as we can get to the scenario that was failing for Joey.

I know Andrew said "let's not guess" which is generally a good idea ... but I'm still going to guess that the server is sending error messages onto the socket. Didn't mwh recently fix a similar bug?

Yes I did. We've also found that conch has a bug when the client tries to rekey the connection, so it _could_ be that (but the default is to rekey after a gig of traffic transferred so probably not....)

Note that the error is the server reporting that the *client* sent a corrupted message. So that would seem to rule out the "server is sending error messages onto the socket" hypothesis.

See also bug 622844 which has very similar symptoms, and may turn out to be a duplicate.

I'm going to mark the similar bugs as dupes; perhaps as we investigate further we may find multiple causes or situations.

We could make this more debuggable by making the code read and print out the next several bytes; that might give a clue.