unexpected line in Next(): #1688

bussiere · 2015-09-11T15:11:59Z

I'am currently manipulating pictures and gallery of pictures :
Seems kind of backslash plague with \n\

   time="16:33:05:000" level=error msg="multipart: unexpected line in Next(): \"A\\xa1טY\\xfa\\x12\\xe4\\xdbĬ \\x8bOr\\x80u\\x86\\xc2\\x03X\\fj\\x97\\x86\\x9dd\\xb18\\x14\\x85\\x84#\\xe1\\x16\\xe6d\\x00\\xb6\\a2j\\xf8})\\xb1ļ\\x10P\\b{e[2T\\xc361\\xaf\\x12\\xb6\\xf1\\xb2>\\xd3r\\xc4S5\\xc4/\\xa4W)O<\\xc3\\x1d\\xca\\xc0\\x03\\xa4\\xddW\\x830\\xcdv\\xfcõq<\\x92\\xdf\\x19\\x89ឝ`\\xa6Q\\xab\\xe5nZ\\xb5q\\xb4\\x81\\x980\\x11\\x93R\\xe7QR+l\\xf9\\x98\\xcd_\\x04\\xa4@;`\\n\"" module="commands/http


ipfs add -r . > result.txt
time="16:33:05:000" level=error msg="multipart: unexpected line in Next(): \"A\\xa1טY\\xfa\\x12\\xe4\\xdbĬ\\x8bOr\\x80u\\x86\\xc2\\x03X\\fj\\x97\\x86\\x9dd\\xb18\\x14\\x85\\x84#\\xe1\\x16\\xe6d\\x00\\xb6\\a2j\\xf8})\\xb1ļ\\x10P\\b{e[2T\\xc361\\xaf\\x12\\xb6\\xf1\\xb2>\\xd3r\\xc4S5\\xc4/\\xa4W)O<\\xc3\\x1d\\xca\\xc0\\x03\\xa4\\xddW\\x830\\xcdv\\xfcõq<\\x92\\xdf\\x19\\x89ឝ`\\xa6Q\\xab\\xe5nZ\\xb5q\\xb4\\x81\\x980\\x11\\x93R\\xe7QR+l\\xf9\\x98\\xcd_\\x04\\xa4@;`\\n\"" module="commands/http" 
bussiere@kusanagi:/media/bussiere/ext_kus111/_build$ leafpad result.txt 
bussiere@kusanagi:/media/bussiere/ext_kus111/_build$ ipfs add -r . > result.txt
time="17:10:11:000" level=error msg="unexpected EOF" module="commands/http" 
bussiere@kusanagi:/media/bussiere/ext_kus111/_build$

The text was updated successfully, but these errors were encountered:

whyrusleeping · 2015-09-11T15:28:56Z

@bussiere what version of ipfs (git sha if you can), OS and archictecture?

whyrusleeping · 2015-09-11T15:30:31Z

Also, is there anything weird about the gallery? such as uf8 file names or strange file types

bussiere · 2015-09-11T15:40:52Z

Ubuntu 14.04 go 1.5 amd64
~/Lib/Go/src/github.com/jbenet/go-ipfs$ git rev-parse HEAD
a0e5fc8

And yes in the gallerie it may have some french character as ç or japanese one.

Thanks

bussiere · 2015-09-11T16:58:12Z

That's strange because if i try to add it folder by folder it seems to works :

whyrusleeping · 2015-09-11T17:13:23Z

@bussiere do you mind zipping up a set of files that can repro the issue?

bussiere · 2015-09-11T17:32:24Z

yep the zip is here : QmfYQRPWworETuBudtayhkmCAMxmz8LV3YXm3KXwytyrfM

and i've isolated the error ::

