After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753605 - Inconsistent error handling with jpeg file (new_from_file vs new_from_file_at_size)
Inconsistent error handling with jpeg file (new_from_file vs new_from_file_at...
Status: RESOLVED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2015-08-14 06:42 UTC by Christoph Reiter (lazka)
Modified: 2017-12-06 08:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
image (78.96 KB, image/jpeg)
2015-08-14 06:42 UTC, Christoph Reiter (lazka)
  Details
tests: Add test for bug 753605 (103.39 KB, patch)
2017-12-05 01:24 UTC, Bastien Nocera
none Details | Review
tests: Add test for bug 753605 (103.41 KB, patch)
2017-12-05 05:43 UTC, Bastien Nocera
committed Details | Review
jpeg: Use a temporary variable (1.53 KB, patch)
2017-12-05 05:43 UTC, Bastien Nocera
committed Details | Review
jpeg: Fix loading truncated incremental inputs (2.12 KB, patch)
2017-12-05 05:43 UTC, Bastien Nocera
committed Details | Review

Description Christoph Reiter (lazka) 2015-08-14 06:42:35 UTC
Created attachment 309240 [details]
image

The attached image loads successfully when using gdk_pixbuf_new_from_file but fails when using gdk_pixbuf_new_from_file_at_size with the following error:

gdk-pixbuf-error-quark: Error interpreting JPEG image file (Application transferred too few scanlines) (0)

There seems to be something wrong with the file as imagemagick complains with "Premature end of JPEG file", but the difference in error handling seems weird.
Comment 1 Bastien Nocera 2017-12-05 01:24:25 UTC
Created attachment 364966 [details] [review]
tests: Add test for bug 753605
Comment 2 Bastien Nocera 2017-12-05 01:34:34 UTC
This might be a case of libjpeg sucking, but I'm not certain.

When going down the gdk_pixbuf_new_from_file_at_size() path, we just pass a FILE * to libjpeg, and it does the work of loading the data as it needs.

When using gdk_pixbuf_new_from_file_at_size(), we open the FILE * ourselves, and read it byte-by-byte, and checking on libjpeg to see if it managed to load it. This is when it fails.
Comment 3 Bastien Nocera 2017-12-05 01:48:31 UTC
Misread the code, it's loading 64kB by 64kB.
Comment 4 Bastien Nocera 2017-12-05 05:43:12 UTC
Created attachment 364996 [details] [review]
tests: Add test for bug 753605
Comment 5 Bastien Nocera 2017-12-05 05:43:17 UTC
Created attachment 364997 [details] [review]
jpeg: Use a temporary variable

To avoid using context->cinfo all the time.
Comment 6 Bastien Nocera 2017-12-05 05:43:23 UTC
Created attachment 364998 [details] [review]
jpeg: Fix loading truncated incremental inputs

When loading incremental inputs through a GdkPixbufLoader, we didn't
have any code replicating the stdio_fill_input_buffer() hack to finish
up a file.

Adding those markers makes libjpeg think that the file was at least
closed properly, and will attempt decoding.
Comment 7 Bastien Nocera 2017-12-05 05:44:24 UTC
The bad news is that the file is broken. The good news is that we can cover it up, and you won't notice it :)

Attachment 364996 [details] pushed as 73855e7 - tests: Add test for bug 753605
Attachment 364997 [details] pushed as fa472af - jpeg: Use a temporary variable
Attachment 364998 [details] pushed as b99e04f - jpeg: Fix loading truncated incremental inputs
Comment 8 Christoph Reiter (lazka) 2017-12-06 08:33:26 UTC
Thank you!