Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image/jpeg: unreadByteStuffedByte call cannot be fulfilled #10387

Closed
dvyukov opened this issue Apr 8, 2015 · 0 comments
Closed

image/jpeg: unreadByteStuffedByte call cannot be fulfilled #10387

dvyukov opened this issue Apr 8, 2015 · 0 comments
Assignees
Milestone

Comments

@dvyukov
Copy link
Member

@dvyukov dvyukov commented Apr 8, 2015

Run the following program on the following input:

package main

import (
    "bytes"
    "image/jpeg"
    "io/ioutil"
    "os"
)

func main() {
    data, _ := ioutil.ReadFile(os.Args[1])
    img, err := jpeg.Decode(bytes.NewReader(data))
    if err != nil {
        return
    }
    var w bytes.Buffer
    err = jpeg.Encode(&w, img, nil)
    if err != nil {
        panic(err)
    }
}

https://drive.google.com/file/d/0B20Uwp8Hs1oCU2NTRmdxNmRBb0E/view?usp=sharing

It crashes with:

panic: jpeg: unreadByteStuffedByte call cannot be fulfilled

goroutine 1 [running]:
runtime.gopanic(0x49ac60, 0xc20800e570)
    src/runtime/panic.go:477 +0x3fe fp=0xc208041a08 sp=0xc208041988
image/jpeg.(*decoder).unreadByteStuffedByte(0xc20806e000)
    src/image/jpeg/reader.go:173 +0x8a fp=0xc208041a48 sp=0xc208041a08
image/jpeg.(*decoder).decodeHuffman(0xc20806e000, 0xc20806f150, 0xd, 0x0, 0x0)
    src/image/jpeg/huffman.go:190 +0x1cb fp=0xc208041ae8 sp=0xc208041a48
image/jpeg.(*decoder).processSOS(0xc20806e000, 0x6, 0x0, 0x0)
    src/image/jpeg/scan.go:232 +0x17e5 fp=0xc208041de8 sp=0xc208041ae8
image/jpeg.(*decoder).decode(0xc20806e000, 0x7fe5025251c0, 0xc208014450, 0x574300, 0x0, 0x0, 0x0, 0x0)
    src/image/jpeg/reader.go:619 +0xa4e fp=0xc208041e88 sp=0xc208041de8
image/jpeg.Decode(0x7fe5025251c0, 0xc208014450, 0x0, 0x0, 0x0, 0x0)
    src/image/jpeg/reader.go:762 +0x69 fp=0xc208041ed0 sp=0xc208041e88
main.main()
    jpeg.go:12 +0x132 fp=0xc208041f90 sp=0xc208041ed0

My repository is on commit 8ac129e.

@dvyukov dvyukov added this to the Go1.5 milestone Apr 8, 2015
@nigeltao nigeltao closed this in 2f98bac Apr 14, 2015
nigeltao added a commit that referenced this issue Jul 14, 2015
This rolls back most of golang.org/cl/8841, aka 2f98bac, and makes a
different fix. It keeps the TestTruncatedSOSDataDoesntPanic test
introduced by that other CL, which obviously still passes after this CL.

Fixes #11650, a regression (introduced by cl/8841) from Go 1.4.

The original cl/8841 changed the image/jpeg not to panic on an input
given in #10387. We still do not panic on that input, after this CL.

I have a corpus of over 160,000 JPEG images, a sample of a web crawl.
The image/jpeg code ran happily over that whole corpus both before and
after this CL, although that corpus clearly didn't catch the regression
in the first place.

This code was otherwise tested manually. I don't think that it's trivial
to synthesize a JPEG input that happens to run out of Huffman data at
just the right place. The test image attached to #11650 obviously has
that property, but I don't think we can simply add that test image to
the repository: it's 227KiB, and I don't know its copyright status.

I also looked back over the issue tracker for problematic JPEGs that
people have filed. The Go code, after this CL, is still happy on these
files in my directory:
issue2362a.jpeg
issue3916.jpeg
issue3976.jpeg
issue4084.jpeg
issue4259.jpeg
issue4291.jpeg
issue4337.jpeg
issue4500.jpeg
issue4705.jpeg
issue4975.jpeg
issue5112.jpeg
issue6767.jpeg
issue9888.jpeg
issue10133.jpeg
issue10357.jpeg
issue10447.jpeg
issue11648.jpeg
issue11650.jpeg

There were other images attached in the issue tracker that aren't
actually valid JPEGs. They failed both before and after this CL:
broken-issue2362b.jpeg
broken-issue6450.jpeg
broken-issue8693.jpeg
broken-issue10154.jpeg
broken-issue10387.jpeg
broken-issue10388.jpeg
broken-issue10389.jpeg
broken-issue10413.jpeg

In summary, this CL fixes #11650 and, after some automated and manual
testing, I don't think introduces new regressions.

Change-Id: I30b67036e9b087f3051d57dac7ea05fb4fa36f66
Reviewed-on: https://go-review.googlesource.com/12163
Reviewed-by: Rob Pike <r@golang.org>
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants