How to fix the error "fatal: protocol error: bad line length 2210"

[Python Prog]

Hi

I am trying to push a commit and running into below error,i looked at other posts and but couldn't find anything specific to what the code 2210 means,our developers are clueless about this error,

any guidance on how to debug or fix this error?

fatal: protocol error: bad line length 2210

Commit looks like below

commit b157c973280ccadb739f08bb6283d580241ec459
Author: FIRSTNAME LASTNAME <yulLASTNAME@company.com>
Date:   Wed Sep 12 18:29:40 2018 -0700

    <change://problem/12435467>Clang-1001 failed to build Driver [CLONED_FROM_milestone]
   
    [Problem]
    enable repword support for com driver
   
    [Root Cause]
    enable repword support for com driver
   
    [Scenario/Frequency]
    always
   
    [Description of Change]
    enable repword support for com driver
   
    [Platforms Impacted]
    ABC
   
    [Memory/Performance/Power/Security Impact]
    Low
   
    [Dependencies]
    None
   
    [Risks]
    Low
   
    [Test Method]
    Tested
   
    Change-Id: I51a54859892a7e2c087d654ca16e882d55e67c4b
    Reviewed-on: https://tech-gerrit.sd.company.com/17226
    Reviewed-by: FIRSTNAME3 LASTNAME3 <usernam3@company.com>
    Build-OSX: service account<service@company.com>
    Tested-by: FIRSTNAME LASTNAME <FIRSTNAME_LASTNAME@company.com>
    Reviewed-on: https://tech-gerrit.sd.company.com/12345

    Tested-by: FIRSTNAME2 LASTNAME2 <FIRSTNAME2_LASTNAME2@company.com>

[Björn Pedersen]

Hi,

Am Freitag, 14. September 2018 01:12:15 UTC+2 schrieb Python Prog:

Hi

I am trying to push a commit and running into below error,i looked at other posts and but couldn't find anything specific to what the code 2210 means,our developers are clueless about this error,

any guidance on how to debug or fix this error?

fatal: protocol error: bad line length 2210

The 2210 is not an error code, but the incorrect line length. It seems like the commit message was created with incorrect line breaks, so that everything is treated as one line line. Make sure the the line breaks are
\n (decimal 13),  not \r (as I  think Macs tend to use by default) or \r\n ( typically from Microsoft systems).#

Björn
 

[Jonathan Nieder]

> The 2210 is not an error code, but the incorrect line length

Indeed.

> It seems like the commit message was created with incorrect line breaks, so that everything is treated as one line line.

The error message isn't about the commit message; instead, it's about the data sent over the wire. What version of Git are you running? What protocol do you use (https or ssh)? What command are you using to push? Are there any proxies or other aspects of the setup that might be relevant?

Thanks,

Jonathan

чт, 13 сент. 2018 г. в 22:04, 'Björn Pedersen' via Repo and Gerrit Discussion <repo-d...@googlegroups.com>:

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Elijah Newren]

Hi,

On Thursday, September 13, 2018 at 4:12:15 PM UTC-7, Python Prog wrote:

Hi

I am trying to push a commit and running into below error,i looked at other posts and but couldn't find anything specific to what the code 2210 means,our developers are clueless about this error,

any guidance on how to debug or fix this error?

fatal: protocol error: bad line length 2210

This is a blast from the past; I totally forgot about hitting that.  Do you happen to have a ref-update hook installed on your server, one with a small chance of producing over 64 Kib of output?

If so, I apologize.  I hit this years ago, even figured out a simple reproduction, but ran again into "That's cool that you found the problem and fixed _our_ stack.  Contributing fixes upstream would be great but not until we aren't so busy."  Wanted to track down and fix the bug (though I'm weak at java and not too familiar with gerrit sources), but eventually forgot about it altogether as the promised future sunny day when we weren't so busy never materalized across the next few managers (it's starting to open up, but git-side rather than gerrit-side).

From my old notes:

Create a simple ref-update hook that simply runs:

#!/usr/bin/env python

raise SystemExit('z'*5+'oops'+'z'*(65536-5))

(i.e. print 'zzzzzoops' plus 65531 more z characters. You can replace 'z' with anything else. All that matters is the combination of the length being more than 65535 and the position of the oops relative to how much more the length is than 65535). Then when you try to push to the repo, you'll be greeted by:

$ git push origin HEAD:refs/for/master

Counting objects: 3, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (2/2), done.

Writing objects: 100% (3/3), 308 bytes | 0 bytes/s, done.

Total 3 (delta 1), reused 0 (delta 0)

remote: Resolving deltas: 100% (1/1)

remote: Processing changes: refs: 1, done    

fatal: protocol error: bad line length character: oops

I could replace 'oops' in "fatal: protocol error: bad line length character: oops" with any other four-character string by just modifying my little python script appropriately.

How does this happen? Messages sent with the git protocol are sent in a packetized stream, with each git-packet being prefixed by the length of the packet. The prefix is always a 4-hex-digit length, with as many leading 0's in the length as necessary. So the longest single message that can be sent in a git-packet is 16**4 = 65536 bytes.

Technically the fact that a protocol error is displayed is a bug in gerrit (if you send a really huge message in a pre-receive hook, git breaks it up correctly and transfers it to the other side. gerrit must do some kind of two-byte math in calculating the length and not check for overflow).  It should have instead shown the ridiculously long message and then we would have quickly found the bug in our hook. But it's hard to blame gerrit because who'd be dumb enough to print that much output in an error message? (Other than me?)

[Matthias Sohn]

I guess that's rather a bug in JGit than in Gerrit.

-Matthias