bussiere@kusanagi:/media/bussiere/ext_kus111/101APPLE$ ipfs add -r .
added QmV6BSMWFohrBXVHBEP21asUr8LFJZyz157BtPyNLmwzzs 101APPLE/IMG_1750.JPG/5003.JPG
added QmVtC61fyphzwbBDQ5zGoZVddg4H6D2hRvdewHim2j9ou4 101APPLE/IMG_1750.JPG/index.html
added Qmdp2JAxw7s6mAAsJYdoa8DTjqtkBU2jgWQSRwthGkKx7y 101APPLE/IMG_1750.JPG/thumbnails/5003.JPG
added QmbaQJLPh2jc99BTN6qhdcJT9uMZUdU76jYpDgC8TUDLtp 101APPLE/IMG_1750.JPG/thumbnails
added QmdtitSecheXBnR4KWY6WLxcbVYY6oYeGBC7gJoN6QWXmu 101APPLE/IMG_1750.JPG
added QmX68ToAb8EBssnoT1NcqQwU4oYyxiFViF4F9jrneqAmwE 101APPLE/IMG_1751.JPG/5003.JPG
added QmQVCbVXRXutwQmC9NBubAvnf7QnqyKtFzE6cW1iMkn8Gf 101APPLE/IMG_1751.JPG/index.html
added QmaxjEAnbkwtyW3WHc9HdxSQvBBmUTx5NKLN5oMAJXJAzY 101APPLE/IMG_1751.JPG/thumbnails/5003.JPG
added QmbMcBeVikQPiroUxGFbpknLFthgScrEuBkfktNfACHonu 101APPLE/IMG_1751.JPG/thumbnails
added QmRdQZZEjhe1ZdTb13udjNm6CBrveh8H8Cg2ctRetBKVBu 101APPLE/IMG_1751.JPG
added QmZfLYsLgmSQx7JiscQCHLwoMS68uxTeNMbHK3CGZHUeJW 101APPLE/IMG_1752.JPG/5003.JPG
added QmaKScnQyqguLF1pDmo1fNowMnhAMuoEKt2H4U9jrmiqWu 101APPLE/IMG_1752.JPG/index.html
ERRO[19:28:53:000] multipart: unexpected line in Next(): "\x97\xec(\x0eQ\x80\xeb\u007f16)\x8a\xf1\n" module=commands/http
added QmbFMke1KXqnYyBBWxB74N4c5SBnJMVAiMNRcGu6x1AwQH 101APPLE/IMG_1752.JPG/thumbnails/5003.JPG

thanks

jbenet · 2015-09-14T04:00:05Z

multipart blowing up?

ion1 · 2015-09-17T21:07:20Z

Just like #1722, @eminence reported that this only happens with the binary from gobuilder.me but not with one he built.

jbenet · 2015-09-17T21:10:39Z

Which version is the gobuilder one? 0.3.7 or 0.3.8-dev?

—
Sent from Mailbox

On Thu, Sep 17, 2015 at 5:07 PM, Johan Kiviniemi notifications@github.com
wrote:

Just like #1722, @eminence reported that this only happens with the binary from gobuilder.me but not with one he built.

Reply to this email directly or view it on GitHub:
#1688 (comment)

eminence · 2015-09-17T21:14:52Z

The gobuilder version I downloaded came from the URL below and was downloaded approximately at 5:00 PM EST today. THe .zip archive has a timestamp of "Sept 16 02:41", and it identifies itself as ipfs version 0.3.8-dev.

This version string is identical to the string produced by the working version of IPFS that doesn't reproduce this issue

https://gobuilder.me/get/github.com/ipfs/go-ipfs/cmd/ipfs/ipfs_master_linux-amd64.zip

jbenet · 2015-09-17T22:49:35Z

SIgh, ok. i worried we'd run into a case like this soon enough. we need to start putting git commit short hashes into the version string (0.3.8-dev-a1b2c3) or something.

@whyrusleeping thoughts here?

sonatagreen · 2015-10-11T04:58:00Z

I'm getting the same error. I pulled a fresh version a few minutes ago with go get -u github.com/ipfs/go-ipfs/cmd/ipfs, and ipfs version returns ipfs version 0.3.8-dev.

