|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Status: Closed Package: GD related
PHP Version: 5.2.0 OS: Linux
Private report: No CVE-ID:
 [2006-12-08 18:25 UTC] pz at mysqlperformanceblog dot com
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:

Expected result:
FALSE returned from the function with warning printed 

Actual result:
Script is terminated with fatal error


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-12-08 18:33 UTC]
Pierre, is E_ERROR really required in this case?
 [2006-12-08 20:02 UTC]
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]
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:

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]
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]
"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]
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-09 12:05 UTC]
Please try with this patch (against 5.2 cvs):

It raises (yes many ;) warnings instead of fatal errors.

Ilia, is it ok for 5.2?
 [2006-12-10 01:41 UTC]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2015 The PHP Group
All rights reserved.
Last updated: Mon Nov 30 22:01:38 2015 UTC