Fatal error reported for recoverable error

Bug #39780	Fatal error reported for recoverable error
Submitted:	2006-12-08 18:25 UTC	Modified:	2006-12-10 01:41 UTC
From:	pz at mysqlperformanceblog dot com	Assigned:	pajoye (profile)
Status:	Closed	Package:	GD related
PHP Version:	5.2.0	OS:	Linux
Private report:	No	CVE-ID:	None

[2006-12-08 18:25 UTC] pz at mysqlperformanceblog dot com

Description:
------------
Getting the following error:

PHP Fatal error:  imagecreatefromstring(): gd-png:  fatal libpng error: IDAT: CRC error in 

Note this is FATAL error for  what should have been simply false result code from the function. 

Reproduce code:
---------------
imagecreatefromstring(file_get_contents("http://www.bennygold.com/uploaded_images/crack_line1-793571.gif"));



Expected result:
----------------
FALSE returned from the function with warning printed 

Actual result:
--------------
Script is terminated with fatal error

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2006-12-08 18:33 UTC] tony2001@php.net

Pierre, is E_ERROR really required in this case?

[2006-12-08 20:02 UTC] iliaa@php.net

You really should be using the imagecreatefromgif() function 
in this instance. The URL with an image seems to be down, can 
you provide a working URL for the file please.

[2006-12-08 20:02 UTC] pajoye@php.net

Please provide a working link to the image.

[2006-12-08 20:17 UTC] pz at mysqlperformanceblog dot com

Here is the copy of the image:

http://www.mysqlperformanceblog.com/files/misc/1.gif

It is actually PNG image even if it has gif extension. 

Regarding what function I should use this is not the point - I created simple test case to illustrate problem. In the real script it is used completely different way.

[2006-12-08 21:47 UTC] pajoye@php.net

The image is invalid. Either the buffer is incomplete or the CRC is wrong. You can try with different image viewers, the lower part will miss, more or less depending on how tolerant is the reader.

It is also important to tell us directly what you provide, like a png named as gif, it minimizes the time we need to test or analyze your problem. If you used imagecreatefromgif it will simply fail, so yes, which functions you use to open this image is important.

I will check if returning false is a safe choice. It should be but I need to test it first.

[2006-12-09 09:59 UTC] pz at mysqlperformanceblog dot com

Sure image is invalid.  This is not the point. 

The function is specified as it ether returns image or FALSE on error. If it also can in case of error terminate script execution or format the hard drive it is better to be specified in docs :) 

Now regarding what I provide - the name of the file does not matter in this case as image is created from memory buffer.  I just gave you the real image on which my thumbnail generation script  failed. 

Out of few millions of images processed many were malformed etc but in most cases PHP handles it correctly by reporting FALSE and printing appropriate warning.  So at least this behavior is inconsistent.

[2006-12-09 11:09 UTC] pajoye@php.net

"Sure image is invalid.  This is not the point. "

My point is to have the relelevant informations in the report instead of letting us wondering what you are trying to do or achieve. And it is a valid requirement.

"The function is specified as it ether returns image or FALSE on error."

As I just said, I have to test further to see if it is safe to continue the script execution.

[2006-12-09 11:59 UTC] pajoye@php.net

Ok, I found the problem.

It requires to add more jmp points in the png implementation. We have only one now, forcing us to bail out immediately if an error occurred after the image initialization (when the png headers are correct but not the data/CRC).

I'm not sure if I can make it for 5.2.x but 6.x will return false.

[2006-12-10 01:41 UTC] pajoye@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.