I tried to attach a file that causes the error, but github doesn't seem to like it either. Here's the base64 encoded gzip of it: H4sICK3oGVYAA2NyYXNoZmlsZS50eHQA7cIxEQAgDACxvYoZ6wEDaKmUKimHCobkv069Ovc9FgAAAPCbGEzR8b+/DwAA

To recreate the file, do:

echo H4sICK3oGVYAA2NyYXNoZmlsZS50eHQA7cIxEQAgDACxvYoZ6wEDaKmUKimHCobkv069Ovc9FgAAAPCbGEzR8b+/DwAA > crashfile.txt.gz.b64
base64 -d crashfile.txt.gz.b64 > crashfile.txt.gz
gunzip crashfile.txt.gz

I experimented a bit with how much I could 'simplify' the file while still getting the error, in order to try to narrow down what's happening.

The following seems not to affect whether the error occurs:

replacing a normal character with another normal character
reordering characters

But the following does:

adding or deleting a normal or unusual character
replacing a normal character with an unusual character, or vice versa

Replacing an unusual character with another unusual character sometimes affects it, and sometimes doesn't. I haven't worked out the pattern.

I've identified the following characters as 'unusual':

U+00A0 NO-BREAK SPACE
U+00A9 COPYRIGHT SIGN
U+2013 EN DASH
U+2261 IDENTICAL TO

I assume there are many others, which I haven't bothered to look for.

davidar · 2015-10-11T05:12:54Z

Could this be related to #1582 ?

sonatagreen · 2015-10-11T05:17:37Z

Possible, but I don't see how bad UTF-8 handling would explain the fact that the crash goes away when I change the leading characters from ©©©©–– to ©©©–––.

davidar · 2015-10-11T05:31:57Z

To be honest I'm more surprised that ipfs doesn't crash on binary files more often given the broken json codec.

whyrusleeping · 2015-10-11T08:21:31Z

@davidar broken json codec? i may be missing some context here

davidar · 2015-10-11T10:08:03Z

@whyrusleeping the issue I just linked, with the json encoding corrupting binary data

jbenet · 2015-10-11T10:09:59Z

how common is this for you @sonatagreen ?

sonatagreen · 2015-10-11T20:50:12Z

It's only happened to me once so far.

sonatagreen · 2015-10-27T03:53:58Z

Ran into it again today, so twice now.

One-liner to reproduce:

gunzip /ipfs/QmXhHWLZcT4BbVrihUZK6bm9Detty9vAztmiMR2M9kP58g/crashfile.txt.gz -c > crashfile.txt ; ipfs add crashfile.txt

eminence · 2015-11-01T18:45:15Z

i ran into this today. i didn't save the file that triggered this error

mhe · 2015-11-18T20:51:40Z

I ran into the same issue when experimenting with IPFS. I started to dig into it a bit and the interesting thing is that it appears to depend on file size. I can reproduce this behaviour for any file of size n*4032-1 (where n is an integer > 0).

dd if=/dev/zero of=testfile bs=1 count=8063
ipfs add testfile
ipfs cat QmPftE3vHBA9cVS1DgnFXLhv4reSvLzEKbCWqCYe94zafU > testfile_cat
diff testfile testfile_cat
hexdump testfile
hexdump testfile_cat

The hex dump of testfile:

0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* 
0001f70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   
0001f7f

The hex dump of testfile_cat:

0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001f70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d
0001f80 0a 2d 2d                                       
0001f83

Considering the "boundary-line" of the mime-multipart thing appears to be of length 62, together with two characters \r and \n this adds up to 64. Add this to the magic number 4032 (see above) and you have 4096. This happens to be the same as the peek buffer size in go's multipart package (https://golang.org/src/mime/multipart/multipart.go). I haven't had the time to pinpoint the exact cause, but I suspect the cause of this bug is hiding in the complexity of (the peek buffer part of) this multipart package. Also considering the diff between the original and the retrieved file: it is 4 bytes longer, exactly '\r\n--'. Perhaps the boundary-line is not properly detected in these cases? Anyway, perhaps this is another data-point that can help in resolving this.

jbenet · 2015-11-20T07:48:43Z

I can reproduce this behaviour

