php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73116 imagecreatefromjpeg fatal error on empty file
Submitted: 2016-09-19 22:00 UTC Modified: 2017-09-10 21:15 UTC
Votes:11
Avg. Score:4.5 ± 0.7
Reproduced:10 of 10 (100.0%)
Same Version:6 (60.0%)
Same OS:4 (40.0%)
From: chupaka at gmail dot com Assigned: cmb (profile)
Status: Closed Package: GD related
PHP Version: 5.6.26 OS: Fedora 24
Private report: No CVE-ID: None
 [2016-09-19 22:00 UTC] chupaka at gmail dot com
Description:
------------
When using imagecreatefromjpeg on empty file, PHP generates Fatal error instead of warning, so it's impossible to handle the error.

Test script:
---------------
<?php

touch('emptyfile');

imagecreatefromjpeg('notexist');
imagecreatefromjpeg('emptyfile');

echo "Continue with error handling";


Expected result:
----------------
PHP Warning:  imagecreatefromjpeg(notexist): failed to open stream: No such file or directory in /var/www/test.php on line 5
PHP Warning:  imagecreatefromjpeg(emptyfile): gd-jpeg: JPEG library reports unrecoverable error: Empty input file in /var/www/test.php on line 6
Continue with error handling

Actual result:
--------------
PHP Warning:  imagecreatefromjpeg(notexist): failed to open stream: No such file or directory in /var/www/test.php on line 5
PHP Fatal error:  imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error: Empty input file in /var/www/test.php on line 6

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-09-24 14:33 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2016-09-24 14:33 UTC] cmb@php.net
I can't reproduce the fatal PHP error.

Which libgd and libjpeg version do you use? And is this really
about PHP 5.6.26?
 [2016-09-24 15:48 UTC] chupaka at gmail dot com
-Status: Feedback +Status: Assigned
 [2016-09-24 15:48 UTC] chupaka at gmail dot com
[root@new-info ~]# dnf list installed php gd libjpeg-turbo
Last metadata expiration check: 1:16:50 ago on Sat Sep 24 17:28:15 2016.
Installed Packages
gd.x86_64                       2.2.3-2.fc24              @updates
libjpeg-turbo.x86_64            1.5.0-2.fc24              @updates
php.x86_64                      5.6.26-1.fc24             @updates-testing
[root@new-info ~]#
 [2016-09-24 21:52 UTC] cmb@php.net
-Status: Assigned +Status: Verified -Assigned To: cmb +Assigned To: remi
 [2016-09-24 21:52 UTC] cmb@php.net
Thanks for the version information.

I can reproduce the behavior in a very similar Fedora 24
environment, but not with the original libs, so this might be a
Fedora package issue.

Remi, could you please have a look at this issue?
 [2016-10-05 11:15 UTC] eforcems at o2 dot pl
Hi, this is not only Fedora issue. I have the same issue on Kubuntu 16.04 from this repo http://ppa.launchpad.net/ondrej/php/ubuntu/
 [2016-10-05 11:30 UTC] cmb@php.net
-Assigned To: remi +Assigned To: ondrej
 [2016-10-05 11:30 UTC] cmb@php.net
Ondřej, can you have a look at this issue please?
 [2016-10-05 11:57 UTC] ondrej@php.net
Seems the usual dichotomy between bundled and standalone gd library in:

```
 /* Called by the IJG JPEG library upon encountering a fatal error */
 static void fatal_jpeg_error(j_common_ptr cinfo)
 {
        jmpbuf_wrapper *jmpbufw;
-       char buffer[JMSG_LENGTH_MAX];
 
-       (*cinfo->err->format_message)(cinfo, buffer);
-       gd_error_ex(GD_ERROR, "gd-jpeg: JPEG library reports unrecoverable error: %s", buffer);
+       php_gd_error("gd-jpeg: JPEG library reports unrecoverable error: ");
+       (*cinfo->err->output_message) (cinfo);
 
        jmpbufw = (jmpbuf_wrapper *)cinfo->client_data;
        jpeg_destroy(cinfo);
 
        if(jmpbufw != 0) {
                longjmp(jmpbufw->jmpbuf, 1);
-               gd_error_ex(GD_ERROR, "gd-jpeg: EXTREMELY fatal error: longjmp returned control; terminating\n");
+               php_gd_error_ex(E_ERROR, "gd-jpeg: EXTREMELY fatal error: longjmp returned control; terminating");
        } else {
-               gd_error_ex(GD_ERROR, "gd-jpeg: EXTREMELY fatal error: jmpbuf unrecoverable; terminating\n");
+               php_gd_error_ex(E_ERROR, "gd-jpeg: EXTREMELY fatal error: jmpbuf unrecoverable; terminating");
        }
 
        exit(99);
 }
```

