http://bugs.winehq.org/show_bug.cgi?id=59887 --- Comment #4 from mcmarius@gmx.net --- ## ROOT CAUSE: full LZW table / deferred-clear boundary in DGifDecompressLine Instrumenting the LZW stream of every frame shows that **frame 38 is the only frame whose code table fills to all 4096 entries** (then continues with 12-bit codes before a clear). Every other frame emits a clear code before the table fills, so they never exercise this path. This is the GIF "deferred clear code" region of the LZW stream. The error comes from Wine's bundled GIF LZW decompressor, `DGifDecompressLine` in `dlls/windowscodecs/ungif.c`, reached via `CommonDecoder_Initialize` → `DGifSlurp`. The relevant code (wine master): ```c #define LZ_MAX_CODE 4095 ... if (Prefix[CrntCode] == NO_SUCH_CODE) { if (CrntCode == Private->RunningCode - 2) { CrntPrefix = LastCode; /* KwKwK / just-defined-code case */ Suffix[Private->RunningCode - 2] = ... DGifGetPrefixChar(Prefix, LastCode, ClearCode); } else { return GIF_ERROR; /* <-- fails here */ } } else CrntPrefix = CrntCode; ``` and the growth guard in `DGifDecompressInput`: ```c if (Private->RunningCode < LZ_MAX_CODE + 2 && ++Private->RunningCode > Private->MaxCode1 && Private->RunningBits < LZ_BITS) { Private->MaxCode1 <<= 1; Private->RunningBits++; } ``` When the table fills, the decoder stops defining new codes. If its `RunningCode` state is off by one entry from the encoder's at that fill boundary, a following code references an entry the decoder has not defined → `Prefix[CrntCode] == NO_SUCH_CODE`, not the KwKwK case → `return GIF_ERROR`, which fails the whole image. Windows' decoder accepts the same stream. → Fix direction: correct the entry-add / RunningCode bookkeeping at the full-table / deferred-clear boundary so a valid code at LZ_MAX_CODE is not treated as undefined. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.