@mhe great! could you contribute a sharness test case so we can make it pass?

mhe · 2015-11-22T12:46:03Z

@jbenet Sure, sounds like an interesting exercise :) I've attached a sharness test to this comment (I thought an PR would be a bit overkill).

t0250-multipart-file4031.sh.txt

jbenet · 2015-12-01T02:48:30Z

Ok thanks @mhe -- we should make a PR with a fix that includes that test case.

travisperson · 2015-12-21T10:43:27Z

I assume this is fixed as of 1.5.2 golang/go/issues/12662 ?

whyrusleeping · 2015-12-21T17:43:32Z

@travisperson ah yes! thanks, i can close this now.

whyrusleeping added the kind/bug A bug in existing code (including security flaws) label Sep 11, 2015

ion1 mentioned this issue Sep 17, 2015

MIME boundary and headers from an API call leak to file contents #1722

Closed

whyrusleeping mentioned this issue Dec 8, 2015

flatten multipart transfers #2046

Merged

travisperson mentioned this issue Dec 21, 2015

Multipart Error: unexpected line in Next(), IPFS not reading everything from Part. #2112

Closed

whyrusleeping closed this as completed Dec 21, 2015

djdv mentioned this issue Dec 24, 2015

Windows: ipfs -r <path> behaves inconsistent and can crash #2115

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unexpected line in Next(): #1688

unexpected line in Next(): #1688

bussiere commented Sep 11, 2015

whyrusleeping commented Sep 11, 2015

whyrusleeping commented Sep 11, 2015

bussiere commented Sep 11, 2015

bussiere commented Sep 11, 2015

whyrusleeping commented Sep 11, 2015

bussiere commented Sep 11, 2015

jbenet commented Sep 14, 2015

ion1 commented Sep 17, 2015

jbenet commented Sep 17, 2015

Just like #1722, @eminence reported that this only happens with the binary from gobuilder.me but not with one he built.

eminence commented Sep 17, 2015

jbenet commented Sep 17, 2015

sonatagreen commented Oct 11, 2015

davidar commented Oct 11, 2015

sonatagreen commented Oct 11, 2015

davidar commented Oct 11, 2015

whyrusleeping commented Oct 11, 2015

davidar commented Oct 11, 2015

jbenet commented Oct 11, 2015

sonatagreen commented Oct 11, 2015 via email

sonatagreen commented Oct 27, 2015

eminence commented Nov 1, 2015

mhe commented Nov 18, 2015

jbenet commented Nov 20, 2015

mhe commented Nov 22, 2015

jbenet commented Dec 1, 2015

travisperson commented Dec 21, 2015

whyrusleeping commented Dec 21, 2015

unexpected line in Next(): #1688

unexpected line in Next(): #1688

Comments

bussiere commented Sep 11, 2015

whyrusleeping commented Sep 11, 2015

whyrusleeping commented Sep 11, 2015

bussiere commented Sep 11, 2015

bussiere commented Sep 11, 2015

whyrusleeping commented Sep 11, 2015

bussiere commented Sep 11, 2015

jbenet commented Sep 14, 2015

ion1 commented Sep 17, 2015

jbenet commented Sep 17, 2015

Just like #1722, @eminence reported that this only happens with the binary from gobuilder.me but not with one he built.

eminence commented Sep 17, 2015

jbenet commented Sep 17, 2015

sonatagreen commented Oct 11, 2015

davidar commented Oct 11, 2015

sonatagreen commented Oct 11, 2015

davidar commented Oct 11, 2015

whyrusleeping commented Oct 11, 2015

davidar commented Oct 11, 2015

jbenet commented Oct 11, 2015

sonatagreen commented Oct 11, 2015 via email

sonatagreen commented Oct 27, 2015

eminence commented Nov 1, 2015

mhe commented Nov 18, 2015

jbenet commented Nov 20, 2015

mhe commented Nov 22, 2015

jbenet commented Dec 1, 2015

travisperson commented Dec 21, 2015

whyrusleeping commented Dec 21, 2015