GNOME Bugzilla – Bug 695513
GIF: too much input data, ignoring extra
Last modified: 2013-03-12 07:47:56 UTC
Created attachment 238463 [details] GIF that triggers the bug Here is a small GIF (also attached): 00000000 47 49 46 38 39 61 02 00 02 00 f0 00 31 00 00 00 |GIF89a......1...| 00000010 01 01 01 21 f9 04 04 00 00 00 00 2c 00 00 00 00 |...!.......,....| 00000020 02 00 02 00 00 02 02 44 5c 00 3b |.......D\.;| 0000002b The compressed image data is the two bytes 44 5c and consists of the codes 4(clear), 0, 1, 6, 5(end), packed into 3-bit fields. Loading this GIF into Gimp produces this message on stderr: GIF: too much input data, ignoring extra... In this case it is a false positive. The reason is the final 'return code & 255' in LZWReadByte(). This only runs when GetCode() has returned -1 to indicate the end of the image data. In this case a negative value should also be returned from LZWReadByte(), to indicate the end of the data. Other parts of LZWReadByte() do this and it's what ReadImage() expects. ANDing with 255 means that 255 is instead returned to ReadImage(), resulting in the message above. Suggested fix: --- a/plug-ins/common/file-gif-load.c +++ b/plug-ins/common/file-gif-load.c @@ -862,7 +862,7 @@ LZWReadByte (FILE *fd, return (*--sp) & 255; } - return code & 255; + return -1; } static gint32
This is a bug in our code. GIMP doesn't correctly parse a 2x2 1-bit checkerboard pattern GIF image that it saved. The patch suggested in comment #0 is an incorrect fix. GetCode() has the bug, where it incorrectly thinks it has run out of input bits. With a fixed GetCode(), LZWReadByte() correctly parses the following End of Information code. I'll attach a patch shortly.
Pushed to master branch: commit f86655bb1fcf356524c1894096f4866633cc7666 Author: Mukund Sivaraman <muks@banu.com> Date: Tue Mar 12 13:08:14 2013 +0530 file-gif-load: Fix incorrect out-of-input-bits condition (#695513) GetCode() erroneously assumes that it has run out of input bits, because it's off by 1 in its size calculation. At the end of the block, if the End-of-Information code is exactly at the block boundary, it calculates that it needs to read an extra bit, and tries to read beyond the end of the block. It fails then, and the End-of-Information code is not processed, and other warnings/errors are generated. Pushed to gimp-2-8 branch: commit af88c4a6c943eb5db04fa3eea00befb7442a1e58 Author: Mukund Sivaraman <muks@banu.com> Date: Tue Mar 12 13:08:14 2013 +0530 file-gif-load: Fix incorrect out-of-input-bits condition (#695513) GetCode() erroneously assumes that it has run out of input bits, because it's off by 1 in its size calculation. At the end of the block, if the End-of-Information code is exactly at the block boundary, it calculates that it needs to read an extra bit, and tries to read beyond the end of the block. It fails then, and the End-of-Information code is not processed, and other warnings/errors are generated. (cherry picked from commit f86655bb1fcf356524c1894096f4866633cc7666) Resolving as FIXED, milestone 2.8.