Skip to content

image/gif: check rejection of this gif #3565

Description

@gopherbot

by kballard:

The attached GIF is rendered successfully by both Chrome and Firefox. It probably has
some sort of corruption though, because Safari and Preview render it as corrupt (though
it still does render). GraphicConverter also renders it as corrupt, though in a
different fashion.

However, Go doesn't render it at all. It just returns the error "lzw: invalid
code".

Mac OS X 10.7.3, go version go1.

Attachments:

  1. GGUVZ.gif (9997027 bytes)

Activity

  1. rsc commented on Apr 25, 2012

    @rsc
    Contributor

    Comment 1:

    This could be a feature.  Now that I've looked at it in Chrome, I can't unsee that gif.

    Labels changed: added priority-later, removed priority-triage.

    Owner changed to @nigeltao.

    Status changed to Accepted.

  2. gopherbot commented on Apr 26, 2012

    @gopherbot
    ContributorAuthor

    Comment 3 by kballard:

    For the record, Safari/Preview on Mountain Lion render this GIF correctly now as well.
  3. rsc commented on Sep 12, 2012

    @rsc
    Contributor

    Comment 4:

    Labels changed: added go1.1maybe.

  4. rsc commented on Mar 12, 2013

    @rsc
    Contributor

    Comment 5:

    [The time for maybe has passed.]

    Labels changed: removed go1.1maybe.

  5. gopherbot commented on Mar 13, 2013

    @gopherbot
    ContributorAuthor

    Comment 6 by jeff.allen:

    I looked into this a bit. I found that when the invalid code is found:
    code 639
    litwidth 8
    width 12
    clear 256
    eof 257
    hi 90
    ovf 4096
    last 98
    Because 639 < 90 (d.hi), it fails. I'll trace through another gif decoder and try to
    see what they do when receiving a code like this.
  6. gopherbot commented on Mar 13, 2013

    @gopherbot
    ContributorAuthor

    Comment 7 by jeff.allen:

    Another GIF that causes Go problems:
    https://bug525326.bugzilla.mozilla.org/attachment.cgi?id=409291
    Don't know if it is the same problem yet, if not, I'll file a new bug.
  7. gopherbot commented on Mar 13, 2013

    @gopherbot
    ContributorAuthor

    Comment 8 by jeff.allen:

    I suspect this code in Webkit shows the way to making Go's gif decoder more lenient:
    http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageReader.cpp?rev=131831#L322
    More later.
  8. gopherbot commented on Mar 14, 2013

    @gopherbot
    ContributorAuthor

    Comment 9 by jeff.allen:

    A fix for this would involve making compress/lzw tolerant of incorrectly encoded
    streams. This seems like a bad idea in general. So a correct fix would need to add to
    the API of compress/lzw a boolean for "tolerate errors?".
    An API change to compress/lzw before Go 1.1 is not going to happen, so I think punting
    on this is the right call.
    The image in comment #7 is something else (issue #5050).
  9. gopherbot commented on Jul 4, 2013

    @gopherbot
    ContributorAuthor

    Comment 10 by jeff.allen:

    I think closing this as Won't Fix would be a good idea. Thanks.
  10. nigeltao commented on Jul 5, 2013

    @nigeltao
    Contributor

    Comment 11:

    Status changed to WorkingAsIntended.

  11. locked and limited conversation to collaborators on Jun 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions