#29482 [Opn]: imagecreatefrompng() throws fatal error (no warning) when opening broken images
ID: 29482
User updated by: troublegum at woltlab dot de
Reported By: troublegum at woltlab dot de
Status: Open
Bug Type: GD related
Operating System: Windows XP Professional
PHP Version: 5.0.0
New Comment:
# The mentioned image can be downloaded at:
http://webpm.woltlab.info/misc/bugs.php.net/29482_broken.png
# The appropriate testcase here:
http://webpm.woltlab.info/misc/bugs.php.net/29482_test1.php.txt
# A demo of this behavior (running php4.3.5 with gd 2.0.17
(compatible))
http://webpm.woltlab.info/misc/bugs.php.net/29482_test1.php
Previous Comments:
[2004-08-04 02:46:38] troublegum at woltlab dot de
I got a PNG image, that works perfectly fine with getimagesize() (means
the correct values for width and height are being extracted), but
imagecreatefrompng() fails to open it (with the above error message).
So this is definately not an option to sort out images, that can't be
open with imagecreatefrompng().
If it's not a bug, then it's certainly an improvement for future php
versions.
[2004-08-04 02:06:08] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Use the getimagesize() function to validate the image first
if you are unsure about the file's contents.
[2004-08-01 15:55:51] troublegum at woltlab dot de
Description:
imagecreatefrompng() should not throw a fatal error
when opening broken image files. Instead, a warning would be much more
useful.
The following code is useless as the scripts dies without any output.
If I remove the @, it throws the following message:
---
Fatal error: imagecreatefrompng() [function.imagecreatefrompng]:
gd-png: fatal libpng error: Invalid chunk length. in
F:\htdocs\bug\read.php on line 3
---
imagecreatefrompng throws a warning when opening files that are no png
files ('broken.png' is not a valid PNG file) but not when the image
file is a png image, bug is broken for whatever reason.
---
OS: Windows XP Professional
Apache: 2.0.49
PHP: 5.0.0 as apache module
GD: bundled (2.0.23 compatible)
PNG Support: enabled
Reproduce code:
---
?php
$filename = 'broken.png';
$imageResource = @imagecreatefrompng($filename);
if (!$imageResource) {
die('could not read ' . $filename . ' image');
}
else {
echo 'image ' . $filename . ' successfully read';
}
?
Expected result:
could not read broken.png image
Actual result:
--
Fatal error: imagecreatefrompng() [function.imagecreatefrompng]:
gd-png: fatal libpng error: Invalid chunk length. in
F:\htdocs\bug\read.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=29482edit=1
#29482 [Bgs-Opn]: imagecreatefrompng() throws fatal error (no warning) when opening broken images
ID: 29482
User updated by: troublegum at woltlab dot de
Reported By: troublegum at woltlab dot de
-Status: Bogus
+Status: Open
Bug Type: GD related
Operating System: Windows XP Professional
PHP Version: 5.0.0
New Comment:
I got a PNG image, that works perfectly fine with getimagesize() (means
the correct values for width and height are being extracted), but
imagecreatefrompng() fails to open it (with the above error message).
So this is definately not an option to sort out images, that can't be
open with imagecreatefrompng().
If it's not a bug, then it's certainly an improvement for future php
versions.
Previous Comments:
[2004-08-04 02:06:08] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Use the getimagesize() function to validate the image first
if you are unsure about the file's contents.
[2004-08-01 15:55:51] troublegum at woltlab dot de
Description:
imagecreatefrompng() should not throw a fatal error
when opening broken image files. Instead, a warning would be much more
useful.
The following code is useless as the scripts dies without any output.
If I remove the @, it throws the following message:
---
Fatal error: imagecreatefrompng() [function.imagecreatefrompng]:
gd-png: fatal libpng error: Invalid chunk length. in
F:\htdocs\bug\read.php on line 3
---
imagecreatefrompng throws a warning when opening files that are no png
files ('broken.png' is not a valid PNG file) but not when the image
file is a png image, bug is broken for whatever reason.
---
OS: Windows XP Professional
Apache: 2.0.49
PHP: 5.0.0 as apache module
GD: bundled (2.0.23 compatible)
PNG Support: enabled
Reproduce code:
---
?php
$filename = 'broken.png';
$imageResource = @imagecreatefrompng($filename);
if (!$imageResource) {
die('could not read ' . $filename . ' image');
}
else {
echo 'image ' . $filename . ' successfully read';
}
?
Expected result:
could not read broken.png image
Actual result:
--
Fatal error: imagecreatefrompng() [function.imagecreatefrompng]:
gd-png: fatal libpng error: Invalid chunk length. in
F:\htdocs\bug\read.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=29482edit=1
#29482 [NEW]: imagecreatefrompng() throws fatal error (no warning) when opening broken images
From: troublegum at woltlab dot de
Operating system: Windows XP Professional
PHP version: 5.0.0
PHP Bug Type: GD related
Bug description: imagecreatefrompng() throws fatal error (no warning) when opening
broken images
Description:
imagecreatefrompng() should not throw a fatal error
when opening broken image files. Instead, a warning would be much more
useful.
The following code is useless as the scripts dies without any output. If I
remove the @, it throws the following message:
---
Fatal error: imagecreatefrompng() [function.imagecreatefrompng]: gd-png:
fatal libpng error: Invalid chunk length. in F:\htdocs\bug\read.php on
line 3
---
imagecreatefrompng throws a warning when opening files that are no png
files ('broken.png' is not a valid PNG file) but not when the image file
is a png image, bug is broken for whatever reason.
---
OS: Windows XP Professional
Apache: 2.0.49
PHP: 5.0.0 as apache module
GD: bundled (2.0.23 compatible)
PNG Support: enabled
Reproduce code:
---
?php
$filename = 'broken.png';
$imageResource = @imagecreatefrompng($filename);
if (!$imageResource) {
die('could not read ' . $filename . ' image');
}
else {
echo 'image ' . $filename . ' successfully read';
}
?
Expected result:
could not read broken.png image
Actual result:
--
Fatal error: imagecreatefrompng() [function.imagecreatefrompng]: gd-png:
fatal libpng error: Invalid chunk length. in F:\htdocs\bug\read.php on
line 3
--
Edit bug report at http://bugs.php.net/?id=29482edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29482r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29482r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29482r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29482r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29482r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29482r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29482r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29482r=support
Expected behavior: http://bugs.php.net/fix.php?id=29482r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29482r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29482r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29482r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29482r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29482r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29482r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29482r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29482r=float
#28585 [NEW]: Query String ending with = leads to an empty $_GET array
From: troublegum at woltlab dot de
Operating system: Linux
PHP version: 4.3.6
PHP Bug Type: Scripting Engine problem
Bug description: Query String ending with = leads to an empty $_GET array
Description:
An Query String with = at the end deletes all other GET variables (empty
$_GET array).
Seems to be related to the following bugs, but as far as I can see this
server does not run Apache2 and suPHP (?).
http://bugs.php.net/bug.php?id=27740
http://bugs.php.net/bug.php?id=27861
---
'./configure' '--prefix=/opt/php-4.3.6' '--enable-bcmath' '--with-bz2'
'--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-discard-path'
'--with-layout=GNU' '--with-config-file-path=/opt/php-4.3.6/etc'
'--enable-calendar' '--with-curl' '--with-curlwrappers' '--enable-dbase'
'--enable-ftp' '--with-gettext' '-enable-exif' '--with-gd'
'--with-imap=/opt/imap-2004' '--with-imap-ssl=/usr' '--with-mime-magic'
'--with-mysql' '--with-ncurses' '--with-openssl=/usr' '--with-zip'
'--with-zlib' '--enable-dba=shared' '--with-db4' '--with-mssql'
---
Server API: CGI/FastCGI
magic_quotes_gpc = On
register_argc_argv = On
register_globals = On
variables_order = EGPCS
---
This problem occured on three of our client's server.
I can provide the complete output of phpinfo() if needed.
---
Reproduce code:
---
Open get.php?key=valfoo= in your browser.
Notice the = at the end.
-- get.php --
?php
var_dump($_GET);
?
Expected result:
array(2) {
[key]=
string(3) val
[foo]=
string(0)
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=28585edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28585r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28585r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28585r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28585r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28585r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28585r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28585r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28585r=support
Expected behavior: http://bugs.php.net/fix.php?id=28585r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28585r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28585r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28585r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28585r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28585r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28585r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28585r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28585r=float
#25849 [NEW]: regular expression on a UTF-8 string brakes this string
From: troublegum at woltlab dot de Operating system: Windows 2000 Pro SP4 PHP version: 4CVS-2003-10-13 (stable) PHP Bug Type: PCRE related Bug description: regular expression on a UTF-8 string brakes this string Description: I want to perform a regular expression on a string to replace all whitespace and commas with one single space. But If the string is a UTF-8 string, this string will be broken. I was not able to reproduce this behavior on my DebianLinux/Apache1.3.28/PHP4.3.3 Server. It occurs only on my Windows 2000 machine. Server: Apache 1.3.28 PHP as Apache Module php.ini Settings that diff from php.ini-dist: display_startup_errors = On magic_quotes_gpc = Off doc_root = c:/dev/htdocs extension_dir = c:/dev/php-4.3.3dev/extensions/ upload_max_filesize = 6M extension=php_bz2.dll extension=php_gd2.dll extension=php_gettext.dll extension=php_mbstring.dll extension=php_pdf.dll extension=php_sockets.dll session.save_path = c:/winnt/temp/php4_sessions session.use_trans_sid = 1 Reproduce code: --- see http://webpm.woltlab.info/phpgroup/pcre_utf8.phps Please read also the comments on the regular expression I can provide more strings that will fail if it is necessary. Expected result: 1) CoeurDéjà Pris 2) Coeur Déjà Pris Actual result: -- 1) CoeurDéjà Pris 2) Coeur Déj? Pris -- Edit bug report at http://bugs.php.net/?id=25849edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25849r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25849r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25849r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25849r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25849r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25849r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25849r=support Expected behavior: http://bugs.php.net/fix.php?id=25849r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25849r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25849r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25849r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25849r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25849r=dst IIS Stability: http://bugs.php.net/fix.php?id=25849r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25849r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25849r=float
#24503 [NEW]: writing newlines and multiline comments produces strange results
From: troublegum at woltlab dot de
Operating system: Windows 2000 Professional
PHP version: 5CVS-2003-07-04 (dev)
PHP Bug Type: Filesystem function related
Bug description: writing newlines and multiline comments produces strange results
Description:
OS: Windows 2000 Professional
Server: Apache 1.3.27
PHP: Version 5.0.0b2-dev (cvs snapshot 07-04-2003) as apache module
I wanted to create .php files dynamically.
I tested the following test-script:
Reproduce code:
---
?php
$variables = array(1,2,3,4,5,6);
$comments['comment1'] = test1;
$comments['comment2'] = test2;
$comments['comment3'] = test3;
$fp = fopen(./file.php, w);
//fwrite($fp, ?php\n/*\ncomment1: .$comments['comment1'].\ncomment2:
.$comments['comment2'].\ncomment3: .$comments['comment3'].\n*/\n\n);
fwrite($fp, ?php
/*
comment1: .$comments['comment1'].
comment2: .$comments['comment2'].
comment3: .$comments['comment3'].
*/
);
// write variables to file
fwrite($fp, \n);
foreach($variables as $key=$val) {
fwrite($fp, \$var_.$key. = \.addcslashes($val,$\\\).\;\n);
}
fwrite($fp, \n?);
// close file and show results
fclose($fp);
echo file writtenhr /\n;
show_source(./file.php);
?
Expected result:
The expected content of the file ./file.php should be the following:
?php
/*
comment1: test1
comment2: test2
comment3: test3
*/
$var_0 = 1;
$var_1 = 2;
$var_2 = 3;
$var_3 = 4;
$var_4 = 5;
$var_5 = 6;
?
Actual result:
--
Instead, the content which is written to ./file.php is the following:
?php
/*
comment1: test1
comment2: test2
comment3: test3
*
$var_0 = 1;
$var_1 = 2;
$var_2 = 3;
$var_3 = 4;
$var_4 = 5;
$var_5 = 6;
?
So it is not surprising that show_source for this file results in Warning:
Unterminated comment starting line 2 in c:\dev\htdocs\php5\fw.php on line
21
--
Edit bug report at http://bugs.php.net/?id=24503edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24503r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24503r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24503r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24503r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24503r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24503r=support
Expected behavior: http://bugs.php.net/fix.php?id=24503r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24503r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24503r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24503r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24503r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24503r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24503r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24503r=gnused
