#36792 [Fbk-Opn]: Apache crashing while executing some scripts
ID: 36792 User updated by: webmaster at zloba dot ath dot cx Reported By: webmaster at zloba dot ath dot cx -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 4.4.2 New Comment: After some tracing I founded that the problem is caused by the installer.php here: http://zloba.ath.cx/lotgd-installer.zip There are many cut-offs of code and this installer crashes without any arguments passed (because actually there aren't any argument checks). The error logged is the same as I pasted above. I left only the libraries and common.php too, but it is still very hard job to trace the problem, there are too much includes. I will continue working to realize which instruction(s) cause the crash of Apache. Previous Comments: [2006-03-19 22:36:21] [EMAIL PROTECTED] If it's possible, please provide short and complete reproduce code. [2006-03-19 22:30:09] webmaster at zloba dot ath dot cx The script crashes here: http://your.server/lotgd/installer.php?stage=1c=1-232014 (stage 2 - license agreement) installer.php has many includes so here is the full source code (the official side requires registration in order to download it): http://zloba.ath.cx/lotgd-1.0.6.tar.gz It doesn't require any additional modules of PHP to test the installer, so I think there shouldn't be any problems. I forgot to quote the error log: [Sun Mar 19 23:20:22 2006] [notice] Parent: child process exited with status 3221225477 -- Restarting. The status is always the same. [2006-03-19 22:01:21] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-03-19 21:59:38] webmaster at zloba dot ath dot cx Description: Apache (2.0.55) crashes in certain situations. Tried running LoTGD (http://dragonprime.net/) and the httpd crashed. Other scripts have crashed too. It says that the actual problem was from php4ts.dll and the problem is when scripts are run, so I think it's PHP bug. The dump of Apache (over 20MB unzipped!) is here: http://zloba.ath.cx/dumps.zip Reproduce code: --- LoTGD 1.0.6 installation scripts from http://dragonprime.net/ Expected result: Have the software installed Actual result: -- The HTTPD crashed -- Edit this bug report at http://bugs.php.net/?id=36792edit=1
#30218 [Com]: xsltApplyOneTeplate warning c'se nbsp;
ID: 30218 Comment by: ross at golder dot org Reported By: robert dot dahlin at jerntorget dot se Status: No Feedback Bug Type: XSLT related Operating System: Linux Slackware 2.6 PHP Version: 5.0.1 New Comment: Same here, PHP 5.0.5-2ubuntu1.2 (cli). Simple test case: ?php $xsl = ?xml version=\1.0\? !DOCTYPE xsl:stylesheet [!ENTITY whatever \#163;\] xsl:stylesheet version=\1.1\ xmlns:xsl=\http://www.w3.org/1999/XSL/Transform\; xsl:template match=\test\ pwhatever;xsl:value-of select=\.\//p pwhatever;xsl:apply-templates//p pwhatever;No problem/p /xsl:template /xsl:stylesheet ; $xml = ?xml version=\1.0\? testSomething/test ; $xmldom = DOMDocument::loadXML($xml); $xsldom = DOMDocument::loadXML($xsl); $xsltproc = new XSLTProcessor(); $xsltproc-importStylesheet($xsldom); echo $xsltproc-transformToXML($xmldom); ? Previous Comments: [2005-09-15 10:35:38] chabotc at xs4all dot nl We have the same problem here. The problem happens when a NBSP is situated before a xsl:if statement. Also in the output, even if you enclose the nbsp; with a span/span, there's no nbsp;'s or spaces.. We've tried defining !ENTITY nbsp #32; (or #160) but to no avail, we get the same xsltApplyOneTemplate: if was not compiled in error. This is with libxml2-2.6.22, libxslt-1.1.15-1 and php-5.0.4 on a fully up to date RedHat Enterprise Server 4. From phpinfo: Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies with Zend Extension Manager v1.0.8, Copyright (c) 2003-2005, by Zend Technologies with Zend Optimizer v2.5.8, Copyright (c) 1998-2004, by Zend Technologies with Zend Debugger v4.0.0, Copyright (c) 1999-2005, by Zend Technologies libXML support active libXML Version 2.6.22 libXML streams enabled XSL enabled libxslt Version 1.1.15 libxslt compiled against libxml Version 2.6.22 EXSLT enabled libexslt Version1.1.15 This does pose quite a problem to us for our upgrade path to php5, we used sablotron's xslt under php4 for our products, and ofcourse the html templates do contain quite a few nbsp's.. [2004-10-07 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2004-09-29 18:03:02] [EMAIL PROTECTED] Currently can't reproduce that, can you please upgrade to a recent libxml2/libxslt version and see if the problem persists? [2004-09-28 11:06:47] robert dot dahlin at jerntorget dot se XML and XSL example. The same thing happens when i use for example raquo; but if spanraquo;/span it does not appear either. If i wan't it to be visible i have to use #187; instead, but that's not OK. Here is an example that does not work for me, I just get the following warnings. Warning: xsltApplyOneTemplate: apply-templates was not compiled in xsltest.php on line 20 Warning: xsltApplyOneTemplate: apply-templates was not compiled in xsltest.php on line 20 //Robert Dahlin --- XML: - ?xml version=1.0 encoding=UTF-8? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;[ !ENTITY nbsp #160;] document data sessid/sessid oid/oid object type=html id=12345 pageOID=4![CDATA[TESTSTRING]]/object /data /document - XSL: - !DOCTYPE wasp [ !ENTITY lt #38;#60; !ENTITY gt #62; !ENTITY amp#38;#38; !ENTITY apos #39; !ENTITY quot #34; !ENTITY nbsp #32; !ENTITY raquo #187; !ENTITY deg#176; !ENTITY space ] xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:include href='/www/xsl-includes/menu.xsl'/ xsl:template match=/ xsl:apply-templates select=document/ /xsl:template xsl:template match=document html xsl:apply-templates select=data/ /html /xsl:template xsl:template match=data body bgcolor=#FF marginwidth= topmargin= marginheight= leftmargin= table border=0 background= width=100% cellspacing=0 cellpadding=0 trtd style=raquo;xsl:apply-templates select=object//td/tr trtd style=nbsp;xsl:apply-templates select=object//td/tr /table /body /xsl:template
#36788 [Opn-Fbk]: prepared statements broken
ID: 36788
Updated by: [EMAIL PROTECTED]
Reported By: bubblenut at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux 2.6.12 (Kubuntu)
PHP Version: 5.1.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-03-20 00:55:22] bubblenut at gmail dot com
Ahh, sorry, little typo, OK it looks like it's just in the parameter
insertion then (do I need to start a new bug report?)
Revised Code
?php
//phpinfo();
$db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=?);
$stmt-bindValue(1, 1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
foreach($db-query(SELECT id FROM recipe WHERE id=1) as $res) {
var_dump($res);
}
Expected Result
---
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Actual Result
-
array(0) {
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
[2006-03-20 00:40:03] [EMAIL PROTECTED]
It still doesn't work without execute() after prepare().
And after adding this execute() call, it works _just fine_.
[2006-03-20 00:29:10] bubblenut at gmail dot com
OK, so change the fetches for fetchAlls an alter the expected and
actual results acordingly (yes I have tested with those methods). The
bug still stands. Prepared statements are not working for this install.
[2006-03-19 22:47:39] [EMAIL PROTECTED]
This is what I get with your code (and this is expected):
---
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 2014 Cannot execute queries while
other unbuffered queries are active. Consider using
PDOStatement::fetchAll(). Alternatively, if your code is only ever
going to run against mysql, you may enable query buffering by setting
the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.' in /tmp/1.php:11
Stack trace:
#0 /tmp/1.php(11): PDO-prepare('SELECT id FROM ...')
#1 {main}
thrown in /tmp/1.php on line 11
---
[2006-03-19 16:00:20] bubblenut at gmail dot com
Description:
It works fine on my Debian Sarge machine but on my Kubuntu laptop it
fails.
I have tried it with the follwing releases
PHP 5.1.0 CVS
PHP 5.1.1
PHP 5.1.2
PHP 5.1.2 CVS
Reproduce code:
---
?php
//phpinfo();
$db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=?);
$stmt-bindValue(1, 1);
$stmt-execute();
$res = $stmt-fetch();
var_dump($res);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=1);
$res = $stmt-fetch();
var_dump($res);
foreach($db-query(SELECT id FROM recipe WHERE id=1) as $res) {
var_dump($res);
}
Expected result:
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Actual result:
--
bool(false)
bool(false)
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
--
Edit this bug report at http://bugs.php.net/?id=36788edit=1
#36788 [Fbk-Opn]: prepared statements broken
ID: 36788
User updated by: bubblenut at gmail dot com
Reported By: bubblenut at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux 2.6.12 (Kubuntu)
PHP Version: 5.1.2
New Comment:
I get the following error when doing the make install
SECURITY ERROR: PHP_Archive::mapPhar can only be called from within the
phar that initiates itInstalling PDO headers:
/usr/local/php/include/php/ext/pdo/
Also earlier in the make install I get the following libtool warning
libtool: install: warning: remember to run `libtool --finish
/usr/local/src/php5.1-200603200930/libs'
Previous Comments:
[2006-03-20 11:09:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-20 00:55:22] bubblenut at gmail dot com
Ahh, sorry, little typo, OK it looks like it's just in the parameter
insertion then (do I need to start a new bug report?)
Revised Code
?php
//phpinfo();
$db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=?);
$stmt-bindValue(1, 1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
foreach($db-query(SELECT id FROM recipe WHERE id=1) as $res) {
var_dump($res);
}
Expected Result
---
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Actual Result
-
array(0) {
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
[2006-03-20 00:40:03] [EMAIL PROTECTED]
It still doesn't work without execute() after prepare().
And after adding this execute() call, it works _just fine_.
[2006-03-20 00:29:10] bubblenut at gmail dot com
OK, so change the fetches for fetchAlls an alter the expected and
actual results acordingly (yes I have tested with those methods). The
bug still stands. Prepared statements are not working for this install.
[2006-03-19 22:47:39] [EMAIL PROTECTED]
This is what I get with your code (and this is expected):
---
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 2014 Cannot execute queries while
other unbuffered queries are active. Consider using
PDOStatement::fetchAll(). Alternatively, if your code is only ever
going to run against mysql, you may enable query buffering by setting
the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.' in /tmp/1.php:11
Stack trace:
#0 /tmp/1.php(11): PDO-prepare('SELECT id FROM ...')
#1 {main}
thrown in /tmp/1.php on line 11
---
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36788
--
Edit this bug report at http://bugs.php.net/?id=36788edit=1
#36749 [Asn-Csd]: 'Error Fetching http body' when using HTTP Proxy
ID: 36749 Updated by: [EMAIL PROTECTED] Reported By: robertg2 at hope dot ac dot uk -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: Windows XP Suse 10 PHP Version: 5.1.2 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_1. Please verify with Novell Bordermanager. Previous Comments: [2006-03-19 15:31:14] robertg2 at hope dot ac dot uk Using a default install of Squid 2.5STABLE10-5 instead of Novell BorderManager for the proxy makes the SoapFault disappear. The only real difference in the response from Squid is the fact that it is HTTP/1.0. Using a default install of tinyproxy 1.6.3 - http://tinyproxy.sourceforge.net/ - makes the SoapFault reappear. The response from tinyproxy is in HTTP/1.1, like BorderManager's. So... the rule so far is: if PHP Soap is set to use a web proxy, and the proxy returns a response of type HTTP/1.1 with no Content-Length header, this SoapFault will occur. [2006-03-18 22:30:16] [EMAIL PROTECTED] Dmitry, please take a look at it. [2006-03-18 22:12:16] robertg2 at hope dot ac dot uk Checked it out - the other services contain a 'Content-Length' HTTP header in the response to the soapcalls. The amazon.com ItemLookup service referred to in this report does not. [2006-03-18 21:10:36] [EMAIL PROTECTED] How do I know that? If you can check it out - please do it and tell us. [2006-03-18 20:56:28] robertg2 at hope dot ac dot uk That is correct. I don't pretend to have a full grasp of the problem, but may I suggest/speculate/guess that those web services that work through the proxy for me either use chunked data or specify a value in the Content-length header in their response(s). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36749 -- Edit this bug report at http://bugs.php.net/?id=36749edit=1
#36788 [Opn]: prepared statements broken
ID: 36788
User updated by: bubblenut at gmail dot com
Reported By: bubblenut at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Linux 2.6.12 (Kubuntu)
PHP Version: 5.1.2
New Comment:
Discovered that I can still use php but I'm still getting the same
result
array(0) {
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Previous Comments:
[2006-03-20 11:35:03] bubblenut at gmail dot com
I get the following error when doing the make install
SECURITY ERROR: PHP_Archive::mapPhar can only be called from within the
phar that initiates itInstalling PDO headers:
/usr/local/php/include/php/ext/pdo/
Also earlier in the make install I get the following libtool warning
libtool: install: warning: remember to run `libtool --finish
/usr/local/src/php5.1-200603200930/libs'
[2006-03-20 11:09:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-20 00:55:22] bubblenut at gmail dot com
Ahh, sorry, little typo, OK it looks like it's just in the parameter
insertion then (do I need to start a new bug report?)
Revised Code
?php
//phpinfo();
$db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=?);
$stmt-bindValue(1, 1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
foreach($db-query(SELECT id FROM recipe WHERE id=1) as $res) {
var_dump($res);
}
Expected Result
---
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Actual Result
-
array(0) {
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
[2006-03-20 00:40:03] [EMAIL PROTECTED]
It still doesn't work without execute() after prepare().
And after adding this execute() call, it works _just fine_.
[2006-03-20 00:29:10] bubblenut at gmail dot com
OK, so change the fetches for fetchAlls an alter the expected and
actual results acordingly (yes I have tested with those methods). The
bug still stands. Prepared statements are not working for this install.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36788
--
Edit this bug report at http://bugs.php.net/?id=36788edit=1
#36788 [Opn-Fbk]: prepared statements broken
ID: 36788
Updated by: [EMAIL PROTECTED]
Reported By: bubblenut at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux 2.6.12 (Kubuntu)
PHP Version: 5.1.2
New Comment:
Ignore them. I believe you don't need PEAR to test PDO.
Previous Comments:
[2006-03-20 11:41:57] bubblenut at gmail dot com
Discovered that I can still use php but I'm still getting the same
result
array(0) {
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
[2006-03-20 11:35:03] bubblenut at gmail dot com
I get the following error when doing the make install
SECURITY ERROR: PHP_Archive::mapPhar can only be called from within the
phar that initiates itInstalling PDO headers:
/usr/local/php/include/php/ext/pdo/
Also earlier in the make install I get the following libtool warning
libtool: install: warning: remember to run `libtool --finish
/usr/local/src/php5.1-200603200930/libs'
[2006-03-20 11:09:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-20 00:55:22] bubblenut at gmail dot com
Ahh, sorry, little typo, OK it looks like it's just in the parameter
insertion then (do I need to start a new bug report?)
Revised Code
?php
//phpinfo();
$db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=?);
$stmt-bindValue(1, 1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
$stmt = $db-prepare(SELECT id FROM recipe WHERE id=1);
$stmt-execute();
$res = $stmt-fetchAll();
var_dump($res);
foreach($db-query(SELECT id FROM recipe WHERE id=1) as $res) {
var_dump($res);
}
Expected Result
---
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
Actual Result
-
array(0) {
}
array(1) {
[0]=
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
}
array(2) {
[id]=
string(1) 1
[0]=
string(1) 1
}
[2006-03-20 00:40:03] [EMAIL PROTECTED]
It still doesn't work without execute() after prepare().
And after adding this execute() call, it works _just fine_.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36788
--
Edit this bug report at http://bugs.php.net/?id=36788edit=1
#36749 [Csd]: 'Error Fetching http body' when using HTTP Proxy
ID: 36749 User updated by: robertg2 at hope dot ac dot uk Reported By: robertg2 at hope dot ac dot uk Status: Closed Bug Type: SOAP related Operating System: Windows XP Suse 10 PHP Version: 5.1.2 Assigned To: dmitry New Comment: Latest snapshot tested and working with Novell Bordermanager. Quick work, thanks! Previous Comments: [2006-03-20 11:38:25] [EMAIL PROTECTED] Fixed in CVS HEAD and PHP_5_1. Please verify with Novell Bordermanager. [2006-03-19 15:31:14] robertg2 at hope dot ac dot uk Using a default install of Squid 2.5STABLE10-5 instead of Novell BorderManager for the proxy makes the SoapFault disappear. The only real difference in the response from Squid is the fact that it is HTTP/1.0. Using a default install of tinyproxy 1.6.3 - http://tinyproxy.sourceforge.net/ - makes the SoapFault reappear. The response from tinyproxy is in HTTP/1.1, like BorderManager's. So... the rule so far is: if PHP Soap is set to use a web proxy, and the proxy returns a response of type HTTP/1.1 with no Content-Length header, this SoapFault will occur. [2006-03-18 22:30:16] [EMAIL PROTECTED] Dmitry, please take a look at it. [2006-03-18 22:12:16] robertg2 at hope dot ac dot uk Checked it out - the other services contain a 'Content-Length' HTTP header in the response to the soapcalls. The amazon.com ItemLookup service referred to in this report does not. [2006-03-18 21:10:36] [EMAIL PROTECTED] How do I know that? If you can check it out - please do it and tell us. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36749 -- Edit this bug report at http://bugs.php.net/?id=36749edit=1
#36716 [Bgs-Csd]: php.ini not found in scriptdirectory see Bug #33882
ID: 36716
User updated by: schwarz at power-netz dot de
Reported By: schwarz at power-netz dot de
-Status: Bogus
+Status: Closed
Bug Type: CGI related
Operating System: linux 2.4.32
PHP Version: 5.1.2
New Comment:
RESOLVED would be a good status :)
The error is simple to remove :
Add a ./: before your configure --with-config-file-path
option, like i.e. --with-config-file-path=./:/usr/local/apache/conf
Problem solved.
If you have stated that matter in the changelogs,
we didn't see it , but if not, you should mention it.
5.0.3 :
'./configure'
'--with-pdflib=/home/power-netz/PDFlib-Lite-6.0.0p1/bind/pdflib/c/'
'--with-mysql=/usr' '--with-imap=/usr/src/imap-2002d' '--with-openssl'
'--with-jpeg-dir' '--with-zlib-dir' '--enable-ftp' '--with-gd'
'--with-freetype-dir=/usr/include/freetype2' '--with-png-dir'
'--with-session' '--enable-trans-sid' '--enable-gd-native-ttf'
'--with-ming' '--with-curl' '--with-mcrypt'
'--with-mysql-sock=/opt/root/tmp/mysql.sock'
'--with-imap-ssl=/usr/src/imap-2002d'
'--with-config-file-path=/usr/local/apache/conf/' '--with-idn'
'--enable-force-cgi-redirect'
5.1.2 :
'./configure'
'--with-pdflib=/home/power-netz/PDFlib-Lite-6.0.0p1/bind/pdflib/c/'
'--with-mysql=/usr' '--with-imap=/usr/src/imap-2002d' '--with-openssl'
'--with-jpeg-dir' '--with-zlib-dir' '--enable-ftp' '--with-gd'
'--with-freetype-dir=/usr/include/freetype2' '--with-png-dir'
'--with-session' '--enable-trans-sid' '--enable-gd-native-ttf'
'--with-ming' '--with-curl' '--with-mcrypt'
'--with-mysql-sock=/opt/root/tmp/mysql.sock'
'--with-imap-ssl=/usr/src/imap-2002d'
'--with-config-file-path=.:/usr/local/apache/conf/' '--with-idn'
'--enable-force-cgi-redirect'
Previous Comments:
[2006-03-19 18:08:51] [EMAIL PROTECTED]
Works fine here:
[EMAIL PROTECTED]:~/development/testimonials$ strace -o t
../php/5.1/sapi/cgi/php -i /dev/null; grep \.ini t; rm t;
lstat64(/home/mike/development/php/5.1/sapi/cgi/php-cgi.ini,
0xbfedf5fc) = -1 ENOENT (No such file or directory)
open(/home/mike/development/php/5.1/sapi/cgi/php-cgi.ini, O_RDONLY) =
-1 ENOENT (No such file or directory)
lstat64(/home/mike/development/testimonials/php-cgi.ini, 0xbfedf5fc)
= -1 ENOENT (No such file or directory)
open(/home/mike/development/testimonials/php-cgi.ini, O_RDONLY) = -1
ENOENT (No such file or directory)
lstat64(/home/mike/development/php/5.1/sapi/cgi/php.ini,
{st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
readlink(/home/mike/development/php/5.1/sapi/cgi/php.ini,
../../php.ini, 4096) = 13
lstat64(/home/mike/development/php/5.1/php.ini,
{st_mode=S_IFREG|0644, st_size=103, ...}) = 0
open(/home/mike/development/php/5.1/php.ini, O_RDONLY) = 3
lstat64(/home/mike/development/php/5.1/sapi/cgi/php.ini,
{st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
readlink(/home/mike/development/php/5.1/sapi/cgi/php.ini,
../../php.ini, 4096) = 13
lstat64(/home/mike/development/php/5.1/php.ini,
{st_mode=S_IFREG|0644, st_size=103, ...}) = 0
write(1, Configuration File (php.ini) Pat..., 33) = 33
[2006-03-16 10:50:08] schwarz at power-netz dot de
reconsider it.
[2006-03-14 10:16:52] schwarz at power-netz dot de
You are right, php4 and 5.0.3 don't seek inside
the script dir directly. The Apache sets the current
directory to the scripts directory and php4 + 5.0.3
try to open ./php-cgi.ini which 5.1.2 does not
try.
Pls see here for the difference:
bash-2.04# pwd
/home/benderircde/public_html/php5
bash-2.04# cd /home/benderircde/public_html/php5
bash-2.04# strace php5 /home/benderircde/public_html/php5/info.php 21
| grep php5-cgi.ini
open(/usr/local/apache/conf//php5-cgi.ini, O_RDONLY) = 3
lstat64(/usr/local/apache/conf/php5-cgi.ini, {st_mode=S_IFREG|0644,
st_size=25282, ...}) = 0
trtd class=eConfiguration File (php.ini) Path /tdtd
class=v/usr/local/apache/conf/php5-cgi.ini /td/tr
bash-2.04# strace php5.0.3 /home/benderircde/public_html/php5/info.php
21 | grep php5-cgi.ini
open(./php5-cgi.ini, O_RDONLY)= 3
lstat64(/home/benderircde/public_html/php5/php5-cgi.ini,
{st_mode=S_IFREG|0644, st_size=339, ...}) = 0
trtd class=eConfiguration File (php.ini) Path /tdtd
class=v/home/benderircde/public_html/php5/php5-cgi.ini /td/tr
bash-2.04# strace php /home/benderircde/public_html/php5/info.php 21
| grep php-cgi.ini
open(./php-cgi.ini, O_RDONLY) = 3
lstat64(/home/benderircde/public_html/php5/php-cgi.ini,
{st_mode=S_IFREG|0644, st_size=339, ...}) = 0
trtd class=eConfiguration File (php.ini) Path /tdtd
class=v/home/benderircde/public_html/php5/php-cgi.ini /td/tr
bash-2.04#
[2006-03-14 09:28:07] [EMAIL PROTECTED]
PHP4 doesn't behave this way and I doubt PHP5 will do it either, just
because
#36716 [Csd-Bgs]: php.ini not found in scriptdirectory see Bug #33882
ID: 36716
Updated by: [EMAIL PROTECTED]
Reported By: schwarz at power-netz dot de
-Status: Closed
+Status: Bogus
Bug Type: CGI related
Operating System: linux 2.4.32
PHP Version: 5.1.2
New Comment:
No bug - no change - Bogus.
Previous Comments:
[2006-03-20 13:42:23] schwarz at power-netz dot de
RESOLVED would be a good status :)
The error is simple to remove :
Add a ./: before your configure --with-config-file-path
option, like i.e. --with-config-file-path=./:/usr/local/apache/conf
Problem solved.
If you have stated that matter in the changelogs,
we didn't see it , but if not, you should mention it.
5.0.3 :
'./configure'
'--with-pdflib=/home/power-netz/PDFlib-Lite-6.0.0p1/bind/pdflib/c/'
'--with-mysql=/usr' '--with-imap=/usr/src/imap-2002d' '--with-openssl'
'--with-jpeg-dir' '--with-zlib-dir' '--enable-ftp' '--with-gd'
'--with-freetype-dir=/usr/include/freetype2' '--with-png-dir'
'--with-session' '--enable-trans-sid' '--enable-gd-native-ttf'
'--with-ming' '--with-curl' '--with-mcrypt'
'--with-mysql-sock=/opt/root/tmp/mysql.sock'
'--with-imap-ssl=/usr/src/imap-2002d'
'--with-config-file-path=/usr/local/apache/conf/' '--with-idn'
'--enable-force-cgi-redirect'
5.1.2 :
'./configure'
'--with-pdflib=/home/power-netz/PDFlib-Lite-6.0.0p1/bind/pdflib/c/'
'--with-mysql=/usr' '--with-imap=/usr/src/imap-2002d' '--with-openssl'
'--with-jpeg-dir' '--with-zlib-dir' '--enable-ftp' '--with-gd'
'--with-freetype-dir=/usr/include/freetype2' '--with-png-dir'
'--with-session' '--enable-trans-sid' '--enable-gd-native-ttf'
'--with-ming' '--with-curl' '--with-mcrypt'
'--with-mysql-sock=/opt/root/tmp/mysql.sock'
'--with-imap-ssl=/usr/src/imap-2002d'
'--with-config-file-path=.:/usr/local/apache/conf/' '--with-idn'
'--enable-force-cgi-redirect'
[2006-03-19 18:08:51] [EMAIL PROTECTED]
Works fine here:
[EMAIL PROTECTED]:~/development/testimonials$ strace -o t
../php/5.1/sapi/cgi/php -i /dev/null; grep \.ini t; rm t;
lstat64(/home/mike/development/php/5.1/sapi/cgi/php-cgi.ini,
0xbfedf5fc) = -1 ENOENT (No such file or directory)
open(/home/mike/development/php/5.1/sapi/cgi/php-cgi.ini, O_RDONLY) =
-1 ENOENT (No such file or directory)
lstat64(/home/mike/development/testimonials/php-cgi.ini, 0xbfedf5fc)
= -1 ENOENT (No such file or directory)
open(/home/mike/development/testimonials/php-cgi.ini, O_RDONLY) = -1
ENOENT (No such file or directory)
lstat64(/home/mike/development/php/5.1/sapi/cgi/php.ini,
{st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
readlink(/home/mike/development/php/5.1/sapi/cgi/php.ini,
../../php.ini, 4096) = 13
lstat64(/home/mike/development/php/5.1/php.ini,
{st_mode=S_IFREG|0644, st_size=103, ...}) = 0
open(/home/mike/development/php/5.1/php.ini, O_RDONLY) = 3
lstat64(/home/mike/development/php/5.1/sapi/cgi/php.ini,
{st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
readlink(/home/mike/development/php/5.1/sapi/cgi/php.ini,
../../php.ini, 4096) = 13
lstat64(/home/mike/development/php/5.1/php.ini,
{st_mode=S_IFREG|0644, st_size=103, ...}) = 0
write(1, Configuration File (php.ini) Pat..., 33) = 33
[2006-03-16 10:50:08] schwarz at power-netz dot de
reconsider it.
[2006-03-14 10:16:52] schwarz at power-netz dot de
You are right, php4 and 5.0.3 don't seek inside
the script dir directly. The Apache sets the current
directory to the scripts directory and php4 + 5.0.3
try to open ./php-cgi.ini which 5.1.2 does not
try.
Pls see here for the difference:
bash-2.04# pwd
/home/benderircde/public_html/php5
bash-2.04# cd /home/benderircde/public_html/php5
bash-2.04# strace php5 /home/benderircde/public_html/php5/info.php 21
| grep php5-cgi.ini
open(/usr/local/apache/conf//php5-cgi.ini, O_RDONLY) = 3
lstat64(/usr/local/apache/conf/php5-cgi.ini, {st_mode=S_IFREG|0644,
st_size=25282, ...}) = 0
trtd class=eConfiguration File (php.ini) Path /tdtd
class=v/usr/local/apache/conf/php5-cgi.ini /td/tr
bash-2.04# strace php5.0.3 /home/benderircde/public_html/php5/info.php
21 | grep php5-cgi.ini
open(./php5-cgi.ini, O_RDONLY)= 3
lstat64(/home/benderircde/public_html/php5/php5-cgi.ini,
{st_mode=S_IFREG|0644, st_size=339, ...}) = 0
trtd class=eConfiguration File (php.ini) Path /tdtd
class=v/home/benderircde/public_html/php5/php5-cgi.ini /td/tr
bash-2.04# strace php /home/benderircde/public_html/php5/info.php 21
| grep php-cgi.ini
open(./php-cgi.ini, O_RDONLY) = 3
lstat64(/home/benderircde/public_html/php5/php-cgi.ini,
{st_mode=S_IFREG|0644, st_size=339, ...}) = 0
trtd class=eConfiguration File (php.ini) Path /tdtd
class=v/home/benderircde/public_html/php5/php-cgi.ini /td/tr
bash-2.04#
#36797 [NEW]: Problem using UTF-8 database with pdo_oci
From: mauroi at digbang dot com
Operating system: Win XP SP2
PHP version: 5.1.2
PHP Bug Type: PDO related
Bug description: Problem using UTF-8 database with pdo_oci
Description:
I'm trying to use a AL32UTF8 database with PDO, but it seems that the
charset is not correctly set (I get funny characters in the output).
I've tried the method described in
(http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.html)
with no success.
I'm using Oracle instant client for Windows.
Reproduce code:
---
sql:
create table foo (field varchar(10));
php:
$a = new PDO('oci:dbname=server;charset=UTF-8', 'user', 'password');
$a-beginTransaction();
$b = $a-prepare('insert into foo (field) values (?)');
$b-bindValue(1, 'áéíóú');
$b-execute();
$c = $a-prepare('select * from foo');
$c-execute();
var_dump($c-fetchAll());
$a-rollBack();
Expected result:
the result with the row with áéíóú correctly displayed
--
Edit bug report at http://bugs.php.net/?id=36797edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36797r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36797r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36797r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36797r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36797r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36797r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36797r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36797r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36797r=support
Expected behavior:http://bugs.php.net/fix.php?id=36797r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36797r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36797r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36797r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36797r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36797r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36797r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36797r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36797r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36797r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36797r=mysqlcfg
#36797 [Opn-Fbk]: Problem using UTF-8 database with pdo_oci
ID: 36797
Updated by: [EMAIL PROTECTED]
Reported By: mauroi at digbang dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Win XP SP2
PHP Version: 5.1.2
New Comment:
Try with AL32UTF8 instead of UTF-8.
Previous Comments:
[2006-03-20 15:22:13] mauroi at digbang dot com
Description:
I'm trying to use a AL32UTF8 database with PDO, but it seems that the
charset is not correctly set (I get funny characters in the output).
I've tried the method described in
(http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.html)
with no success.
I'm using Oracle instant client for Windows.
Reproduce code:
---
sql:
create table foo (field varchar(10));
php:
$a = new PDO('oci:dbname=server;charset=UTF-8', 'user', 'password');
$a-beginTransaction();
$b = $a-prepare('insert into foo (field) values (?)');
$b-bindValue(1, 'áéíóú');
$b-execute();
$c = $a-prepare('select * from foo');
$c-execute();
var_dump($c-fetchAll());
$a-rollBack();
Expected result:
the result with the row with áéíóú correctly displayed
--
Edit this bug report at http://bugs.php.net/?id=36797edit=1
#36797 [Fbk-Opn]: Problem using UTF-8 database with pdo_oci
ID: 36797
User updated by: mauroi at digbang dot com
Reported By: mauroi at digbang dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Win XP SP2
PHP Version: 5.1.2
New Comment:
I've tried but the same happens.
I've also tried the complete NLS_LANG (AMERICAN_AMERICA.AL32UTF8) with
no success.
Thanks!
Previous Comments:
[2006-03-20 15:25:04] [EMAIL PROTECTED]
Try with AL32UTF8 instead of UTF-8.
[2006-03-20 15:22:13] mauroi at digbang dot com
Description:
I'm trying to use a AL32UTF8 database with PDO, but it seems that the
charset is not correctly set (I get funny characters in the output).
I've tried the method described in
(http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.html)
with no success.
I'm using Oracle instant client for Windows.
Reproduce code:
---
sql:
create table foo (field varchar(10));
php:
$a = new PDO('oci:dbname=server;charset=UTF-8', 'user', 'password');
$a-beginTransaction();
$b = $a-prepare('insert into foo (field) values (?)');
$b-bindValue(1, 'áéíóú');
$b-execute();
$c = $a-prepare('select * from foo');
$c-execute();
var_dump($c-fetchAll());
$a-rollBack();
Expected result:
the result with the row with áéíóú correctly displayed
--
Edit this bug report at http://bugs.php.net/?id=36797edit=1
#36795 [Opn-Fbk]: Inappropriate unterminated entity reference in DOMElement-setAttribute
ID: 36795 Updated by: [EMAIL PROTECTED] Reported By: john at carney dot id dot au -Status: Open +Status: Feedback Bug Type: DOM XML related Operating System: Windows/Linux PHP Version: 5.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Also, what version of libxml2 are you using as I am unable to reproduce this. Previous Comments: [2006-03-20 02:05:23] john at carney dot id dot au Description: While it is not specifically mentioned in the documentation, DOMElement-setAttribute automatically escapes XML special characters in the value parameter. Yet, as of PHP 5.1.2 it will throw an unterminated entity reference warning if the supplied value contains an ampersand - even if it is escaped. As well as fixing the actual bug, the documentation needs to clarify *exactly* how special characters in the inputs to this and other DOM functions are treated. If you are going to silently escape input text, you need to tell people so that they don't end up with stuff being double-escaped. Reproduce code: --- $element-setAttribute (anattr, jack jill) ; $element-setAttribute (anattr, jack amp; jill) ; Expected result: No warnings should be thrown. Actual result: -- BOTH calls to setAttribute throw an unterminated entity reference warning. -- Edit this bug report at http://bugs.php.net/?id=36795edit=1
#36798 [NEW]: mysql error when using named parameters in a query with high ascii
From: albert at jool dot nl Operating system: Debian Sarge PHP version: 5.1.2 PHP Bug Type: PDO related Bug description: mysql error when using named parameters in a query with high ascii Description: Create a PDO_MYSQL connection ($db in the example code). Prepare a query with high ascii values between single quotes (update queries are often affected) and one or more named parameters. Execute the query. Reproduce code: --- $query = SELECT 'ï' as test FROMtest WHERE id = :id; $stm = $db-prepare($query); $stm-execute(array(:id = 1)); Expected result: No errors, query is correct when executed directly under mysql. Actual result: -- SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':id' at line 3 -- Edit bug report at http://bugs.php.net/?id=36798edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36798r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36798r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36798r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36798r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36798r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36798r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36798r=needscript Try newer version:http://bugs.php.net/fix.php?id=36798r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36798r=support Expected behavior:http://bugs.php.net/fix.php?id=36798r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36798r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36798r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36798r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36798r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36798r=dst IIS Stability:http://bugs.php.net/fix.php?id=36798r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36798r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36798r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36798r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36798r=mysqlcfg
#36798 [Opn]: mysql error when using named parameters in a query with high ascii
ID: 36798 User updated by: albert at jool dot nl Reported By: albert at jool dot nl Status: Open Bug Type: PDO related Operating System: Debian Sarge PHP Version: 5.1.2 New Comment: Changing the single quotes in the query to double seems to fix the problem. Previous Comments: [2006-03-20 15:50:38] albert at jool dot nl Description: Create a PDO_MYSQL connection ($db in the example code). Prepare a query with high ascii values between single quotes (update queries are often affected) and one or more named parameters. Execute the query. Reproduce code: --- $query = SELECT 'ï' as test FROMtest WHERE id = :id; $stm = $db-prepare($query); $stm-execute(array(:id = 1)); Expected result: No errors, query is correct when executed directly under mysql. Actual result: -- SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':id' at line 3 -- Edit this bug report at http://bugs.php.net/?id=36798edit=1
#36798 [Opn-Fbk]: mysql error when using named parameters in a query with high ascii
ID: 36798 Updated by: [EMAIL PROTECTED] Reported By: albert at jool dot nl -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Debian Sarge PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Can't reproduce. Previous Comments: [2006-03-20 15:54:34] albert at jool dot nl Changing the single quotes in the query to double seems to fix the problem. [2006-03-20 15:50:38] albert at jool dot nl Description: Create a PDO_MYSQL connection ($db in the example code). Prepare a query with high ascii values between single quotes (update queries are often affected) and one or more named parameters. Execute the query. Reproduce code: --- $query = SELECT 'ï' as test FROMtest WHERE id = :id; $stm = $db-prepare($query); $stm-execute(array(:id = 1)); Expected result: No errors, query is correct when executed directly under mysql. Actual result: -- SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':id' at line 3 -- Edit this bug report at http://bugs.php.net/?id=36798edit=1
#36798 [Fbk-Opn]: response
ID: 36798 User updated by: albert at jool dot nl -Summary: mysql error when using named parameters in a query with high ascii Reported By: albert at jool dot nl -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Debian Sarge PHP Version: 5.1.2 New Comment: Tried the snapshot, and the problem still exists. Perhaps you aren't seeing the error because you need to explicitly set exception handling: $db = new PDO(mysql:host=$dbHost;dbname=$dbName, $dbUser, $dbPass); $db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); [.. and then the code ..] Previous Comments: [2006-03-20 15:59:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Can't reproduce. [2006-03-20 15:54:34] albert at jool dot nl Changing the single quotes in the query to double seems to fix the problem. [2006-03-20 15:50:38] albert at jool dot nl Description: Create a PDO_MYSQL connection ($db in the example code). Prepare a query with high ascii values between single quotes (update queries are often affected) and one or more named parameters. Execute the query. Reproduce code: --- $query = SELECT 'ï' as test FROMtest WHERE id = :id; $stm = $db-prepare($query); $stm-execute(array(:id = 1)); Expected result: No errors, query is correct when executed directly under mysql. Actual result: -- SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':id' at line 3 -- Edit this bug report at http://bugs.php.net/?id=36798edit=1
#36798 [Opn]: mysql error when using named parameters in a query with high ascii
ID: 36798 User updated by: albert at jool dot nl -Summary: response Reported By: albert at jool dot nl Status: Open Bug Type: PDO related Operating System: Debian Sarge PHP Version: 5.1.2 New Comment: oops, changed the summary Previous Comments: [2006-03-20 16:52:34] albert at jool dot nl Tried the snapshot, and the problem still exists. Perhaps you aren't seeing the error because you need to explicitly set exception handling: $db = new PDO(mysql:host=$dbHost;dbname=$dbName, $dbUser, $dbPass); $db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); [.. and then the code ..] [2006-03-20 15:59:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Can't reproduce. [2006-03-20 15:54:34] albert at jool dot nl Changing the single quotes in the query to double seems to fix the problem. [2006-03-20 15:50:38] albert at jool dot nl Description: Create a PDO_MYSQL connection ($db in the example code). Prepare a query with high ascii values between single quotes (update queries are often affected) and one or more named parameters. Execute the query. Reproduce code: --- $query = SELECT 'ï' as test FROMtest WHERE id = :id; $stm = $db-prepare($query); $stm-execute(array(:id = 1)); Expected result: No errors, query is correct when executed directly under mysql. Actual result: -- SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':id' at line 3 -- Edit this bug report at http://bugs.php.net/?id=36798edit=1
#36799 [NEW]: Short cirquit AND evaluates like OR
From: cleo at anarki dot dk
Operating system: WinXP, Mandriva Linux 2006
PHP version: 5.1.2
PHP Bug Type: *General Issues
Bug description: Short cirquit AND evaluates like OR
Description:
Consider the following piece of code:
$res= ($h=0) and ($h=23);
It could be used to determine if a user has submitted an hour between 0
and 23.
However, if the user enters 25, then the function evaluates to true
If you reverse the order of the operands like this:
$res = ($h=23) and ($h=0);
...then a $h value of 25 will make the function evaluate to false.
But now -1 will make it evaluate to true!
So clearly, this must be a major bug.
Best regards
Claus Holm, Copenhagen, Denmark
Reproduce code:
---
? if (isset($_POST['test'])) {
$hours= $_POST['e_hours'];
$hours= (integer)$hours;
echo You entered $hours br;
echo 'Now we test: ($hours=0) and ($hours=23)br';
$test1= ($hours=0) and ($hours=23);
echo $test1 ? ok : nope;
echo br;
echo 'And now we test: ($hours=23)and($hours=0)br';
$test2= ($hours=23) and ($hours=0);
echo $test2 ? ok : nope;
}
else {
? Input an hour between 0 and 23:br
FORM action=?=$_SERVER['PHP_SELF']? method=post
INPUT type=text name=e_hours value=br
INPUT type=submit name=test value=Run test
/form
?}
?
Expected result:
If the value 25 is entered, then I should see this:
You entered 25
Now we test: ($hours=0) and ($hours=23)
nope
And now we test: ($hours=23) and ($hours=0)
nope
Actual result:
--
You entered 25
Now we test: ($hours=0) and ($hours=23)
ok
And now we test: ($hours=23) and ($hours=0)
nope
--
Edit bug report at http://bugs.php.net/?id=36799edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36799r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36799r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36799r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36799r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36799r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36799r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36799r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36799r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36799r=support
Expected behavior:http://bugs.php.net/fix.php?id=36799r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36799r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36799r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36799r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36799r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36799r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36799r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36799r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36799r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36799r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36799r=mysqlcfg
#36799 [Opn-Bgs]: Short cirquit AND evaluates like OR
ID: 36799
Updated by: [EMAIL PROTECTED]
Reported By: cleo at anarki dot dk
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: WinXP, Mandriva Linux 2006
PHP Version: 5.1.2
New Comment:
$h = 25;
$res = (($h=0) and ($h=23));
Previous Comments:
[2006-03-20 17:47:15] cleo at anarki dot dk
Description:
Consider the following piece of code:
$res= ($h=0) and ($h=23);
It could be used to determine if a user has submitted an hour between 0
and 23.
However, if the user enters 25, then the function evaluates to
true
If you reverse the order of the operands like this:
$res = ($h=23) and ($h=0);
...then a $h value of 25 will make the function evaluate to false.
But now -1 will make it evaluate to true!
So clearly, this must be a major bug.
Best regards
Claus Holm, Copenhagen, Denmark
Reproduce code:
---
? if (isset($_POST['test'])) {
$hours= $_POST['e_hours'];
$hours= (integer)$hours;
echo You entered $hours br;
echo 'Now we test: ($hours=0) and ($hours=23)br';
$test1= ($hours=0) and ($hours=23);
echo $test1 ? ok : nope;
echo br;
echo 'And now we test: ($hours=23)and($hours=0)br';
$test2= ($hours=23) and ($hours=0);
echo $test2 ? ok : nope;
}
else {
? Input an hour between 0 and 23:br
FORM action=?=$_SERVER['PHP_SELF']? method=post
INPUT type=text name=e_hours value=br
INPUT type=submit name=test value=Run test
/form
?}
?
Expected result:
If the value 25 is entered, then I should see this:
You entered 25
Now we test: ($hours=0) and ($hours=23)
nope
And now we test: ($hours=23) and ($hours=0)
nope
Actual result:
--
You entered 25
Now we test: ($hours=0) and ($hours=23)
ok
And now we test: ($hours=23) and ($hours=0)
nope
--
Edit this bug report at http://bugs.php.net/?id=36799edit=1
#36726 [Bgs-Opn]: imagecreatefromjpeg() crahes PHP
ID: 36726
User updated by: christoph at ziegenberg dot com
Reported By: christoph at ziegenberg dot com
-Status: Bogus
+Status: Open
Bug Type: GD related
Operating System: Suse Linux 9.3
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
It is the bundled GD. I added two additional files for you to compare -
one working fine and one producing the expected error, because it could
not be opened by imagecreatefromjpeg().
And I added a link to allow you a look on the basic phpinfo() output. I
will provide you with further information, if needed.
As I already mentioned it seems to work on other systems. And as also
mentioned another user had the same problem - so there seems to be
something wrong, doesn't it?
Previous Comments:
[2006-03-18 23:24:09] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
All images work well for me. You can try yourself with this script, put
all your images in a 36726 folder and run this script:
$basedir = ./36726/;
$images = array('14844.jpg', '18925.jpg', '21987.jpg');
foreach ($images as $a) {
$im = imagecreatefromjpeg($basedir . $a);
imagejpeg($im, $basedir . $a.2.jpeg);
echo $a done\n;
}
Be sure to use the bundled GD (configure --with-gd).
[2006-03-18 18:40:55] christoph at ziegenberg dot com
I uploaded the images and a testscript.
Look here: http://www.ziegenberg.com/jpegbug/
[2006-03-13 22:59:31] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please give us an image to reproduce your problem.
[2006-03-13 22:37:23] christoph at ziegenberg dot com
Description:
Using imagecreatefromjpeg() lets PHP crash without an error message.
also using @imagecreatefromjpeg() doesn't help - it's not possible to
check the returning value.
I the user comments a user already described problems with jpegs
created by Canon PowerShot S70, my image (uploaded by a user) was
created by a Canon PowerShot A400. So this seems to be the problem.
It worked on my Windows XP without any problem, but on Suse it
crashed...
Reproduce code:
---
I'll ask the user to upload the picture here. Then simply call
imagecreatefromjpeg() with this image.
Expected result:
No crash, but an error message and an empty return value.
Actual result:
--
Crash
--
Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36726 [Opn-Fbk]: imagecreatefromjpeg() crahes PHP
ID: 36726
Updated by: [EMAIL PROTECTED]
Reported By: christoph at ziegenberg dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Suse Linux 9.3
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
Sorry I do not trace your changes :) which files did you add?
Cannot be opened by imagecreatefromjpeg? What does that mean? It
crashes or you have an error message?
The phpinfo you provide is useless as it does not show the GD
informations...
Previous Comments:
[2006-03-20 18:45:55] christoph at ziegenberg dot com
It is the bundled GD. I added two additional files for you to compare -
one working fine and one producing the expected error, because it could
not be opened by imagecreatefromjpeg().
And I added a link to allow you a look on the basic phpinfo() output. I
will provide you with further information, if needed.
As I already mentioned it seems to work on other systems. And as also
mentioned another user had the same problem - so there seems to be
something wrong, doesn't it?
[2006-03-18 23:24:09] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
All images work well for me. You can try yourself with this script, put
all your images in a 36726 folder and run this script:
$basedir = ./36726/;
$images = array('14844.jpg', '18925.jpg', '21987.jpg');
foreach ($images as $a) {
$im = imagecreatefromjpeg($basedir . $a);
imagejpeg($im, $basedir . $a.2.jpeg);
echo $a done\n;
}
Be sure to use the bundled GD (configure --with-gd).
[2006-03-18 18:40:55] christoph at ziegenberg dot com
I uploaded the images and a testscript.
Look here: http://www.ziegenberg.com/jpegbug/
[2006-03-13 22:59:31] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please give us an image to reproduce your problem.
[2006-03-13 22:37:23] christoph at ziegenberg dot com
Description:
Using imagecreatefromjpeg() lets PHP crash without an error message.
also using @imagecreatefromjpeg() doesn't help - it's not possible to
check the returning value.
I the user comments a user already described problems with jpegs
created by Canon PowerShot S70, my image (uploaded by a user) was
created by a Canon PowerShot A400. So this seems to be the problem.
It worked on my Windows XP without any problem, but on Suse it
crashed...
Reproduce code:
---
I'll ask the user to upload the picture here. Then simply call
imagecreatefromjpeg() with this image.
Expected result:
No crash, but an error message and an empty return value.
Actual result:
--
Crash
--
Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36801 [NEW]: imagecreagefromstring accepts content of MPEG files
From: glavoie at mutehq dot net Operating system: Debian Sarge GNU/Linux PHP version: 5.1.2 PHP Bug Type: GD related Bug description: imagecreagefromstring accepts content of MPEG files Description: If I give the content of a MPEG file to imagecreatefromstring, it doesn't return an error. This is causing me an headach with HTTP graphic file upload since I must be sure that uploaded files are realli graphic ones for resizing. -- Edit bug report at http://bugs.php.net/?id=36801edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36801r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36801r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36801r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36801r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36801r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36801r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36801r=needscript Try newer version:http://bugs.php.net/fix.php?id=36801r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36801r=support Expected behavior:http://bugs.php.net/fix.php?id=36801r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36801r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36801r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36801r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36801r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36801r=dst IIS Stability:http://bugs.php.net/fix.php?id=36801r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36801r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36801r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36801r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36801r=mysqlcfg
#36801 [Opn-Fbk]: imagecreagefromstring accepts content of MPEG files
ID: 36801 Updated by: [EMAIL PROTECTED] Reported By: glavoie at mutehq dot net -Status: Open +Status: Feedback Bug Type: GD related Operating System: Debian Sarge GNU/Linux PHP Version: 5.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2006-03-20 19:08:30] glavoie at mutehq dot net Description: If I give the content of a MPEG file to imagecreatefromstring, it doesn't return an error. This is causing me an headach with HTTP graphic file upload since I must be sure that uploaded files are realli graphic ones for resizing. -- Edit this bug report at http://bugs.php.net/?id=36801edit=1
#36726 [Fbk-Opn]: imagecreatefromjpeg() crahes PHP
ID: 36726
User updated by: christoph at ziegenberg dot com
Reported By: christoph at ziegenberg dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Suse Linux 9.3
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
I added the following images: 21839.jpg, 21494.jpg, 7737.jpg,
22086.jpg, 11848.jpg
You can see the GD information on the main page (gd_info() output), but
now you will also see the output from the phpinfo() (filtered to not
publish more information than needed).
cannot be opened by imagecreatefromjpeg means that the function
imagecreatefromjpeg() will return an empty string and create an error
for some of the new image - try it and you'll see what I mean. This is
what I expect for the first uploaded images if there is something wrong
with the format (although I don't know what this is for the example
images)...
Previous Comments:
[2006-03-20 18:58:12] [EMAIL PROTECTED]
Sorry I do not trace your changes :) which files did you add?
Cannot be opened by imagecreatefromjpeg? What does that mean? It
crashes or you have an error message?
The phpinfo you provide is useless as it does not show the GD
informations...
[2006-03-20 18:45:55] christoph at ziegenberg dot com
It is the bundled GD. I added two additional files for you to compare -
one working fine and one producing the expected error, because it could
not be opened by imagecreatefromjpeg().
And I added a link to allow you a look on the basic phpinfo() output. I
will provide you with further information, if needed.
As I already mentioned it seems to work on other systems. And as also
mentioned another user had the same problem - so there seems to be
something wrong, doesn't it?
[2006-03-18 23:24:09] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
All images work well for me. You can try yourself with this script, put
all your images in a 36726 folder and run this script:
$basedir = ./36726/;
$images = array('14844.jpg', '18925.jpg', '21987.jpg');
foreach ($images as $a) {
$im = imagecreatefromjpeg($basedir . $a);
imagejpeg($im, $basedir . $a.2.jpeg);
echo $a done\n;
}
Be sure to use the bundled GD (configure --with-gd).
[2006-03-18 18:40:55] christoph at ziegenberg dot com
I uploaded the images and a testscript.
Look here: http://www.ziegenberg.com/jpegbug/
[2006-03-13 22:59:31] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Please give us an image to reproduce your problem.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36726
--
Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36792 [Opn-Fbk]: Apache crashing while executing some scripts
ID: 36792 Updated by: [EMAIL PROTECTED] Reported By: webmaster at zloba dot ath dot cx -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP SP2 PHP Version: 4.4.2 New Comment: I can't reproduce any crashes and/or different problems with Apache1/Apache2 prefork/Apache2 threaded. Valgrind doesn't report any memory issues also. Previous Comments: [2006-03-20 09:02:40] webmaster at zloba dot ath dot cx After some tracing I founded that the problem is caused by the installer.php here: http://zloba.ath.cx/lotgd-installer.zip There are many cut-offs of code and this installer crashes without any arguments passed (because actually there aren't any argument checks). The error logged is the same as I pasted above. I left only the libraries and common.php too, but it is still very hard job to trace the problem, there are too much includes. I will continue working to realize which instruction(s) cause the crash of Apache. [2006-03-19 22:36:21] [EMAIL PROTECTED] If it's possible, please provide short and complete reproduce code. [2006-03-19 22:30:09] webmaster at zloba dot ath dot cx The script crashes here: http://your.server/lotgd/installer.php?stage=1c=1-232014 (stage 2 - license agreement) installer.php has many includes so here is the full source code (the official side requires registration in order to download it): http://zloba.ath.cx/lotgd-1.0.6.tar.gz It doesn't require any additional modules of PHP to test the installer, so I think there shouldn't be any problems. I forgot to quote the error log: [Sun Mar 19 23:20:22 2006] [notice] Parent: child process exited with status 3221225477 -- Restarting. The status is always the same. [2006-03-19 22:01:21] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-03-19 21:59:38] webmaster at zloba dot ath dot cx Description: Apache (2.0.55) crashes in certain situations. Tried running LoTGD (http://dragonprime.net/) and the httpd crashed. Other scripts have crashed too. It says that the actual problem was from php4ts.dll and the problem is when scripts are run, so I think it's PHP bug. The dump of Apache (over 20MB unzipped!) is here: http://zloba.ath.cx/dumps.zip Reproduce code: --- LoTGD 1.0.6 installation scripts from http://dragonprime.net/ Expected result: Have the software installed Actual result: -- The HTTPD crashed -- Edit this bug report at http://bugs.php.net/?id=36792edit=1
#36726 [Opn-Fbk]: imagecreatefromjpeg() crahes PHP
ID: 36726
Updated by: [EMAIL PROTECTED]
Reported By: christoph at ziegenberg dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Suse Linux 9.3
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
Sorry, can you provide me *one* archive with all the images inside?
FYI, I tried 11848.jpg and it works well.
I feel like your system is broken or you are doing something wrong in
your setup.
Previous Comments:
[2006-03-20 19:33:55] christoph at ziegenberg dot com
I added the following images: 21839.jpg, 21494.jpg, 7737.jpg,
22086.jpg, 11848.jpg
You can see the GD information on the main page (gd_info() output), but
now you will also see the output from the phpinfo() (filtered to not
publish more information than needed).
cannot be opened by imagecreatefromjpeg means that the function
imagecreatefromjpeg() will return an empty string and create an error
for some of the new image - try it and you'll see what I mean. This is
what I expect for the first uploaded images if there is something wrong
with the format (although I don't know what this is for the example
images)...
[2006-03-20 18:58:12] [EMAIL PROTECTED]
Sorry I do not trace your changes :) which files did you add?
Cannot be opened by imagecreatefromjpeg? What does that mean? It
crashes or you have an error message?
The phpinfo you provide is useless as it does not show the GD
informations...
[2006-03-20 18:45:55] christoph at ziegenberg dot com
It is the bundled GD. I added two additional files for you to compare -
one working fine and one producing the expected error, because it could
not be opened by imagecreatefromjpeg().
And I added a link to allow you a look on the basic phpinfo() output. I
will provide you with further information, if needed.
As I already mentioned it seems to work on other systems. And as also
mentioned another user had the same problem - so there seems to be
something wrong, doesn't it?
[2006-03-18 23:24:09] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
All images work well for me. You can try yourself with this script, put
all your images in a 36726 folder and run this script:
$basedir = ./36726/;
$images = array('14844.jpg', '18925.jpg', '21987.jpg');
foreach ($images as $a) {
$im = imagecreatefromjpeg($basedir . $a);
imagejpeg($im, $basedir . $a.2.jpeg);
echo $a done\n;
}
Be sure to use the bundled GD (configure --with-gd).
[2006-03-18 18:40:55] christoph at ziegenberg dot com
I uploaded the images and a testscript.
Look here: http://www.ziegenberg.com/jpegbug/
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36726
--
Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36802 [NEW]: Signal 11 with with mysqli_set_charset ()
From: mdalton at galaxytelecom dot net Operating system: Linux PHP version: 5.1.2 PHP Bug Type: Reproducible crash Bug description: Signal 11 with with mysqli_set_charset () Description: While trying to call set_charset method on a mysqli object php crashes with a signal 11. Situation tested on a stock ubuntu php + mysqli + mysql 5.0 setup, and on a home rolled apache+hardened-php+mysql 5.0 system Reproduce code: --- ?php $mysqli = mysqli_init (); $mysqli-set_charset ( 'utf8' ); echo $mysqli-character_set_name (); ? Expected result: script should echo 'utf8' Actual result: -- The apache child process bombs with a signal 11 -- Edit bug report at http://bugs.php.net/?id=36802edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36802r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36802r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36802r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36802r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36802r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36802r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36802r=needscript Try newer version:http://bugs.php.net/fix.php?id=36802r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36802r=support Expected behavior:http://bugs.php.net/fix.php?id=36802r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36802r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36802r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36802r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36802r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36802r=dst IIS Stability:http://bugs.php.net/fix.php?id=36802r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36802r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36802r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36802r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36802r=mysqlcfg
#36802 [Opn-Fbk]: Signal 11 with with mysqli_set_charset ()
ID: 36802 Updated by: [EMAIL PROTECTED] Reported By: mdalton at galaxytelecom dot net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip If you still can reproduce it with plain PHP, please provide gdb backtrace (see http://bugs.php.net/bugs-generating-backtrace.php). Previous Comments: [2006-03-20 19:49:08] mdalton at galaxytelecom dot net Description: While trying to call set_charset method on a mysqli object php crashes with a signal 11. Situation tested on a stock ubuntu php + mysqli + mysql 5.0 setup, and on a home rolled apache+hardened-php+mysql 5.0 system Reproduce code: --- ?php $mysqli = mysqli_init (); $mysqli-set_charset ( 'utf8' ); echo $mysqli-character_set_name (); ? Expected result: script should echo 'utf8' Actual result: -- The apache child process bombs with a signal 11 -- Edit this bug report at http://bugs.php.net/?id=36802edit=1
#36799 [Bgs]: Short cirquit AND evaluates like OR
ID: 36799
User updated by: cleo at anarki dot dk
Reported By: cleo at anarki dot dk
Status: Bogus
Bug Type: *General Issues
Operating System: WinXP, Mandriva Linux 2006
PHP Version: 5.1.2
New Comment:
All right,
( (p1) and (p2) )
evaluates correctly,
but that doesn't change the fact, that
(p1) and (p2)
evaluates totally wrongly.
And I don't see the difference.
Neither from a mathematician's nor a computer scientist's point of
view.
Therefore, I still strongly argue, that this is a bug in PHP's way of
evaluating boolean expressions.
Best regards
Claus Holm from Copenhagen
Previous Comments:
[2006-03-20 18:09:23] [EMAIL PROTECTED]
$h = 25;
$res = (($h=0) and ($h=23));
[2006-03-20 17:47:15] cleo at anarki dot dk
Description:
Consider the following piece of code:
$res= ($h=0) and ($h=23);
It could be used to determine if a user has submitted an hour between 0
and 23.
However, if the user enters 25, then the function evaluates to
true
If you reverse the order of the operands like this:
$res = ($h=23) and ($h=0);
...then a $h value of 25 will make the function evaluate to false.
But now -1 will make it evaluate to true!
So clearly, this must be a major bug.
Best regards
Claus Holm, Copenhagen, Denmark
Reproduce code:
---
? if (isset($_POST['test'])) {
$hours= $_POST['e_hours'];
$hours= (integer)$hours;
echo You entered $hours br;
echo 'Now we test: ($hours=0) and ($hours=23)br';
$test1= ($hours=0) and ($hours=23);
echo $test1 ? ok : nope;
echo br;
echo 'And now we test: ($hours=23)and($hours=0)br';
$test2= ($hours=23) and ($hours=0);
echo $test2 ? ok : nope;
}
else {
? Input an hour between 0 and 23:br
FORM action=?=$_SERVER['PHP_SELF']? method=post
INPUT type=text name=e_hours value=br
INPUT type=submit name=test value=Run test
/form
?}
?
Expected result:
If the value 25 is entered, then I should see this:
You entered 25
Now we test: ($hours=0) and ($hours=23)
nope
And now we test: ($hours=23) and ($hours=0)
nope
Actual result:
--
You entered 25
Now we test: ($hours=0) and ($hours=23)
ok
And now we test: ($hours=23) and ($hours=0)
nope
--
Edit this bug report at http://bugs.php.net/?id=36799edit=1
#36799 [Bgs]: Short cirquit AND evaluates like OR
ID: 36799
Updated by: [EMAIL PROTECTED]
Reported By: cleo at anarki dot dk
Status: Bogus
Bug Type: *General Issues
Operating System: WinXP, Mandriva Linux 2006
PHP Version: 5.1.2
New Comment:
http://www.php.net/manual/en/language.operators.php#language.operators.precedence
Previous Comments:
[2006-03-20 19:59:05] cleo at anarki dot dk
All right,
( (p1) and (p2) )
evaluates correctly,
but that doesn't change the fact, that
(p1) and (p2)
evaluates totally wrongly.
And I don't see the difference.
Neither from a mathematician's nor a computer scientist's point of
view.
Therefore, I still strongly argue, that this is a bug in PHP's way of
evaluating boolean expressions.
Best regards
Claus Holm from Copenhagen
[2006-03-20 18:09:23] [EMAIL PROTECTED]
$h = 25;
$res = (($h=0) and ($h=23));
[2006-03-20 17:47:15] cleo at anarki dot dk
Description:
Consider the following piece of code:
$res= ($h=0) and ($h=23);
It could be used to determine if a user has submitted an hour between 0
and 23.
However, if the user enters 25, then the function evaluates to
true
If you reverse the order of the operands like this:
$res = ($h=23) and ($h=0);
...then a $h value of 25 will make the function evaluate to false.
But now -1 will make it evaluate to true!
So clearly, this must be a major bug.
Best regards
Claus Holm, Copenhagen, Denmark
Reproduce code:
---
? if (isset($_POST['test'])) {
$hours= $_POST['e_hours'];
$hours= (integer)$hours;
echo You entered $hours br;
echo 'Now we test: ($hours=0) and ($hours=23)br';
$test1= ($hours=0) and ($hours=23);
echo $test1 ? ok : nope;
echo br;
echo 'And now we test: ($hours=23)and($hours=0)br';
$test2= ($hours=23) and ($hours=0);
echo $test2 ? ok : nope;
}
else {
? Input an hour between 0 and 23:br
FORM action=?=$_SERVER['PHP_SELF']? method=post
INPUT type=text name=e_hours value=br
INPUT type=submit name=test value=Run test
/form
?}
?
Expected result:
If the value 25 is entered, then I should see this:
You entered 25
Now we test: ($hours=0) and ($hours=23)
nope
And now we test: ($hours=23) and ($hours=0)
nope
Actual result:
--
You entered 25
Now we test: ($hours=0) and ($hours=23)
ok
And now we test: ($hours=23) and ($hours=0)
nope
--
Edit this bug report at http://bugs.php.net/?id=36799edit=1
#36803 [NEW]: pdo_pgsql lobs problem
From: mauroi at digbang dot com Operating system: Win XP SP2 PHP version: 5.1.2 PHP Bug Type: PDO related Bug description: pdo_pgsql lobs problem Description: I'm trying to insert a lob into a pgsql field. My first problem is that the documentation doesn't say if the table field should be a bytea or an oid (more suitable for a large object). I supposed both worked. I've tried with a bytea and it worked as expected. But the same operation with an OID field doesn't work. (Also, i've noticed three undocumented public methods in pdo_pgsql (pgsqlLOBUnlink, pgsqlLOBOpen, pgsqlLOBCreate)) Shouldn't it work with both methods??? At least, the quote function escapes always the lob as if it was a bytea. But in the rest of the driver it considers the possibility of an oid. Thanks in advance. -- Edit bug report at http://bugs.php.net/?id=36803edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36803r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36803r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36803r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36803r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36803r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36803r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36803r=needscript Try newer version:http://bugs.php.net/fix.php?id=36803r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36803r=support Expected behavior:http://bugs.php.net/fix.php?id=36803r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36803r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36803r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36803r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36803r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36803r=dst IIS Stability:http://bugs.php.net/fix.php?id=36803r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36803r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36803r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36803r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36803r=mysqlcfg
#36804 [NEW]: pdo_pgsql lobs problem
From: mauroi at digbang dot com Operating system: Win XP SP2 PHP version: 5.1.2 PHP Bug Type: PDO related Bug description: pdo_pgsql lobs problem Description: I'm trying to insert a lob into a pgsql field. My first problem is that the documentation doesn't say if the table field should be a bytea or an oid (more suitable for a large object). I supposed both worked. I've tried with a bytea and it worked as expected. But the same operation with an OID field doesn't work. (Also, i've noticed three undocumented public methods in pdo_pgsql (pgsqlLOBUnlink, pgsqlLOBOpen, pgsqlLOBCreate)) Shouldn't it work with both methods??? At least, the quote function escapes always the lob as if it was a bytea. But in the rest of the driver it considers the possibility of an oid. Thanks in advance. -- Edit bug report at http://bugs.php.net/?id=36804edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36804r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36804r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36804r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36804r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36804r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36804r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36804r=needscript Try newer version:http://bugs.php.net/fix.php?id=36804r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36804r=support Expected behavior:http://bugs.php.net/fix.php?id=36804r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36804r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36804r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36804r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36804r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36804r=dst IIS Stability:http://bugs.php.net/fix.php?id=36804r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36804r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36804r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36804r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36804r=mysqlcfg
#36726 [Fbk-Opn]: imagecreatefromjpeg() crahes PHP
ID: 36726
User updated by: christoph at ziegenberg dot com
Reported By: christoph at ziegenberg dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Suse Linux 9.3
PHP Version: 5.1.2
Assigned To: pajoye
New Comment:
Download it here:
http://www.ziegenberg.com/jpegbug/images.zip
Maybe the setup is the problem, but 99% of the uploaded images work
fine. Nevertheless you should get an error you can work with...
Previous Comments:
[2006-03-20 19:42:57] [EMAIL PROTECTED]
Sorry, can you provide me *one* archive with all the images inside?
FYI, I tried 11848.jpg and it works well.
I feel like your system is broken or you are doing something wrong in
your setup.
[2006-03-20 19:33:55] christoph at ziegenberg dot com
I added the following images: 21839.jpg, 21494.jpg, 7737.jpg,
22086.jpg, 11848.jpg
You can see the GD information on the main page (gd_info() output), but
now you will also see the output from the phpinfo() (filtered to not
publish more information than needed).
cannot be opened by imagecreatefromjpeg means that the function
imagecreatefromjpeg() will return an empty string and create an error
for some of the new image - try it and you'll see what I mean. This is
what I expect for the first uploaded images if there is something wrong
with the format (although I don't know what this is for the example
images)...
[2006-03-20 18:58:12] [EMAIL PROTECTED]
Sorry I do not trace your changes :) which files did you add?
Cannot be opened by imagecreatefromjpeg? What does that mean? It
crashes or you have an error message?
The phpinfo you provide is useless as it does not show the GD
informations...
[2006-03-20 18:45:55] christoph at ziegenberg dot com
It is the bundled GD. I added two additional files for you to compare -
one working fine and one producing the expected error, because it could
not be opened by imagecreatefromjpeg().
And I added a link to allow you a look on the basic phpinfo() output. I
will provide you with further information, if needed.
As I already mentioned it seems to work on other systems. And as also
mentioned another user had the same problem - so there seems to be
something wrong, doesn't it?
[2006-03-18 23:24:09] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
All images work well for me. You can try yourself with this script, put
all your images in a 36726 folder and run this script:
$basedir = ./36726/;
$images = array('14844.jpg', '18925.jpg', '21987.jpg');
foreach ($images as $a) {
$im = imagecreatefromjpeg($basedir . $a);
imagejpeg($im, $basedir . $a.2.jpeg);
echo $a done\n;
}
Be sure to use the bundled GD (configure --with-gd).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36726
--
Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36803 [Opn-Bgs]: pdo_pgsql lobs problem
ID: 36803 Updated by: [EMAIL PROTECTED] Reported By: mauroi at digbang dot com -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Win XP SP2 PHP Version: 5.1.2 New Comment: . Previous Comments: [2006-03-20 20:13:01] mauroi at digbang dot com Description: I'm trying to insert a lob into a pgsql field. My first problem is that the documentation doesn't say if the table field should be a bytea or an oid (more suitable for a large object). I supposed both worked. I've tried with a bytea and it worked as expected. But the same operation with an OID field doesn't work. (Also, i've noticed three undocumented public methods in pdo_pgsql (pgsqlLOBUnlink, pgsqlLOBOpen, pgsqlLOBCreate)) Shouldn't it work with both methods??? At least, the quote function escapes always the lob as if it was a bytea. But in the rest of the driver it considers the possibility of an oid. Thanks in advance. -- Edit this bug report at http://bugs.php.net/?id=36803edit=1
#36804 [Opn-Bgs]: pdo_pgsql lobs problem
ID: 36804 Updated by: [EMAIL PROTECTED] Reported By: mauroi at digbang dot com -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Win XP SP2 PHP Version: 5.1.2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-03-20 20:13:41] mauroi at digbang dot com Description: I'm trying to insert a lob into a pgsql field. My first problem is that the documentation doesn't say if the table field should be a bytea or an oid (more suitable for a large object). I supposed both worked. I've tried with a bytea and it worked as expected. But the same operation with an OID field doesn't work. (Also, i've noticed three undocumented public methods in pdo_pgsql (pgsqlLOBUnlink, pgsqlLOBOpen, pgsqlLOBCreate)) Shouldn't it work with both methods??? At least, the quote function escapes always the lob as if it was a bytea. But in the rest of the driver it considers the possibility of an oid. Thanks in advance. -- Edit this bug report at http://bugs.php.net/?id=36804edit=1
#36804 [Bgs-Csd]: pdo_pgsql lobs problem
ID: 36804 User updated by: mauroi at digbang dot com Reported By: mauroi at digbang dot com -Status: Bogus +Status: Closed Bug Type: PDO related Operating System: Win XP SP2 PHP Version: 5.1.2 New Comment: Duplicated. Sorry Previous Comments: [2006-03-20 20:17:28] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2006-03-20 20:13:41] mauroi at digbang dot com Description: I'm trying to insert a lob into a pgsql field. My first problem is that the documentation doesn't say if the table field should be a bytea or an oid (more suitable for a large object). I supposed both worked. I've tried with a bytea and it worked as expected. But the same operation with an OID field doesn't work. (Also, i've noticed three undocumented public methods in pdo_pgsql (pgsqlLOBUnlink, pgsqlLOBOpen, pgsqlLOBCreate)) Shouldn't it work with both methods??? At least, the quote function escapes always the lob as if it was a bytea. But in the rest of the driver it considers the possibility of an oid. Thanks in advance. -- Edit this bug report at http://bugs.php.net/?id=36804edit=1
#36805 [NEW]: lob-load() only returning first 1MB
From: terry at bitsoup dot com
Operating system: Win2K3 Enterprise
PHP version: 5.1.3RC1
PHP Bug Type: OCI8 related
Bug description: lob-load() only returning first 1MB
Description:
When we tried to load an approx. 2.2MB LOB into a string using the
$lob-load() routine, only the first 1MB was returned.
We did not notice this behavior in previous versions.
The workaround we have in place for now is to use the $lob-read() method
instead.
$text = ''
while ($str = $clob-read(10)) { $text .= $str; }
Reproduce code:
---
$text = '';
$text = $clob-load();
echo LOB SIZE= . $clob-size() . br;
echo STR SIZE= . strlen($text) . br;
Expected result:
LOB SIZE=2213589
STR SIZE=2213589
Actual result:
--
LOB SIZE=2213589
STR SIZE=1048576
--
Edit bug report at http://bugs.php.net/?id=36805edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36805r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36805r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36805r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36805r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36805r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36805r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36805r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36805r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36805r=support
Expected behavior:http://bugs.php.net/fix.php?id=36805r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36805r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36805r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36805r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36805r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36805r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36805r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36805r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36805r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36805r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36805r=mysqlcfg
#36805 [Opn-Bgs]: lob-load() only returning first 1MB
ID: 36805
Updated by: [EMAIL PROTECTED]
Reported By: terry at bitsoup dot com
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: Win2K3 Enterprise
PHP Version: 5.1.3RC1
New Comment:
Duplicate of http://pecl.php.net/bugs/bug.php?id=5995
Previous Comments:
[2006-03-20 20:43:54] terry at bitsoup dot com
Description:
When we tried to load an approx. 2.2MB LOB into a string using the
$lob-load() routine, only the first 1MB was returned.
We did not notice this behavior in previous versions.
The workaround we have in place for now is to use the $lob-read()
method instead.
$text = ''
while ($str = $clob-read(10)) { $text .= $str; }
Reproduce code:
---
$text = '';
$text = $clob-load();
echo LOB SIZE= . $clob-size() . br;
echo STR SIZE= . strlen($text) . br;
Expected result:
LOB SIZE=2213589
STR SIZE=2213589
Actual result:
--
LOB SIZE=2213589
STR SIZE=1048576
--
Edit this bug report at http://bugs.php.net/?id=36805edit=1
#36726 [Opn-Bgs]: imagecreatefromjpeg() crahes PHP
ID: 36726 Updated by: [EMAIL PROTECTED] Reported By: christoph at ziegenberg dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Suse Linux 9.3 PHP Version: 5.1.2 Assigned To: pajoye New Comment: 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 21839.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 121 extraneous bytes before marker 0xd9 7737.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 135 extraneous bytes before marker 0xd9 These two jpeg images are not valid. From php 5.1.3 (try using snapshot.php.net 5.1.x), you can ignore the warnings or minor errors using this command: ini_set(gd.jpeg_ignore_warning, true); I set to expected behavior. By the way, you should use error_reporting(E_ALL); when you develop. Previous Comments: [2006-03-20 20:16:28] christoph at ziegenberg dot com Download it here: http://www.ziegenberg.com/jpegbug/images.zip Maybe the setup is the problem, but 99% of the uploaded images work fine. Nevertheless you should get an error you can work with... [2006-03-20 19:42:57] [EMAIL PROTECTED] Sorry, can you provide me *one* archive with all the images inside? FYI, I tried 11848.jpg and it works well. I feel like your system is broken or you are doing something wrong in your setup. [2006-03-20 19:33:55] christoph at ziegenberg dot com I added the following images: 21839.jpg, 21494.jpg, 7737.jpg, 22086.jpg, 11848.jpg You can see the GD information on the main page (gd_info() output), but now you will also see the output from the phpinfo() (filtered to not publish more information than needed). cannot be opened by imagecreatefromjpeg means that the function imagecreatefromjpeg() will return an empty string and create an error for some of the new image - try it and you'll see what I mean. This is what I expect for the first uploaded images if there is something wrong with the format (although I don't know what this is for the example images)... [2006-03-20 18:58:12] [EMAIL PROTECTED] Sorry I do not trace your changes :) which files did you add? Cannot be opened by imagecreatefromjpeg? What does that mean? It crashes or you have an error message? The phpinfo you provide is useless as it does not show the GD informations... [2006-03-20 18:45:55] christoph at ziegenberg dot com It is the bundled GD. I added two additional files for you to compare - one working fine and one producing the expected error, because it could not be opened by imagecreatefromjpeg(). And I added a link to allow you a look on the basic phpinfo() output. I will provide you with further information, if needed. As I already mentioned it seems to work on other systems. And as also mentioned another user had the same problem - so there seems to be something wrong, doesn't it? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36726 -- Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36806 [NEW]: iconv_mime_decode case-sensitivity for encoding token ('B' or 'Q')
From: jgoldsmith at returnpath dot net
Operating system: FC4
PHP version: 5.1.2
PHP Bug Type: ICONV related
Bug description: iconv_mime_decode case-sensitivity for encoding token ('B' or
'Q')
Description:
iconv_mime_decode doesn't recognize lower-case encoding tokens ('b' or
'q'). These are acceptible according to the MIME RFC
(http://www.ietf.org/rfc/rfc2047.txt).
Here is a fix. Edit file: /ext/iconv/iconv.c
Line: 1398
Change
case 'B':
to
case 'B': case 'b':
Line 1403
Change
case 'Q':
to
case 'Q': case 'q':
Reproduce code:
---
$string = '=?UTF-8?b?VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZyE=?=';
echo iconv_mime_decode($string,1);
Expected result:
This is an encoded string!
Actual result:
--
Warning: iconv_mime_decode() [function.iconv-mime-decode]: Malformed
string
--
Edit bug report at http://bugs.php.net/?id=36806edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36806r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36806r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36806r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36806r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36806r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36806r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36806r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36806r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36806r=support
Expected behavior:http://bugs.php.net/fix.php?id=36806r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36806r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36806r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36806r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36806r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36806r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36806r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36806r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36806r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36806r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36806r=mysqlcfg
#36801 [Fbk-Opn]: imagecreagefromstring accepts content of MPEG files
ID: 36801
User updated by: glavoie at mutehq dot net
Reported By: glavoie at mutehq dot net
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Debian Sarge GNU/Linux
PHP Version: 5.1.2
New Comment:
I use this script to convert images to JPEG with resizing when needed.
When a MPEG file is given to imagecreatefromstring(), $source doesn't
return false and I get an images($source) of 1 and a imagesy($source)
of ~7000. When creating the new resized image with
imagecreatetruecolor, the ratio is huge and an image of about 2.5 GB is
created in memory.
?php
if ( isset( $_GET['width'] ) )
$width = $_GET['width'];
else
$width = 0;
$source = imagecreatefromstring( file_get_contents('1.mpg')
);
if ($source)
{
if ( $width )
{
$ratio = $width / imagesx( $source );
$resized = imagecreatetruecolor( $width, $ratio
* imagesy( $source ) );
imagecopyresampled( $resized, $source, 0, 0, 0,
0, $width, $ratio * imagesy( $source ), imagesx( $source ), imagesy(
$source ) );
$source = $resized;
}
ob_start();
imagejpeg($source);
$photo = ob_get_contents();
ob_end_clean();
header( 'Content-type: image/jpeg' );
echo $photo;
}
?
Previous Comments:
[2006-03-20 19:13:58] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-03-20 19:08:30] glavoie at mutehq dot net
Description:
If I give the content of a MPEG file to imagecreatefromstring, it
doesn't return an error. This is causing me an headach with HTTP
graphic file upload since I must be sure that uploaded files are realli
graphic ones for resizing.
--
Edit this bug report at http://bugs.php.net/?id=36801edit=1
#36806 [Opn-Csd]: iconv_mime_decode case-sensitivity for encoding token ('B' or 'Q')
ID: 36806
Updated by: [EMAIL PROTECTED]
Reported By: jgoldsmith at returnpath dot net
-Status: Open
+Status: Closed
Bug Type: ICONV related
Operating System: FC4
PHP Version: 5.1.2
New Comment:
Fixed month ago.
Previous Comments:
[2006-03-20 21:42:31] jgoldsmith at returnpath dot net
Description:
iconv_mime_decode doesn't recognize lower-case encoding tokens ('b' or
'q'). These are acceptible according to the MIME RFC
(http://www.ietf.org/rfc/rfc2047.txt).
Here is a fix. Edit file: /ext/iconv/iconv.c
Line: 1398
Change
case 'B':
to
case 'B': case 'b':
Line 1403
Change
case 'Q':
to
case 'Q': case 'q':
Reproduce code:
---
$string = '=?UTF-8?b?VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZyE=?=';
echo iconv_mime_decode($string,1);
Expected result:
This is an encoded string!
Actual result:
--
Warning: iconv_mime_decode() [function.iconv-mime-decode]: Malformed
string
--
Edit this bug report at http://bugs.php.net/?id=36806edit=1
#36801 [Opn-Bgs]: imagecreagefromstring accepts content of MPEG files
ID: 36801
Updated by: [EMAIL PROTECTED]
Reported By: glavoie at mutehq dot net
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Debian Sarge GNU/Linux
PHP Version: 5.1.2
New Comment:
Looks like you're using MPEG-JPEG codec and libgd detects your file as
JPEG image. I'm not sure if anything can be done about it, but it's
definitely not PHP problem.
Previous Comments:
[2006-03-20 21:44:11] glavoie at mutehq dot net
I use this script to convert images to JPEG with resizing when needed.
When a MPEG file is given to imagecreatefromstring(), $source doesn't
return false and I get an images($source) of 1 and a imagesy($source)
of ~7000. When creating the new resized image with
imagecreatetruecolor, the ratio is huge and an image of about 2.5 GB is
created in memory.
?php
if ( isset( $_GET['width'] ) )
$width = $_GET['width'];
else
$width = 0;
$source = imagecreatefromstring( file_get_contents('1.mpg')
);
if ($source)
{
if ( $width )
{
$ratio = $width / imagesx( $source );
$resized = imagecreatetruecolor( $width, $ratio
* imagesy( $source ) );
imagecopyresampled( $resized, $source, 0, 0, 0,
0, $width, $ratio * imagesy( $source ), imagesx( $source ), imagesy(
$source ) );
$source = $resized;
}
ob_start();
imagejpeg($source);
$photo = ob_get_contents();
ob_end_clean();
header( 'Content-type: image/jpeg' );
echo $photo;
}
?
[2006-03-20 19:13:58] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-03-20 19:08:30] glavoie at mutehq dot net
Description:
If I give the content of a MPEG file to imagecreatefromstring, it
doesn't return an error. This is causing me an headach with HTTP
graphic file upload since I must be sure that uploaded files are realli
graphic ones for resizing.
--
Edit this bug report at http://bugs.php.net/?id=36801edit=1
#36802 [Fbk-Asn]: Signal 11 with with mysqli_set_charset ()
ID: 36802 Updated by: [EMAIL PROTECTED] Reported By: mdalton at galaxytelecom dot net -Status: Feedback +Status: Assigned Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.1.2 -Assigned To: +Assigned To: georg Previous Comments: [2006-03-20 19:51:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip If you still can reproduce it with plain PHP, please provide gdb backtrace (see http://bugs.php.net/bugs-generating-backtrace.php). [2006-03-20 19:49:08] mdalton at galaxytelecom dot net Description: While trying to call set_charset method on a mysqli object php crashes with a signal 11. Situation tested on a stock ubuntu php + mysqli + mysql 5.0 setup, and on a home rolled apache+hardened-php+mysql 5.0 system Reproduce code: --- ?php $mysqli = mysqli_init (); $mysqli-set_charset ( 'utf8' ); echo $mysqli-character_set_name (); ? Expected result: script should echo 'utf8' Actual result: -- The apache child process bombs with a signal 11 -- Edit this bug report at http://bugs.php.net/?id=36802edit=1
#36726 [Bgs-Opn]: imagecreatefromjpeg() crahes PHP
ID: 36726 User updated by: christoph at ziegenberg dot com Reported By: christoph at ziegenberg dot com -Status: Bogus +Status: Open Bug Type: GD related Operating System: Suse Linux 9.3 PHP Version: 5.1.2 Assigned To: pajoye New Comment: Thanks, got the reason... error_reporting was active, but display_errors wasn't and the error has not been logged. I changed it and got the following error for image 18925.jpg: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1600 bytes) I didn't expect that PHP needs so much memory for an image less than 200 KB - and I do NOT think that this is a normal behaviour, because there are much larger images (e.g. the new test image 2.jpg with about 1.5 MB) which work fine with the recommended value 8M... Changing it to 16M works for all images. I think that this error should not occur for the mentioned example image and that there is an error with the image processing wasting all the memory. So I changed this bug again to open... hope you agree. Previous Comments: [2006-03-20 21:05:35] [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 21839.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 121 extraneous bytes before marker 0xd9 7737.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 135 extraneous bytes before marker 0xd9 These two jpeg images are not valid. From php 5.1.3 (try using snapshot.php.net 5.1.x), you can ignore the warnings or minor errors using this command: ini_set(gd.jpeg_ignore_warning, true); I set to expected behavior. By the way, you should use error_reporting(E_ALL); when you develop. [2006-03-20 20:16:28] christoph at ziegenberg dot com Download it here: http://www.ziegenberg.com/jpegbug/images.zip Maybe the setup is the problem, but 99% of the uploaded images work fine. Nevertheless you should get an error you can work with... [2006-03-20 19:42:57] [EMAIL PROTECTED] Sorry, can you provide me *one* archive with all the images inside? FYI, I tried 11848.jpg and it works well. I feel like your system is broken or you are doing something wrong in your setup. [2006-03-20 19:33:55] christoph at ziegenberg dot com I added the following images: 21839.jpg, 21494.jpg, 7737.jpg, 22086.jpg, 11848.jpg You can see the GD information on the main page (gd_info() output), but now you will also see the output from the phpinfo() (filtered to not publish more information than needed). cannot be opened by imagecreatefromjpeg means that the function imagecreatefromjpeg() will return an empty string and create an error for some of the new image - try it and you'll see what I mean. This is what I expect for the first uploaded images if there is something wrong with the format (although I don't know what this is for the example images)... [2006-03-20 18:58:12] [EMAIL PROTECTED] Sorry I do not trace your changes :) which files did you add? Cannot be opened by imagecreatefromjpeg? What does that mean? It crashes or you have an error message? The phpinfo you provide is useless as it does not show the GD informations... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36726 -- Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36726 [Opn]: imagecreatefromjpeg() crahes PHP
ID: 36726 User updated by: christoph at ziegenberg dot com Reported By: christoph at ziegenberg dot com Status: Open Bug Type: GD related Operating System: Suse Linux 9.3 PHP Version: 5.1.2 Assigned To: pajoye New Comment: Bye the way: I added the additional information to the phpinfo() output with the error_reporting, memory_limit,... settings. Previous Comments: [2006-03-20 22:22:41] christoph at ziegenberg dot com Thanks, got the reason... error_reporting was active, but display_errors wasn't and the error has not been logged. I changed it and got the following error for image 18925.jpg: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1600 bytes) I didn't expect that PHP needs so much memory for an image less than 200 KB - and I do NOT think that this is a normal behaviour, because there are much larger images (e.g. the new test image 2.jpg with about 1.5 MB) which work fine with the recommended value 8M... Changing it to 16M works for all images. I think that this error should not occur for the mentioned example image and that there is an error with the image processing wasting all the memory. So I changed this bug again to open... hope you agree. [2006-03-20 21:05:35] [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 21839.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 121 extraneous bytes before marker 0xd9 7737.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 135 extraneous bytes before marker 0xd9 These two jpeg images are not valid. From php 5.1.3 (try using snapshot.php.net 5.1.x), you can ignore the warnings or minor errors using this command: ini_set(gd.jpeg_ignore_warning, true); I set to expected behavior. By the way, you should use error_reporting(E_ALL); when you develop. [2006-03-20 20:16:28] christoph at ziegenberg dot com Download it here: http://www.ziegenberg.com/jpegbug/images.zip Maybe the setup is the problem, but 99% of the uploaded images work fine. Nevertheless you should get an error you can work with... [2006-03-20 19:42:57] [EMAIL PROTECTED] Sorry, can you provide me *one* archive with all the images inside? FYI, I tried 11848.jpg and it works well. I feel like your system is broken or you are doing something wrong in your setup. [2006-03-20 19:33:55] christoph at ziegenberg dot com I added the following images: 21839.jpg, 21494.jpg, 7737.jpg, 22086.jpg, 11848.jpg You can see the GD information on the main page (gd_info() output), but now you will also see the output from the phpinfo() (filtered to not publish more information than needed). cannot be opened by imagecreatefromjpeg means that the function imagecreatefromjpeg() will return an empty string and create an error for some of the new image - try it and you'll see what I mean. This is what I expect for the first uploaded images if there is something wrong with the format (although I don't know what this is for the example images)... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36726 -- Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36791 [Fbk-Bgs]: broken php5ts.dll
ID: 36791 Updated by: [EMAIL PROTECTED] Reported By: realworld at blazefans dot com -Status: Feedback +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.1.2 New Comment: Make sure to remove all remains on the old PHP install. PHP 5.1.2 works just fine with Apache2. Previous Comments: [2006-03-19 21:38:06] [EMAIL PROTECTED] I don't have Windows, so I'm afraid I'm not able to do it. Please provide the error messages you see and any entries in error_log related to this problem. But before that please check that you've deleted all .dll's from 5.0.5 install. [2006-03-19 21:30:26] realworld at blazefans dot com To reproduce setup apache 2.0 on Windows XP with PHP 5.0.2 all should work fine Update PHP by installing PHP 5.1.2 and attempt to restart apache. Apache should fail. Replace php5ts.dll with PHP 5.0.2's version and the service should restart when requested [2006-03-19 21:22:33] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2006-03-19 21:19:45] realworld at blazefans dot com Description: Have downloaded the latest version of PHP 5 (5.1.2) and installed it on my machine and suddenly Apache would no longer start. After much searching it turns out that php5ts.dll was somehow causing the problem. I replaced the new version with the version in the backup folder and apache started again. -- Edit this bug report at http://bugs.php.net/?id=36791edit=1
#36726 [Opn-Bgs]: imagecreatefromjpeg() crahes PHP
ID: 36726 Updated by: [EMAIL PROTECTED] Reported By: christoph at ziegenberg dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Suse Linux 9.3 PHP Version: 5.1.2 Assigned To: pajoye New Comment: 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 the file size of a JPEG data has nothing to do with the size of the *uncompressed* pixel data in memory. For example, your images is 1600x1200, true colors (4bytes per pixel): == 768 bytes add to that the whole memory that your script or php may need and you are out of the 8M. Now please, keep this bug as closed as there is obviously no bug. If you need support feel free to use our numerous support possibilies. Previous Comments: [2006-03-20 22:28:46] christoph at ziegenberg dot com Bye the way: I added the additional information to the phpinfo() output with the error_reporting, memory_limit,... settings. [2006-03-20 22:22:41] christoph at ziegenberg dot com Thanks, got the reason... error_reporting was active, but display_errors wasn't and the error has not been logged. I changed it and got the following error for image 18925.jpg: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1600 bytes) I didn't expect that PHP needs so much memory for an image less than 200 KB - and I do NOT think that this is a normal behaviour, because there are much larger images (e.g. the new test image 2.jpg with about 1.5 MB) which work fine with the recommended value 8M... Changing it to 16M works for all images. I think that this error should not occur for the mentioned example image and that there is an error with the image processing wasting all the memory. So I changed this bug again to open... hope you agree. [2006-03-20 21:05:35] [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 21839.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 121 extraneous bytes before marker 0xd9 7737.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 135 extraneous bytes before marker 0xd9 These two jpeg images are not valid. From php 5.1.3 (try using snapshot.php.net 5.1.x), you can ignore the warnings or minor errors using this command: ini_set(gd.jpeg_ignore_warning, true); I set to expected behavior. By the way, you should use error_reporting(E_ALL); when you develop. [2006-03-20 20:16:28] christoph at ziegenberg dot com Download it here: http://www.ziegenberg.com/jpegbug/images.zip Maybe the setup is the problem, but 99% of the uploaded images work fine. Nevertheless you should get an error you can work with... [2006-03-20 19:42:57] [EMAIL PROTECTED] Sorry, can you provide me *one* archive with all the images inside? FYI, I tried 11848.jpg and it works well. I feel like your system is broken or you are doing something wrong in your setup. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36726 -- Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36726 [Bgs]: imagecreatefromjpeg() crahes PHP
ID: 36726 User updated by: christoph at ziegenberg dot com Reported By: christoph at ziegenberg dot com Status: Bogus Bug Type: GD related Operating System: Suse Linux 9.3 PHP Version: 5.1.2 Assigned To: pajoye New Comment: Thanks a lot, I understand what you mean. I only want to add (for other users) that all images are 24 Bit = 3 Byte per pixel, so the calculation isn't as simple as that (to multiply the dimension and channel values from getimagesize()). Previous Comments: [2006-03-20 22:34:03] [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 the file size of a JPEG data has nothing to do with the size of the *uncompressed* pixel data in memory. For example, your images is 1600x1200, true colors (4bytes per pixel): == 768 bytes add to that the whole memory that your script or php may need and you are out of the 8M. Now please, keep this bug as closed as there is obviously no bug. If you need support feel free to use our numerous support possibilies. [2006-03-20 22:28:46] christoph at ziegenberg dot com Bye the way: I added the additional information to the phpinfo() output with the error_reporting, memory_limit,... settings. [2006-03-20 22:22:41] christoph at ziegenberg dot com Thanks, got the reason... error_reporting was active, but display_errors wasn't and the error has not been logged. I changed it and got the following error for image 18925.jpg: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1600 bytes) I didn't expect that PHP needs so much memory for an image less than 200 KB - and I do NOT think that this is a normal behaviour, because there are much larger images (e.g. the new test image 2.jpg with about 1.5 MB) which work fine with the recommended value 8M... Changing it to 16M works for all images. I think that this error should not occur for the mentioned example image and that there is an error with the image processing wasting all the memory. So I changed this bug again to open... hope you agree. [2006-03-20 21:05:35] [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 21839.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 121 extraneous bytes before marker 0xd9 7737.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 135 extraneous bytes before marker 0xd9 These two jpeg images are not valid. From php 5.1.3 (try using snapshot.php.net 5.1.x), you can ignore the warnings or minor errors using this command: ini_set(gd.jpeg_ignore_warning, true); I set to expected behavior. By the way, you should use error_reporting(E_ALL); when you develop. [2006-03-20 20:16:28] christoph at ziegenberg dot com Download it here: http://www.ziegenberg.com/jpegbug/images.zip Maybe the setup is the problem, but 99% of the uploaded images work fine. Nevertheless you should get an error you can work with... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36726 -- Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36741 [Opn-Csd]: userstreams testcase have off-by-one error on fseek()
ID: 36741
Updated by: [EMAIL PROTECTED]
Reported By: elliot dot li at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
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.
Previous Comments:
[2006-03-20 01:43:18] elliot dot li at gmail dot com
Well, this is my patch. (sorry, I don't know how to append an
attachment)
= php-5.1.2-userstreams.test.patch FOLLOWS =
diff -Nur php-5.1.2/ext/standard/tests/file/userstreams.phpt
php-5.1.2.my/ext/standard/tests/file/userstreams.phpt
--- php-5.1.2/ext/standard/tests/file/userstreams.phpt 2003-11-30
21:57:17.0 +0800
+++ php-5.1.2.my/ext/standard/tests/file/userstreams.phpt
2006-03-20 08:32:10.0 +0800
@@ -211,15 +211,15 @@
$whence = $whence_map[array_rand($whence_map, 1)];
switch($whence) {
case SEEK_SET:
- $offset = rand(0, $DATALEN);
+ $offset = rand(0, $DATALEN-1);
$position = $offset;
break;
case SEEK_END:
- $offset = -rand(0, $DATALEN);
+ $offset = -rand(0, $DATALEN-1);
$position = $DATALEN + $offset;
break;
case SEEK_CUR:
- $offset = rand(0, $DATALEN);
+ $offset = rand(0, $DATALEN-1);
$offset -= $position;
$position += $offset;
break;
= php-5.1.2-userstreams.test.patch ABOVE =
[2006-03-18 21:57:31] [EMAIL PROTECTED]
Do you have a patch? (unified diff, please)
[2006-03-15 05:58:13] elliot dot li at gmail dot com
Description:
This case(php-5.1.2/ext/standard/tests/file/userstreams.phpt) generates
a bunch of random numbers and use them as offsets for fseek() test on a
userstream. However, the range of these random numbers is [0,
$DATALEN](rand(0, $DATALEN)), which should be [0, $DATALEN).
CODE SNIP FOLLOWS
/* generate some random seek offsets */
$position = 0;
for ($i = 0; $i 256; $i++) {
$whence = $whence_map[array_rand($whence_map, 1)];
switch($whence) {
case SEEK_SET:
$offset = rand(0, $DATALEN);
$position = $offset;
break;
case SEEK_END:
$offset = -rand(0, $DATALEN);
$position = $DATALEN + $offset;
break;
case SEEK_CUR:
$offset = rand(0, $DATALEN);
$offset -= $position;
$position += $offset;
break;
}
$seeks[] = array($whence, $offset, $position);
}
CODE SNIP ABOVE
Reproduce code:
---
Run this case on and on for a while, you can encounter this problem. I
found this problem during a regression test, and reproduced it on my
PC(Pentium 4 2.6GHz) within one day.
Expected result:
No error should be reported if everything goes OK.
Actual result:
--
= LOG SNIP FOLLOWS =
--[34] whence=SEEK_SET offset=32550 line_length=1024
position_should_be=32550 --
REAL: pos=(29175,32550,32550) ret=0 line[0]=`'
USER: pos=(29175,29175,29175) ret=0 line[16]=`zl urnq vf ubzr
'
## FAIL!
= LOG SNIP ABOVE =
32550 is the total length of the userstream, so fseek($fp, 32550,
SEEK_SET) must fail.
I noticed another problem: mystream.stream_seek() would return a false
on this condition, but the return value of fseek() is still 0! This
would lead to the result that the failure of seeking in a userstream
couldn't be noticed by the main program.
--
Edit this bug report at http://bugs.php.net/?id=36741edit=1
#36732 [Opn-Asn]: configargs req_extensions x509_extensions broken
ID: 36732 Updated by: [EMAIL PROTECTED] Reported By: ben at psc dot edu -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: Linux 2.6 / FC4 PHP Version: 5.1.2 -Assigned To: +Assigned To: wez New Comment: Wez, patches are looking good, please check them (and apply?). Previous Comments: [2006-03-14 05:48:34] ben at psc dot edu typo in location of 4.4.1 and 4.4.2 patch. correct spelling is: php-4.4.2-openssl-extensions-fix.patch [2006-03-14 05:30:12] ben at psc dot edu Description: According to the PHP manual, configargs keys req_extensions and x509_extensions can be used to select which extensions are used when creating a CSR and x509 certificate, respectively. There are [what appear to be] a few mistakes in ext/openssl/openssl.c which result in neither of these two options working properly. Bug #31638 appears to have reported this issue, but has not been resolved. The following patches resolve this issue, and are available at http://www.psc.edu/~ben/patches/php/ php-4.4.2-openssl-extentions-fix.patch Tested with php-4.4.1 and php-4.4.2 php-5.1.2-openssl-extensions-fix.patch Tested with only php-5.1.2 Reproduce code: --- $configargs = array( req_extensions = v3_req, x509_extensions = usr_cert ); $dn = array( countryName = GB, stateOrProvinceName = Berkshire, localityName = Newbury, organizationName = My Company Ltd, commonName = Demo Cert ); $key = openssl_pkey_new(); $csr = openssl_csr_new($dn, $key, $configargs); $crt = openssl_csr_sign($csr, NULL, $key, 365, $configargs); openssl_csr_export($csr, $str, false); print $str . \n\n; openssl_x509_export($crt, $str, false); print $str; Expected result: Certificate Request: Data: Version: 0 (0x0) Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Demo Cert Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:e7:16:aa:4c:d2:b9:53:5b:50:74:ef:b8:7b:e3: 5f:1c:a3:12:f0:12:7f:9b:94:2b:1c:d7:c6:6e:99: 2a:4f:7a:59:b2:99:6f:43:a2:e3:85:93:09:d7:ff: f0:d4:ff:05:de:e9:79:17:67:1e:23:f5:e9:41:41: 18:f3:31:80:16:9a:dd:56:f3:22:fb:44:7d:ca:40: 2b:fa:e1:6b:28:54:99:d5:34:69:18:dd:16:47:84: 54:fc:a0:0d:8f:9e:db:08:44:51:fe:5a:48:c7:61: 3c:34:6b:dc:af:b3:dc:37:7c:52:34:f8:0e:38:be: 25:45:96:ca:2f:b6:5e:eb:f5 Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Signature Algorithm: md5WithRSAEncryption 67:0f:ab:26:a5:9e:6e:00:4d:71:39:a2:cc:c9:f6:67:32:e2: 5c:bd:21:4d:b9:e0:bb:8f:e8:d5:d6:42:3c:20:71:fc:08:7a: 00:b2:97:7d:b1:47:48:f4:a7:86:f5:7f:86:d7:9c:ca:ae:0e: 03:db:c5:df:c6:4b:ea:31:37:75:4f:1e:72:3d:d5:e3:89:9f: 82:ef:3d:88:d2:fe:fd:25:5d:d0:da:0e:a9:19:2c:e5:14:ee: 3c:90:0e:ed:f3:25:6f:36:29:39:a3:23:8b:b6:62:1a:fb:b3: c7:ff:c6:73:cc:66:50:b4:1e:72:79:f6:8b:8c:67:99:f7:8b: 81:ea -BEGIN CERTIFICATE REQUEST- MIIByTCCATICAQAwYDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQ MA4GA1UEBxMHTmV3YnVyeTEXMBUGA1UEChMOTXkgQ29tcGFueSBMdGQxEjAQBgNV BAMTCURlbW8gQ2VydDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5xaqTNK5 U1tQdO+4e+NfHKMS8BJ/m5QrHNfGbpkqT3pZsplvQ6LjhZMJ1//w1P8F3ul5F2ce I/XpQUEY8zGAFprdVvMi+0R9ykAr+uFrKFSZ1TRpGN0WR4RU/KANj57bCERR/lpI x2E8NGvcr7PcN3xSNPgOOL4lRZbKL7Ze6/UCAwEAAaApMCcGCSqGSIb3DQEJDjEa MBgwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwDQYJKoZIhvcNAQEEBQADgYEAZw+r JqWebgBNcTmizMn2ZzLiXL0hTbngu4/o1dZCPCBx/Ah6ALKXfbFHSPSnhvV/htec yq4OA9vF38ZL6jE3dU8ecj3V44mfgu89iNL+/SVd0NoOqRks5RTuPJAO7fMlbzYp OaMji7ZiGvuzx//Gc8xmULQecnn2i4xnmfeLgeo= -END CERTIFICATE REQUEST- Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Demo Cert Validity Not Before: Mar 14 04:02:52 2006 GMT Not After : Mar 14 04:02:52 2007 GMT Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Demo Cert Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:e7:16:aa:4c:d2:b9:53:5b:50:74:ef:b8:7b:e3:
#36737 [Opn-Fbk]: session changes unsaved with register_long_arrays off
ID: 36737 Updated by: [EMAIL PROTECTED] Reported By: morriss at r-can dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows Server 2003 PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-03-14 19:00:42] morriss at r-can dot com Description: I'm using the ISAPI filter in IIS6. With register_long_arrays off, the session variables are not always saved. Note that in my example, I found that assigning $sv=$_SESSION; always breaks it, but my webpage only does assignments like $sv=$_SESSION['idx'] yet is still broken. setting register_long_arrays = On in php.ini fixes the problem. Reproduce code: --- headtitletest.php/title/head html body ?php session_start(); $sv = $_SESSION; //broken! //$sv['idx'] = $_SESSION['idx']; //ok! if (isset($_SESSION['idx'])) $i = $_SESSION['idx'] + 1; else $i = 0; $_SESSION['idx'] = $i; session_write_close(); echo 'pSESSION START: '.$sv['idx'].'/p'; echo 'pSESSION END: '.$_SESSION['idx'].'/p'; ? a href=test.phptest/a /body /html Expected result: SESSION START: n SESSION END: n+1 (after clicking link) SESSION START: n+1 SESSION END: n+2 Actual result: -- SESSION START: n SESSION END: n+1 (does not change even after clicking link. Note that older session data is kept, if idx=3 when requesting the test page, then n=3) -- Edit this bug report at http://bugs.php.net/?id=36737edit=1
#36721 [Opn-Asn]: The SoapServer is not able to send a header that it didn't receive.
ID: 36721 Updated by: [EMAIL PROTECTED] Reported By: hjiverson at plauditdesign dot com -Status: Open +Status: Assigned Bug Type: SOAP related Operating System: N/A PHP Version: 5.1.3RC2 -Assigned To: +Assigned To: dmitry Previous Comments: [2006-03-13 22:21:51] hjiverson at plauditdesign dot com Tested with latest snapshot, same issue: PHP 5.1.3RC2-dev (cli) (built: Mar 13 2006 20:18:23) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies [2006-03-13 19:52:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-03-13 16:50:24] hjiverson at plauditdesign dot com Description: The SoapServer is not able to send a header that it didn't receive, since receiving a header seems to be what invokes the magic function. For example, I have a sessionId header. The client makes its first call and does not yet have a session initiated, and does not send the header. The server should be able to send a sessionId header, whether it received one or not. Reproduce code: --- http://pastebin.com/599820 Expected result: The server should return the header with string FROM SERVER: Actual result: -- The server does not return any header unless one was sent. -- Edit this bug report at http://bugs.php.net/?id=36721edit=1
#36696 [Asn]: __destruct() is called before serialize() when object stored in session
ID: 36696
Updated by: [EMAIL PROTECTED]
Reported By: iain at iaindooley dot com
Status: Assigned
Bug Type: Session related
Operating System: *
PHP Version: 5.1.2
-Assigned To: sascha
+Assigned To: sas
New Comment:
Assigned to the maintainer.
Previous Comments:
[2006-03-13 19:54:55] [EMAIL PROTECTED]
exactly
[2006-03-13 11:07:12] iain at iaindooley dot com
Just for clarity, i presume you mean using:
session_write_close();
before the scripts conclude.
[2006-03-13 10:53:59] [EMAIL PROTECTED]
The solution is easy: close the session before ending your scripts.
Otherwise this is a session shutdown issue.
Assigning to primary session maintainer.
[2006-03-11 04:30:02] iain at iaindooley dot com
Description:
if an object that impelements Serializable is stored in the session,
and implements __destruct, then __destruct is called before serialize()
when the script finishes execution.
Reproduce code:
---
?
class SomeClass implements Serializable
{
function SomeClass()
{
}
public function unserialize($dat)
{
echo('called unseriazlize');
}
public function serialize()
{
echo('called serializebr /');
}
function __destruct()
{
echo('called __destructbr /');
}
}
session_name('god');
session_start();
$_SESSION['var'] = new SomeClass();
?
Expected result:
called serialize
called __destruct
Actual result:
--
called __destruct
called serialize
--
Edit this bug report at http://bugs.php.net/?id=36696edit=1
#36807 [NEW]: CLI crashs unter win32
From: spam2 at rhsoft dot net Operating system: Windows XP PHP version: 5.1.3RC1 PHP Bug Type: Reproducible crash Bug description: CLI crashs unter win32 Description: The latest snapshots for win32 crashs (only the cli) Not only one - all my scripts who will alter or backup databases for a batch-command on windows will crash down if running in command line interface - same skripts over apache2handler works normal. Some snapshots before the problem went away but it exists also in an earlier build of 5.1.3dev Reproduce code: --- Sorry not possible -- Edit bug report at http://bugs.php.net/?id=36807edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36807r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36807r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36807r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36807r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36807r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36807r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36807r=needscript Try newer version:http://bugs.php.net/fix.php?id=36807r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36807r=support Expected behavior:http://bugs.php.net/fix.php?id=36807r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36807r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36807r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36807r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36807r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36807r=dst IIS Stability:http://bugs.php.net/fix.php?id=36807r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36807r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36807r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36807r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36807r=mysqlcfg
#36807 [Opn-Fbk]: CLI crashs unter win32
ID: 36807 Updated by: [EMAIL PROTECTED] Reported By: spam2 at rhsoft dot net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.1.3RC1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2006-03-20 23:25:38] spam2 at rhsoft dot net Description: The latest snapshots for win32 crashs (only the cli) Not only one - all my scripts who will alter or backup databases for a batch-command on windows will crash down if running in command line interface - same skripts over apache2handler works normal. Some snapshots before the problem went away but it exists also in an earlier build of 5.1.3dev Reproduce code: --- Sorry not possible -- Edit this bug report at http://bugs.php.net/?id=36807edit=1
#36726 [Bgs]: imagecreatefromjpeg() crahes PHP
ID: 36726 Updated by: [EMAIL PROTECTED] Reported By: christoph at ziegenberg dot com Status: Bogus Bug Type: GD related Operating System: Suse Linux 9.3 PHP Version: 5.1.2 Assigned To: pajoye New Comment: I only want to add (for other users) that all images are 24 Bit = 3 Byte per pixel No. GD True color buffer uses *four* bytes, red, green, blue and alpha, and *always* :-) Previous Comments: [2006-03-20 22:58:32] christoph at ziegenberg dot com Thanks a lot, I understand what you mean. I only want to add (for other users) that all images are 24 Bit = 3 Byte per pixel, so the calculation isn't as simple as that (to multiply the dimension and channel values from getimagesize()). [2006-03-20 22:34:03] [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 the file size of a JPEG data has nothing to do with the size of the *uncompressed* pixel data in memory. For example, your images is 1600x1200, true colors (4bytes per pixel): == 768 bytes add to that the whole memory that your script or php may need and you are out of the 8M. Now please, keep this bug as closed as there is obviously no bug. If you need support feel free to use our numerous support possibilies. [2006-03-20 22:28:46] christoph at ziegenberg dot com Bye the way: I added the additional information to the phpinfo() output with the error_reporting, memory_limit,... settings. [2006-03-20 22:22:41] christoph at ziegenberg dot com Thanks, got the reason... error_reporting was active, but display_errors wasn't and the error has not been logged. I changed it and got the following error for image 18925.jpg: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1600 bytes) I didn't expect that PHP needs so much memory for an image less than 200 KB - and I do NOT think that this is a normal behaviour, because there are much larger images (e.g. the new test image 2.jpg with about 1.5 MB) which work fine with the recommended value 8M... Changing it to 16M works for all images. I think that this error should not occur for the mentioned example image and that there is an error with the image processing wasting all the memory. So I changed this bug again to open... hope you agree. [2006-03-20 21:05:35] [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 21839.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 121 extraneous bytes before marker 0xd9 7737.jpg: Warning: imagecreatefromjpeg(): gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 135 extraneous bytes before marker 0xd9 These two jpeg images are not valid. From php 5.1.3 (try using snapshot.php.net 5.1.x), you can ignore the warnings or minor errors using this command: ini_set(gd.jpeg_ignore_warning, true); I set to expected behavior. By the way, you should use error_reporting(E_ALL); when you develop. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36726 -- Edit this bug report at http://bugs.php.net/?id=36726edit=1
#36802 [Com]: Signal 11 with with mysqli_set_charset ()
ID: 36802 Comment by: judas dot iscariote at gmail dot com Reported By: mdalton at galaxytelecom dot net Status: Assigned Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.1.2 Assigned To: georg New Comment: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912513283232 (LWP 30938)] 0x2e4b9c65 in mysql_send_query () from /usr/lib64/libmysqlclient.so.15 (gdb) bt #0 0x2e4b9c65 in mysql_send_query () from /usr/lib64/libmysqlclient.so.15 #1 0x2e4b9cd9 in mysql_real_query () from /usr/lib64/libmysqlclient.so.15 #2 0x2e4ba011 in mysql_set_character_set () from /usr/lib64/libmysqlclient.so.15 #3 0x2e6dcbc2 in zif_mysqli_set_charset (ht=value optimized out, return_value=0x950488, return_value_ptr=value optimized out, this_ptr=value optimized out, return_value_used=value optimized out) at /usr/src/debug/php-5.1.2/ext/mysqli/mysqli_nonapi.c:329 #4 0x00d0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fb1d2a0) at zend_vm_execute.h:200 #5 0x00554c53 in execute (op_array=0x9657a8) at zend_vm_execute.h:92 #6 0x0053857c in zend_execute_scripts (type=8, retval=value optimized out, file_count=3) at /usr/src/debug/php-5.1.2/Zend/zend.c:1109 #7 0x004fac35 in php_execute_script (primary_file=0x7fb1f950) at /usr/src/debug/php-5.1.2/main/main.c:1725 #8 0x005c9285 in main (argc=2, argv=0x7fb1fb08) at /usr/src/debug/php-5.1.2/sapi/cli/php_cli.c:1092 php -v PHP 5.1.3RC2-dev (cli) (built: Mar 20 2006 17:23:27) Previous Comments: [2006-03-20 19:51:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip If you still can reproduce it with plain PHP, please provide gdb backtrace (see http://bugs.php.net/bugs-generating-backtrace.php). [2006-03-20 19:49:08] mdalton at galaxytelecom dot net Description: While trying to call set_charset method on a mysqli object php crashes with a signal 11. Situation tested on a stock ubuntu php + mysqli + mysql 5.0 setup, and on a home rolled apache+hardened-php+mysql 5.0 system Reproduce code: --- ?php $mysqli = mysqli_init (); $mysqli-set_charset ( 'utf8' ); echo $mysqli-character_set_name (); ? Expected result: script should echo 'utf8' Actual result: -- The apache child process bombs with a signal 11 -- Edit this bug report at http://bugs.php.net/?id=36802edit=1
#36808 [NEW]: syslog will output garbage from apache child process memory
From: emchen at isc dot upenn dot edu Operating system: Linux 2.6.9 / RHEL4 PHP version: 5.1.2 PHP Bug Type: Unknown/Other Function Bug description: syslog will output garbage from apache child process memory Description: the bug is a bit difficult to explain, it revolves around an apache child process handling multiple PHP requests that use openlog/syslog. the behavior of the bug is described in bug #28722 and bug #35777, namely garbage appearing as the process name / ident field in syslog. the bug occurs when an apache child process handles a script that makes an openlog called followed by a script that makes a syslog called without openlog (separate requests). Reproduce code: --- to recreate bug: 1.) set Apache (forking) MaxClients 1 2.) call php script with: ? syslog(LOG_WARNING,testing); ? 3.) call php script with: ? openlog(MYLOG,LOG_PID,LOG_LOCAL0); syslog(LOG_WARNING,this is a warning); ? 4.) call php script with: ? phpinfo(); ? 4.) call php script with: ? syslog(LOG_WARNING,testing); ? Expected result: in the attached code; the calls to syslog in step 2,3 produce normal output, output from step 4 should be garbage. since the apache child process persists beyond the execution of the PHP scripts, step 4 picks up the results of the openlog call in step 2. when sylog gets called the 3rd time the reference to ident is garbage. Actual result: -- user.log: Mar 20 16:54:15 [host] httpd: testing local0.log: Mar 20 16:56:41 [host] MYLOG[18679]: this is a warning local0.log: Mar 20 16:58:57 [host] [garbage][18679]: testing -- Edit bug report at http://bugs.php.net/?id=36808edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36808r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36808r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36808r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36808r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36808r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36808r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36808r=needscript Try newer version:http://bugs.php.net/fix.php?id=36808r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36808r=support Expected behavior:http://bugs.php.net/fix.php?id=36808r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36808r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36808r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36808r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36808r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36808r=dst IIS Stability:http://bugs.php.net/fix.php?id=36808r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36808r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36808r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36808r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36808r=mysqlcfg
#36698 [Opn-Bgs]: headers_sent() returns FALSE when script SSI-included
ID: 36698
Updated by: [EMAIL PROTECTED]
Reported By: evilcart at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: FreeBSD 5.0 Release
PHP Version: 4.4.2
New Comment:
virtual does subrequest, i.e. does almost the same as
include(http://...;).
No bug here.
Previous Comments:
[2006-03-12 10:35:30] evilcart at gmail dot com
It's just mistprint, excuse me. Of course, I'm using correct syntax in
any working examples.
There is also must be /script instead of /sctipt printed above, but
it doesn't matter, you may instert any code to that output.
[2006-03-11 20:50:29] judas dot iscariote at gmail dot com
what happends if you use CORRECT syntax ?
!--#include virtual=./script.php?$QUERY_STRING --
NOT
!--#include vurtual=./script.php?$QUERY_STRING --
???
[2006-03-11 15:41:37] evilcart at gmail dot com
Description:
I'm using PHP-script as part of the page by including it in some middle
part of the page (e.g. after some HTML code) using Apache SSI directive
!--#include ... --
So when headers_sent() is called before any script output it returns
FALSE instead of TRUE. Also, header() function called immideately after
that does nothing and executes silently.
As I can understand, any HTML code send before SSI #include of script
must set headers_sent() to TRUE.
I have no any errors suppressed on my php.ini file or by other control
directives.
Reproduce code:
---
page.shtml file (simplified):
html
body
!--#include vurtual=./script.php?$QUERY_STRING --
/body
/html
script.php file (simplified):
?php
$location = /some/path/;
if( headers_sent() ) {
echo script language=JavaScript window.location.href = ' .
$location . '/sctipt;
}
else {
header('Location: '.$location);
// execution goes HERE! And no any effect or error messages.
}
?
Expected result:
html
body
script language=JavaScript window.location.href = '/some/path/';
/sctipt
/body
/html
Actual result:
--
html
body
/body
/html
--
Edit this bug report at http://bugs.php.net/?id=36698edit=1
#36802 [Com]: Signal 11 with with mysqli_set_charset ()
ID: 36802 Comment by: judas dot iscariote at gmail dot com Reported By: mdalton at galaxytelecom dot net Status: Assigned Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.1.2 Assigned To: georg New Comment: although Im not an expert on this, seems the OP example lacks of a valid internal mysql_link (created with mysqli_real_connect or similar ) and some validation is missing in the mysqli extension an that result in a crash... I deduce this because using a valid mysqli link the function works as expected. This is a bug anyway, no userspace code should crash PHP. Previous Comments: [2006-03-20 23:28:15] judas dot iscariote at gmail dot com Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912513283232 (LWP 30938)] 0x2e4b9c65 in mysql_send_query () from /usr/lib64/libmysqlclient.so.15 (gdb) bt #0 0x2e4b9c65 in mysql_send_query () from /usr/lib64/libmysqlclient.so.15 #1 0x2e4b9cd9 in mysql_real_query () from /usr/lib64/libmysqlclient.so.15 #2 0x2e4ba011 in mysql_set_character_set () from /usr/lib64/libmysqlclient.so.15 #3 0x2e6dcbc2 in zif_mysqli_set_charset (ht=value optimized out, return_value=0x950488, return_value_ptr=value optimized out, this_ptr=value optimized out, return_value_used=value optimized out) at /usr/src/debug/php-5.1.2/ext/mysqli/mysqli_nonapi.c:329 #4 0x00d0 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fb1d2a0) at zend_vm_execute.h:200 #5 0x00554c53 in execute (op_array=0x9657a8) at zend_vm_execute.h:92 #6 0x0053857c in zend_execute_scripts (type=8, retval=value optimized out, file_count=3) at /usr/src/debug/php-5.1.2/Zend/zend.c:1109 #7 0x004fac35 in php_execute_script (primary_file=0x7fb1f950) at /usr/src/debug/php-5.1.2/main/main.c:1725 #8 0x005c9285 in main (argc=2, argv=0x7fb1fb08) at /usr/src/debug/php-5.1.2/sapi/cli/php_cli.c:1092 php -v PHP 5.1.3RC2-dev (cli) (built: Mar 20 2006 17:23:27) [2006-03-20 19:51:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip If you still can reproduce it with plain PHP, please provide gdb backtrace (see http://bugs.php.net/bugs-generating-backtrace.php). [2006-03-20 19:49:08] mdalton at galaxytelecom dot net Description: While trying to call set_charset method on a mysqli object php crashes with a signal 11. Situation tested on a stock ubuntu php + mysqli + mysql 5.0 setup, and on a home rolled apache+hardened-php+mysql 5.0 system Reproduce code: --- ?php $mysqli = mysqli_init (); $mysqli-set_charset ( 'utf8' ); echo $mysqli-character_set_name (); ? Expected result: script should echo 'utf8' Actual result: -- The apache child process bombs with a signal 11 -- Edit this bug report at http://bugs.php.net/?id=36802edit=1
#36809 [NEW]: __FILE__ behavior changed between last week and this week
From: [EMAIL PROTECTED] Operating system: linux (gentoo) PHP version: 5CVS-2006-03-20 (CVS) PHP Bug Type: Scripting Engine problem Bug description: __FILE__ behavior changed between last week and this week Description: if test.php is: ?php echo __FILE__; ? running php test.php used to spit out the full path to test.php, now it just spits out test.php note that php -r include 'test.php'; spits out the whole path to test.php -- Edit bug report at http://bugs.php.net/?id=36809edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36809r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36809r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36809r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36809r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36809r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36809r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36809r=needscript Try newer version:http://bugs.php.net/fix.php?id=36809r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36809r=support Expected behavior:http://bugs.php.net/fix.php?id=36809r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36809r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36809r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36809r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36809r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36809r=dst IIS Stability:http://bugs.php.net/fix.php?id=36809r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36809r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36809r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36809r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36809r=mysqlcfg
#36809 [Opn]: __FILE__ behavior changed between last week and this week
ID: 36809 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: linux (gentoo) PHP Version: 5CVS-2006-03-20 (CVS) -Assigned To: +Assigned To: dmitry New Comment: [16:49:22] tony2002 fill the report and assign it to Dmitry [16:49:41] tony2002 it's definitely related to the hacks he did recently Previous Comments: [2006-03-21 00:02:24] [EMAIL PROTECTED] Description: if test.php is: ?php echo __FILE__; ? running php test.php used to spit out the full path to test.php, now it just spits out test.php note that php -r include 'test.php'; spits out the whole path to test.php -- Edit this bug report at http://bugs.php.net/?id=36809edit=1
#36808 [Opn-Csd]: syslog will output garbage from apache child process memory
ID: 36808 Updated by: [EMAIL PROTECTED] Reported By: emchen at isc dot upenn dot edu -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Linux 2.6.9 / RHEL4 PHP Version: 5.1.2 New Comment: 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. Previous Comments: [2006-03-20 23:29:34] emchen at isc dot upenn dot edu Description: the bug is a bit difficult to explain, it revolves around an apache child process handling multiple PHP requests that use openlog/syslog. the behavior of the bug is described in bug #28722 and bug #35777, namely garbage appearing as the process name / ident field in syslog. the bug occurs when an apache child process handles a script that makes an openlog called followed by a script that makes a syslog called without openlog (separate requests). Reproduce code: --- to recreate bug: 1.) set Apache (forking) MaxClients 1 2.) call php script with: ? syslog(LOG_WARNING,testing); ? 3.) call php script with: ? openlog(MYLOG,LOG_PID,LOG_LOCAL0); syslog(LOG_WARNING,this is a warning); ? 4.) call php script with: ? phpinfo(); ? 4.) call php script with: ? syslog(LOG_WARNING,testing); ? Expected result: in the attached code; the calls to syslog in step 2,3 produce normal output, output from step 4 should be garbage. since the apache child process persists beyond the execution of the PHP scripts, step 4 picks up the results of the openlog call in step 2. when sylog gets called the 3rd time the reference to ident is garbage. Actual result: -- user.log: Mar 20 16:54:15 [host] httpd: testing local0.log: Mar 20 16:56:41 [host] MYLOG[18679]: this is a warning local0.log: Mar 20 16:58:57 [host] [garbage][18679]: testing -- Edit this bug report at http://bugs.php.net/?id=36808edit=1
#36809 [Opn-Asn]: __FILE__ behavior changed between last week and this week
ID: 36809 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: linux (gentoo) PHP Version: 5CVS-2006-03-20 (CVS) Assigned To: dmitry New Comment: Yes, I guess it's related to the optimization hacks done ~week ago, related to runtime constants fetching etc. Dmitry, please check it out. Previous Comments: [2006-03-21 00:02:58] [EMAIL PROTECTED] [16:49:22] tony2002 fill the report and assign it to Dmitry [16:49:41] tony2002 it's definitely related to the hacks he did recently [2006-03-21 00:02:24] [EMAIL PROTECTED] Description: if test.php is: ?php echo __FILE__; ? running php test.php used to spit out the full path to test.php, now it just spits out test.php note that php -r include 'test.php'; spits out the whole path to test.php -- Edit this bug report at http://bugs.php.net/?id=36809edit=1
#36799 [Bgs]: Short cirquit AND evaluates like OR
ID: 36799
Updated by: [EMAIL PROTECTED]
Reported By: cleo at anarki dot dk
Status: Bogus
Bug Type: *General Issues
Operating System: WinXP, Mandriva Linux 2006
PHP Version: 5.1.2
New Comment:
The whole point of 'and','or' is to be the low-precedence version of
'', '||'. If you want high-precedence, use .
Previous Comments:
[2006-03-20 20:05:03] [EMAIL PROTECTED]
http://www.php.net/manual/en/language.operators.php#language.operators.precedence
[2006-03-20 19:59:05] cleo at anarki dot dk
All right,
( (p1) and (p2) )
evaluates correctly,
but that doesn't change the fact, that
(p1) and (p2)
evaluates totally wrongly.
And I don't see the difference.
Neither from a mathematician's nor a computer scientist's point of
view.
Therefore, I still strongly argue, that this is a bug in PHP's way of
evaluating boolean expressions.
Best regards
Claus Holm from Copenhagen
[2006-03-20 18:09:23] [EMAIL PROTECTED]
$h = 25;
$res = (($h=0) and ($h=23));
[2006-03-20 17:47:15] cleo at anarki dot dk
Description:
Consider the following piece of code:
$res= ($h=0) and ($h=23);
It could be used to determine if a user has submitted an hour between 0
and 23.
However, if the user enters 25, then the function evaluates to
true
If you reverse the order of the operands like this:
$res = ($h=23) and ($h=0);
...then a $h value of 25 will make the function evaluate to false.
But now -1 will make it evaluate to true!
So clearly, this must be a major bug.
Best regards
Claus Holm, Copenhagen, Denmark
Reproduce code:
---
? if (isset($_POST['test'])) {
$hours= $_POST['e_hours'];
$hours= (integer)$hours;
echo You entered $hours br;
echo 'Now we test: ($hours=0) and ($hours=23)br';
$test1= ($hours=0) and ($hours=23);
echo $test1 ? ok : nope;
echo br;
echo 'And now we test: ($hours=23)and($hours=0)br';
$test2= ($hours=23) and ($hours=0);
echo $test2 ? ok : nope;
}
else {
? Input an hour between 0 and 23:br
FORM action=?=$_SERVER['PHP_SELF']? method=post
INPUT type=text name=e_hours value=br
INPUT type=submit name=test value=Run test
/form
?}
?
Expected result:
If the value 25 is entered, then I should see this:
You entered 25
Now we test: ($hours=0) and ($hours=23)
nope
And now we test: ($hours=23) and ($hours=0)
nope
Actual result:
--
You entered 25
Now we test: ($hours=0) and ($hours=23)
ok
And now we test: ($hours=23) and ($hours=0)
nope
--
Edit this bug report at http://bugs.php.net/?id=36799edit=1
#36689 [Asn-Csd]: syslog() truncates messages
ID: 36689 Updated by: [EMAIL PROTECTED] Reported By: timb at photoshelter dot com -Status: Assigned +Status: Closed Bug Type: Unknown/Other Function Operating System: linux PHP Version: 5.1.2 Assigned To: stas New Comment: 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. Previous Comments: [2006-03-11 15:08:04] [EMAIL PROTECTED] Stas introduced that limitation while fixing a format string exploit, he probably knows best. [2006-03-11 00:16:39] timb at photoshelter dot com Description: the PHP function syslog() truncates messages at 500 characters. it should not truncate at all or the length at which truncation happens should be user definable. -- Edit this bug report at http://bugs.php.net/?id=36689edit=1
#36810 [NEW]: ini_set() returns FALSE, even upon success, if the option wasn't set in php.ini
From: djslakor at hotmail dot com Operating system: win32 PHP version: 4CVS-2006-03-21 (snap) PHP Bug Type: PHP options/info functions Bug description: ini_set() returns FALSE, even upon success, if the option wasn't set in php.ini Description: In my example, I wanted to modify the user_agent fopen wrapper option in order to spoof a user_agent (obviously). In my current php.ini configuration, the user_agent line is commented out. When issuing ini_set(user_agent, Mozilla), for example, the function returns false, although it succeeds. The documentation states the function is to return the previous value for the option, however, in this case, since the option was not set to begin with, it returns false, which indicates failure (although the call was a success). This does not make sense. Reproduce code: --- Pre-req: user_agent must be commented out in php.ini $blah = ini_set(user_agent, Mozilla); var_dump($blah); Expected result: I expect the function to successfully set user_agent to Mozilla, which in this case it does, and return something other than false, which indicates failure. [3 Sep 2002 3:54pm CEST] [EMAIL PROTECTED] What's the bug here? If some ini setting is not set at all, what should be returned else than false? Response: Perhaps if the option is not already set, instead of returning false, it should simply return the value you just set the option to. This would be better than indicating a failure when one doesn't exist. Actual result: -- Returns false. -- Edit bug report at http://bugs.php.net/?id=36810edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36810r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36810r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36810r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36810r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36810r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36810r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36810r=needscript Try newer version:http://bugs.php.net/fix.php?id=36810r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36810r=support Expected behavior:http://bugs.php.net/fix.php?id=36810r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36810r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36810r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36810r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36810r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36810r=dst IIS Stability:http://bugs.php.net/fix.php?id=36810r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36810r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36810r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36810r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36810r=mysqlcfg
#36800 [Com]: nit-pick - oci8_interface.c returns VARCHAR not VARCHAR2
ID: 36800 Comment by: cjbj at hotmail dot com Reported By: jnavratil at houston dot rr dot com Status: Open Bug Type: Feature/Change Request Operating System: Fedora Core 4.2 PHP Version: 5.1.2 New Comment: The Oracle 10.2 manuals state: Although the VARCHAR datatype is currently synonymous with VARCHAR2, the VARCHAR datatype is scheduled to be redefined as a separate datatype used for variable-length character strings compared with different comparison semantics. Previous Comments: [2006-03-20 18:16:57] jnavratil at houston dot rr dot com Description: (extreme nit-pick) oci_field_type returns 'VARCHAR' for a SQLT_CHR. It should more accurately return 'VARCHAR2' as 'VARCHAR' is deprecated. -- Edit this bug report at http://bugs.php.net/?id=36800edit=1
#34005 [Asn]: ocipasswordchange() fails
ID: 34005 Updated by: [EMAIL PROTECTED] Reported By: uherj at avx dot cz Status: Assigned Bug Type: OCI8 related Operating System: * PHP Version: 5CVS, 4CVS (2005-12-25) (snap) Assigned To: tony2001 New Comment: Hi, I heard about this very problem from my collegue just the other day. The weird fact is that I actually have added OCIPasswordChange() function myself yet in PHP v4.3.2 ad it really is a straight-forward function - it simply passes the data from and to OCI's OCIPasswordChange call. So there is no interacion with the data submitted. I still have no clear solution but I am guessing that this may relay to OCI itself, not really PHP's OCI8 extension. Anyone has any ideas? ORA-28002 is simply a warning that that your old password is about to expire, cant' there be something set for you that disallows you to change the password during the Grace Period? Did you try changing the password in PL/SQL to see if it's doable for your case? Are there any funny characters in your old password that can be interpreted wrongly? If so, try replicating the problem with a password made of [a-z0-9] and see if problem persists.. Nothing else comes to my mind Let me know. maxim Previous Comments: [2006-01-05 23:55:07] [EMAIL PROTECTED] No. Feel free to provide one. [2006-01-05 23:40:48] gcombe at co dot weber dot ut dot us so is there a fix for this or not? [2005-12-26 17:26:27] [EMAIL PROTECTED] Assuming this happens also with new oci code. [2005-08-05 13:40:04] uherj at avx dot cz this bug shows only when user account return warning: Warning: ocilogon(): OCISessionBegin: OCI_SUCCESS_WITH_INFO: ORA-28002: the password will expire within 10 day [2005-08-05 10:54:46] [EMAIL PROTECTED] FYI ocipasswordchange() passes correct string to OCI funcs. No idea why it fails. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34005 -- Edit this bug report at http://bugs.php.net/?id=34005edit=1
#30804 [Asn]: multiple returned lob resource being overwritten
ID: 30804
Updated by: [EMAIL PROTECTED]
Reported By: michael dot caplan at lechateau dot ca
Status: Assigned
Bug Type: OCI8 related
Operating System: RHE 3
PHP Version: 5CVS-2005-04-05
Assigned To: tony2001
New Comment:
Well,
echo $row['CLOB_TEXT']-load();
is not exactly the same as
$res[] = $row['CLOB_TEXT'];
In the last one you are assigning the whole object to an element of an
array. This may be the reason it overwrites all the rest.
Try this:
$res[] = $row['CLOB_TEXT']-load();
and the print as
foreach($res as $r) {
echo $r . \r\n;
}
Just my guess.
maxim
Previous Comments:
[2005-04-06 21:35:25] michael dot caplan at lechateau dot ca
It was a little difficult to test -- php kept on segfaulting with the
DB abstraction lib I normaily use. I tried a new test as follows, but
unfortunately I had the same results:
CREATE TABLE INTRANET.CLOB_TEST
(ID NUMBER NOT NULL ENABLE,
TEXT_TEXT VARCHAR2(500) NOT NULL ENABLE,
CLOB_TEXT CLOB,
PRIMARY KEY (ID)
)
ID TEXT_TEXT CLOB_TEXT
-- - -
1 text1 this is a clob of text1
2 text2 this is a clob of text2
3 text3 this is a clob of text3
4 text4 this is a clob of text4
5 text5 this is a clob of text5
?php
$db = ocinlogon('intranet', 'stidemoron', 'webdev');
$query = 'select
ID,
TEXT_TEXT,
CLOB_TEXT
from
CLOB_TEST';
$stmt = ociparse($db, $query);
ociexecute($stmt);
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
echo $row['ID'] . \r\n;
echo $row['TEXT_TEXT'] . \r\n;
echo $row['CLOB_TEXT']-load() . \r\n;
}
echo 2-\r\n;
$stmt = ociparse($db, $query);
ociexecute($stmt);
$res = array();
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
$res[] = $row['CLOB_TEXT'];
}
foreach($res as $r) {
echo $r-load() . \r\n;
}
?
results:
1
text1
this is a clob of text1
2
text2
this is a clob of text2
3
text3
this is a clob of text3
4
text4
this is a clob of text4
5
text5
this is a clob of text5
2-
this is a clob of text5
this is a clob of text5
this is a clob of text5
this is a clob of text5
this is a clob of text5
[2004-11-16 14:48:26] michael dot caplan at lechateau dot ca
Description:
I'm not 100% sure if this is a bug, or just a 'quirk', but my attempt
to get feedback on this issue on the php db support list was
unsuccessful. So, here I am
I am selecting multiple columns from a table, one being a clob. the
query returns multiple records for the query. The results are all
good, execpt the clob column in certain circumstances.
Normally, with such a db return, I would loop through the results and
grab the clobs one by one. Under 'special' circumstances, I would want
to first loop throught the results and assign the results to a new array
before fetching the clob. This is where things get funky. In this
senario, the last returned record's clob column overwrites all previous
clob columns (all the previous records have there unique data, except
the clob columns which contains the data for the last record across all
previous records).
A working example:
$query = 'select
id,
author,
cdate,
views,
title,
message,
top
from
APP_THREADS
where
TYPE = \'D\'';
$stmt = ociparse($fw_db-connection, $query);
ociexecute($stmt);
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
echo $row['MESSAGE']-load();
echo $row['id'];
// etc
}
as expected, I get all clobs from the result set. But in this example,
I do not:
$query = 'select
id,
author,
cdate,
views,
title,
message,
top
from
APP_THREADS
where
TYPE = \'D\'';
$stmt = ociparse($fw_db-connection, $query);
ociexecute($stmt);
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
// assign all lob resources to array for later loading
$messages[] = $row['MESSAGE'];
}
foreach ($messages as $message) {
echo $message-load();
}
In this example, the last assigned lob resource overwrites all previous
lob resources. When fetching the clob content later on, each record
returns the data from the last lob.
I am pretty unawair of the internal mechanics of how resources are
handled, and this just might be a quirk of how db result resources for
oci8 are handled, and is unavoidable. (it looks like one resource is
returned for all lobs, not multiple resources for each lob).
However, it is
#36811 [NEW]: strtotime () causes apache segmentation fault
From: gaius dot julius at gmail dot com Operating system: Fedora PHP version: 4.4.2 PHP Bug Type: Date/time related Bug description: strtotime () causes apache segmentation fault Description: if used frequently in same script, strtotime causes segmentation fault or demages datastructures in memory. behaviour like that i'v often seen in, for example, C++ applications with memleaks/incorrect work with pointers/writing by pointers into already freed memory. -- Edit bug report at http://bugs.php.net/?id=36811edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36811r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36811r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36811r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36811r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36811r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36811r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36811r=needscript Try newer version:http://bugs.php.net/fix.php?id=36811r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36811r=support Expected behavior:http://bugs.php.net/fix.php?id=36811r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36811r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36811r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36811r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36811r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36811r=dst IIS Stability:http://bugs.php.net/fix.php?id=36811r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36811r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36811r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36811r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36811r=mysqlcfg