Different error handling in bundled GD library.  Nothing packagers can do about.
 [2016-10-05 11:57 UTC] ondrej@php.net
-Assigned To: ondrej +Assigned To: cmb
 [2016-10-05 12:30 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 [2016-10-05 12:30 UTC] cmb@php.net
Even with an "official" external libgd I couldn't reproduce the
issue, so this might be a packaging issue.

I think it has to do with commit 6cb75fb1[1] which is supposed to
be available as of PHP 5.6.25.

[1] <https://github.com/php/php-src/commit/6cb75fb1>
 [2016-10-05 12:56 UTC] chupaka at gmail dot com
Rolled back to 5.6.22 - and it works without fatal error:

# php -v
PHP 5.6.22 (cli) (built: May 26 2016 13:54:01)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
# php test.php
PHP Warning:  imagecreatefromjpeg(notexist): failed to open stream: No such file or directory in /test.php on line 5
PHP Unknown error:  imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error: Empty input file in Unknown on line 0
PHP Warning:  imagecreatefromjpeg(): 'emptyfile' is not a valid JPEG file in /test.php on line 6
Continue with error handling
#
 [2016-10-05 14:52 UTC] cmb@php.net
-Assigned To: +Assigned To: cmb
 [2016-10-05 14:52 UTC] cmb@php.net
> PHP Unknown error:  imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error: Empty input file in

Exactly that issue (namely that the severity of GD errors has not
been mapped correctly to PHP errors) has been fixed as of PHP
5.6.25.

Maybe this issue is related to the libjpeg version/variant. I'll
have another look at it.
 [2016-10-18 15:18 UTC] cmb@php.net
> Seems the usual dichotomy between bundled and standalone gd
> library in:
> […]

There shouldn't be a problem, as gd_error() is supposed to forward
to php_gd_error() anyway[1]. I've nonetheless improved that
recently[2].

Anyhow, with regard to the actual issue I'm at a loss. It seems
that libjpeg-turbo always raises a fatal error if it detects empty
input files[3]. I can't reproduce this, however, with "plain"
libjpeg-turbo builds.

[1] <https://github.com/php/php-src/blob/PHP-7.0.12/ext/gd/gd.c#L1054-L1056>
[2] <http://git.php.net/?p=php-src.git;a=commit;h=432e16cb>
[3] <https://github.com/libjpeg-turbo/libjpeg-turbo/search?utf8=%E2%9C%93&q=JERR_INPUT_EMPTY>
 [2016-10-18 15:19 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 [2016-11-16 14:24 UTC] mail at adrian-kirchner dot com
Are there chances, that your patch [1] gets merged into the 5.6-branch so it finds its way into distributions like Debian?

On Debian the problem still exists because it has only the patch [2] which does not work with shared libgd [3].

```
# php -v
PHP 5.6.27-0+deb8u1 (cli) (built: Oct 15 2016 15:53:28)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

# touch test.jpg
# php -r "imagecreatefromjpeg('test.jpg');"
PHP Fatal error:  imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error: Empty input file in Command line code on line 1
```

[1] <http://git.php.net/?p=php-src.git;a=commit;h=432e16cb>
[2] <http://git.php.net/?p=php-src.git;a=commitdiff;h=6cb75fb1e8208d79f58351340923059d0d077ee6;hp=8b905e337c0e88ec66a25e4b7dbbd5c87279ea75>
[3] <http://sources.debian.net/src/php5/5.6.27%2Bdfsg-0%2Bdeb8u1/ext/gd/gd.c/#L72>
 [2016-11-16 15:05 UTC] cmb@php.net
It occurs to me that patch [1] wouldn't solve the issue, but
rather libgd would have to fixed, see
<https://github.com/libgd/libgd/issues/338>.
 [2017-09-10 21:15 UTC] cmb@php.net
-Status: Verified +Status: Closed -Assigned To: +Assigned To: cmb
 [2017-09-10 21:15 UTC] cmb@php.net
<https://github.com/libgd/libgd/issues/338> has recently been
fixed, so I'm closing this ticket.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 10 08:01:27 2024 UTC