-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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/gif: panics for several GIFs #5401
Labels
Comments
These are actually two different issues: A) crash1.gif has an no palette information and thus the decoded image has a zero length Palette and image.Palletted.At returns a nil color.Color in this case. See http://tip.golang.org/src/pkg/image/image.go?s=22798:22839#L814 The final panic happens in http://tip.golang.org/src/pkg/image/draw/draw.go?s=14011:14050#L473 which does not check on this nil value. image.Paletted is the only image type which returns a nil color.Color in a call to At(x,y). Possible fixes: Either check for nil Color during draw or have image.Paletted.At return a color.RGBA{} default value like in the case of (x,y) not in the image bounds. B) chrash2.gif has a palette with 128 entries but pixel (0,35) references color no 255 and thus panics in http://tip.golang.org/src/pkg/image/image.go?s=22929:22948#L814 It could be argued, that the gif is malformed and decoding should fail. It seems that other tools (checked GIMP only) handle both cases gracefully by substituting black in both cases above. |
Labels changed: added priority-soon, removed priority-triage. Owner changed to @nigeltao. Status changed to Accepted. |
I'd be willing to work on this (especially with the great diagnosis from dr.volker, thanks!) The last time we were looking at fixing a problem like this (issue #3565) I decided it was better to not fix the bug and continue rejecting the GIF because the breakage was in its LZW encoding. This time, it seems reasonable to accept these images because while they are clearly invalid, the fix is within image/gif/*.go and the behavior of adding a black pixel in is not very controversial. Nigel, please give a "pre-LGTM" before I start on this. :) |
I'd prefer to reject invalid images (as an error) instead of implying black pixels. I think both cases should be fixed in image/gif instead of image or image/draw. Specifically, gif.DecodeXxx should return an error where it currently allows returning an image.Paletted with (A) an empty Palette or (B) a Pix element >= len(Palette). The second check (B) can be elided if len(Palette) == 255. The spec (http://www.w3.org/Graphics/GIF/spec-gif89a.txt) section 22 "Table Based Image Data" says that "Each index must be within the range of the size of the active color table, starting at 0." |
This issue was closed by revision 8192017. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Attachments:
The text was updated successfully, but these errors were encountered: