Bug #53818 [Com]: Missing info in pg_get_notify function
Edit report at https://bugs.php.net/bug.php?id=53818&edit=1
ID: 53818
Comment by: timosha at gmail dot com
Reported by:r dot i dot k at free dot fr
Summary:Missing info in pg_get_notify function
Status: Closed
Type: Bug
Package:PostgreSQL related
Operating System: Linux
PHP Version:5.2.17
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
Please backport this patch to 5.3.x. :)
Previous Comments:
[2011-01-27 17:02:36] il...@php.net
This bug has been fixed in SVN.
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.
[2011-01-22 19:32:25] r dot i dot k at free dot fr
Description:
Since Postgresql 9.0, event notifications fired by the NOTIFY sql command
includes a payload (a 8000 bytes max piece of text).
As of now, the PHP function pg_get_notify only retrieve the "channel" (name of
the notification) and the backend pid.
The attached patch improves this situation by adding the payload to the
returned array of the pg_get_notify function, when the connected PG backend
version is at least 9.0.
Hope it helps...
Test script:
---
$dbconn = pg_connect(...) ; // To be completed
pg_query($dbconn, "LISTEN toto");
pg_query($dbconn, "NOTIFY toto, 'Hello world !'");
$notify = pg_get_notify($dbconn, PGSQL_ASSOC) ;
print_r($notify) ;
Expected result:
// Array("message" => "toto", "pid" => 12345, "payload" => "Hello world !")
Actual result:
--
// Array("message" => "toto", "pid" => 12345)
--
Edit this bug report at https://bugs.php.net/bug.php?id=53818&edit=1
Bug #54446 [Opn->Csd]: Arbitrary file creation via libxslt 'output' extension
Edit report at https://bugs.php.net/bug.php?id=54446&edit=1
ID: 54446
Updated by: fel...@php.net
Reported by:nicolas dot gregoire at agarri dot fr
Summary:Arbitrary file creation via libxslt 'output'
extension
-Status: Open
+Status: Closed
Type: Bug
Package:XSLT related
Operating System: All
PHP Version:5.3.6
Assigned To:chregu
Block user comment: N
Private report: N
Previous Comments:
[2011-10-11 05:18:13] chr...@php.net
This bug has been fixed in SVN.
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.
[2011-10-11 05:09:43] chr...@php.net
It's now als in the PHP 5.3.x branch (will be in 5.3.9). We couldn't use the
same approach as in PHP 5.4 due to ABI compatibility problems. We had to
introduce an ini option. Here's a code example, which works in 5.3 (actually
anything >= 5.0) and 5.4 for writing from within XSLT.
***
$xsl = new XSLTProcessor();
//if you want to write from within the XSLT
if (version_compare(PHP_VERSION,'5.4',"<")) {
$oldval = ini_set("xsl.security_prefs",XSL_SECPREFS_NONE);
} else {
$oldval = $xsl->setSecurityPreferences(XSL_SECPREFS_NONE);
}
$xsl->transformToXml(...);
//go back to the old setting. Better safe than sorry
if (version_compare(PHP_VERSION,'5.4',"<")) {
ini_set("xsl.security_prefs",$oldval);
} else {
$xsl->setSecurityPreferences($oldval);
//or just do
// $xsl = null;
// to get away of this object
}
[2011-10-05 18:11:06] chr...@php.net
Automatic comment from SVN on behalf of chregu
Revision: http://svn.php.net/viewvc/?view=revision&revision=317801
Log: Added test for Bug 54446
Init a variable to a default value to avoid issues
[2011-10-05 09:55:39] chr...@php.net
Automatic comment from SVN on behalf of chregu
Revision: http://svn.php.net/viewvc/?view=revision&revision=317759
Log: Added xsl.security_prefs ini option to define forbidden operations within
XSLT
stylesheets, default is not to enable write operations. This option won't be
in 5.4, since there's a new method. Bug #54446
[2011-09-12 12:44:34] chr...@php.net
Automatic comment from SVN on behalf of chregu
Revision: http://svn.php.net/viewvc/?view=revision&revision=316530
Log: Added test for XSL bug 54446
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
https://bugs.php.net/bug.php?id=54446
--
Edit this bug report at https://bugs.php.net/bug.php?id=54446&edit=1
Bug #60048 [Opn->Csd]: sa_len a #define on IRIX
Edit report at https://bugs.php.net/bug.php?id=60048&edit=1
ID: 60048
Updated by: fel...@php.net
Reported by:china at thewrittenword dot com
Summary:sa_len a #define on IRIX
-Status: Open
+Status: Closed
Type: Bug
Package:Sockets related
Operating System: IRIX 6.5
PHP Version:5.3.8
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-10-13 07:50:48] china at thewrittenword dot com
Description:
on IRIX 6.5 defines sa_len as:
#define sa_len sa_union.sa_generic.sa_len2
Because of this, socket_accept() in ext/sockets/sockets.c cannot be compiled on
this platform because it uses sa_len as a variable:
PHP_FUNCTION(socket_accept)
{
zval *arg1;
php_socket *php_sock, *new_sock;
php_sockaddr_storage sa;
socklen_tsa_len = sizeof(sa);
The obvious fix is to rename "sa_len" to something like php_sa_len.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60048&edit=1
Bug #55814 [Opn->Asn]: stream_socket_recvfrom() “randomly” returns false
Edit report at https://bugs.php.net/bug.php?id=55814&edit=1 ID: 55814 Updated by: paj...@php.net Reported by:ivan dot enderlin at hoa-project dot net Summary:stream_socket_recvfrom() ârandomlyâ returns false -Status: Open +Status: Assigned Type: Bug Package:Streams related Operating System: Windows 7 PHP Version:Irrelevant -Assigned To: +Assigned To:mattficken Block user comment: N Private report: N New Comment: Matt, please analyze that one. Previous Comments: [2011-09-29 14:23:07] ivan dot enderlin at hoa-project dot net Description: Sometimes, on Windows7 with PHP5.3+, stream_socket_recvfrom() returns false (the documentation says that it always returns a string but the source code says the opposite, it can return false), and I have no idea why. It happens only on Windows7 a priori. Basically, I have a client and a server as bellow. Test script: --- Client.php https://bugs.php.net/bug.php?id=55814&edit=1
Bug #60058 [Opn]: No way to upload long code samples in a bug report
Edit report at https://bugs.php.net/bug.php?id=60058&edit=1 ID: 60058 Updated by: paj...@php.net Reported by:david dot gero at ec dot gc dot ca Summary:No way to upload long code samples in a bug report Status: Open Type: Bug Package:Website problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Yes, we should allow that and disable php execution :) In the meantime you can attach it as text, script.txt instead of .php. Previous Comments: [2011-10-13 20:46:13] david dot gero at ec dot gc dot ca Description: The Description: section of the bug report screen says "upload patches and/or long code samples below", presumably in the Patch file: section with the "Browse" button. However, if you try to upload a .php file, it complains that the file is "text/x-php", which for some reason it doesn't consider to be text. Please fix it to allow "text/x-php" to be uploaded. The levels of authorization needed to create a publicly accessible URL on a government web site remove the possibility of "provide a URL to the source code that will reproduce the bug". -- Edit this bug report at https://bugs.php.net/bug.php?id=60058&edit=1
[PHP-BUG] Bug #60058 [NEW]: No way to upload long code samples in a bug report
From: Operating system: PHP version: Irrelevant Package: Website problem Bug Type: Bug Bug description:No way to upload long code samples in a bug report Description: The Description: section of the bug report screen says "upload patches and/or long code samples below", presumably in the Patch file: section with the "Browse" button. However, if you try to upload a .php file, it complains that the file is "text/x-php", which for some reason it doesn't consider to be text. Please fix it to allow "text/x-php" to be uploaded. The levels of authorization needed to create a publicly accessible URL on a government web site remove the possibility of "provide a URL to the source code that will reproduce the bug". -- Edit bug report at https://bugs.php.net/bug.php?id=60058&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60058&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60058&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60058&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60058&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60058&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60058&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60058&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60058&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60058&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60058&r=support Expected behavior: https://bugs.php.net/fix.php?id=60058&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60058&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60058&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60058&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60058&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60058&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60058&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60058&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60058&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60058&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60058&r=mysqlcfg
Bug #60056 [Opn]: Basic authorization crashes Windows CLI web server
Edit report at https://bugs.php.net/bug.php?id=60056&edit=1 ID: 60056 User updated by:david dot gero at ec dot gc dot ca Reported by:david dot gero at ec dot gc dot ca Summary:Basic authorization crashes Windows CLI web server Status: Open Type: Bug -Package:CGI/CLI related +Package:Built-in web server Operating System: Windows XP PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Package: should be PHP built-in web server related Previous Comments: [2011-10-13 20:10:14] david dot gero at ec dot gc dot ca The second error probably happens on lines 1766 and 1869 of sapi/cli/php_cli_server.c where you are using Z_STRVAL_PP(val) instead of just *val request.headers are strings, not Z_STRs Look at the other examples of zend_hash_find in php_cli_server.c [2011-10-13 19:13:29] david dot gero at ec dot gc dot ca The first error happens at line 805 of main/SAPI.c [2011-10-13 16:45:34] david dot gero at ec dot gc dot ca Sigh. Your bug system wouldn't let me upload the PHP file, saying it was "text/x-php", which apparently isn't text. So here it is: 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. ', PHP_EOL, $_SERVER['SERVER_SIGNATURE'], PHP_EOL; ?> Basic Authorization Test Basic Authorization Test Success! You have been authorized as user: [2011-10-13 16:37:50] david dot gero at ec dot gc dot ca Description: The attached "Patch file" is actually a PHP program that shows the problem. Command line was: php -S 127.0.0.1:8000 -t \html In a browser, goto http://localhost:8000/basic-auth-test.php 1. First error is that the browser's authorization request displays "at 0" instead of "at Admin Area", meaning the PHP CLI server is not sending the realm correctly. 2. Second error is that the PHP CLI server crashes when the browser sends the Authorization: Basic Test script: --- Patch file below is test script Expected result: Expect the PHP CLI server not to crash, and to see the following at the browser: Success! You have been authorized as user: foo Actual result: -- Windows PHP CLI server crashes -- Edit this bug report at https://bugs.php.net/bug.php?id=60056&edit=1
Bug #59095 [Com]: setGravity() and setImageGravity() have no effekt on compositeImage()
Edit report at https://bugs.php.net/bug.php?id=59095&edit=1 ID: 59095 Comment by: Dmoreno92 at hotmail dot com Reported by:mail+pecl at rodneyrehm dot de Summary:setGravity() and setImageGravity() have no effekt on compositeImage() Status: Suspended Type: Bug Package:imagick Operating System: Mac OS X 10.6.2 PHP Version:5.3.1 Block user comment: N Private report: N New Comment: Hey everyone it me once again Danny Moreno so want to you know i never subscribe php because done before i went on the website not newspaper one more thing thank you member of the php team so i think is it any questions about me send facebook text messages or e-mail so better luck next time peace. Previous Comments: [2010-03-12 18:16:06] mkoppa...@php.net Moved to here: http://www.imagemagick.org/discourse-server/viewtopic.php?f=6&t=15763 [2010-03-02 17:12:06] mail+pecl at rodneyrehm dot de I just tested the issue with Imagick 3.0.0RC1 and got the same (wrong) result. [2010-03-02 12:22:14] mail+pecl at rodneyrehm dot de Description: The following command places the watermark.png nicely in the lower right corner of original.jpg: composite -gravity SouthEast -geometry "+0+0" 'watermark.png' 'original.jpg' 'output.jpg' Trying the to get the same result with Imagick fails, though: setImageGravity( Imagick::GRAVITY_SOUTHEAST ); $im->compositeImage( $wm, Imagick::COMPOSITE_DEFAULT, 0, 0 ); $im->writeImage( 'output.jpg' ); ?> Doing a getImageGravity() ); ?> gives me »int 9, int 9« - which tells me the gravity is set properly. Thus I guess compositeImage() simply ignores the gravity attribute. Some info from phpinfo(): imagick module version: 2.3.0 ImageMagick version: ImageMagick 6.6.0-0 2010-03-02 Q16 Reproduce code: --- setImageGravity( Imagick::GRAVITY_SOUTHEAST ); $im->compositeImage( $wm, Imagick::COMPOSITE_DEFAULT, 0, 0 ); $im->writeImage( 'output.jpg' ); ?> Expected result: watermark.png placed in bottom right corner on top of original.jpg Actual result: -- watermark.png placed in top left corner on top of original.jpg -- Edit this bug report at https://bugs.php.net/bug.php?id=59095&edit=1
Bug #60056 [Com]: Basic authorization crashes Windows CLI web server
Edit report at https://bugs.php.net/bug.php?id=60056&edit=1 ID: 60056 Comment by: david dot gero at ec dot gc dot ca Reported by:david dot gero at ec dot gc dot ca Summary:Basic authorization crashes Windows CLI web server Status: Open Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: The second error probably happens on lines 1766 and 1869 of sapi/cli/php_cli_server.c where you are using Z_STRVAL_PP(val) instead of just *val request.headers are strings, not Z_STRs Look at the other examples of zend_hash_find in php_cli_server.c Previous Comments: [2011-10-13 19:13:29] david dot gero at ec dot gc dot ca The first error happens at line 805 of main/SAPI.c [2011-10-13 16:45:34] david dot gero at ec dot gc dot ca Sigh. Your bug system wouldn't let me upload the PHP file, saying it was "text/x-php", which apparently isn't text. So here it is: 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. ', PHP_EOL, $_SERVER['SERVER_SIGNATURE'], PHP_EOL; ?> Basic Authorization Test Basic Authorization Test Success! You have been authorized as user: [2011-10-13 16:37:50] david dot gero at ec dot gc dot ca Description: The attached "Patch file" is actually a PHP program that shows the problem. Command line was: php -S 127.0.0.1:8000 -t \html In a browser, goto http://localhost:8000/basic-auth-test.php 1. First error is that the browser's authorization request displays "at 0" instead of "at Admin Area", meaning the PHP CLI server is not sending the realm correctly. 2. Second error is that the PHP CLI server crashes when the browser sends the Authorization: Basic Test script: --- Patch file below is test script Expected result: Expect the PHP CLI server not to crash, and to see the following at the browser: Success! You have been authorized as user: foo Actual result: -- Windows PHP CLI server crashes -- Edit this bug report at https://bugs.php.net/bug.php?id=60056&edit=1
Bug #55848 [Csd->Bgs]: openssl doesn't work with unix sockets
Edit report at https://bugs.php.net/bug.php?id=55848&edit=1 ID: 55848 Updated by: paj...@php.net Reported by:mattfic...@php.net Summary:openssl doesn't work with unix sockets -Status: Closed +Status: Bogus Type: Bug Package:OpenSSL related Operating System: Windows PHP Version:5.4.0beta1 Assigned To:pajoye Block user comment: N Private report: N New Comment: Configuration issue caused by some minor diffs between 5.4 and 5.4 Previous Comments: [2011-10-12 17:37:39] paj...@php.net The PDO and SSL issue in 5.3.8 is already fixed in SVN, it was due to a typo in a #ifdef. [2011-10-12 17:32:31] mattfic...@php.net After tracing the problem, I figured out it was a problem in my configuration. Mysqlnd with SSL works on PHP 5.4.0 for me now, through both mysql, mysqli and PDO (therefore I'm closing this bug). Note, that on PHP 5.3.8, mysql and SSL fail for me when I try to use PDO. However, it works on 5.3.8 through mysql and mysqli. [2011-10-10 20:47:00] and...@php.net Matt, the error message comes from two places both in PHP. Once wenn crypto is set up and then when enabled. It probably barks already during set up and this got to be traced. I can't reproduce it here on Linux. Is it possible go trace it in a debugger and see which parts of the streams return NOT_IMPL for the stream? Thanks! [2011-10-10 20:08:43] and...@php.net PHP 5.3 and 5.4, and probably trunk, don't support SSL over Unix Sockets. Sorry! mysqlnd tries to set up SSL and PHP barks that this stream type doesn't support crypto. As workaround: you have to go back using libmysql, where SSL over Unix Sockets works. [2011-10-08 09:39:35] pajoye @php.net This bug due to this typo was only in 5.3, 5.4 and trunk were not affected as far as I can see 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 https://bugs.php.net/bug.php?id=55848 -- Edit this bug report at https://bugs.php.net/bug.php?id=55848&edit=1
Bug #60056 [Com]: Basic authorization crashes Windows CLI web server
Edit report at https://bugs.php.net/bug.php?id=60056&edit=1 ID: 60056 Comment by: david dot gero at ec dot gc dot ca Reported by:david dot gero at ec dot gc dot ca Summary:Basic authorization crashes Windows CLI web server Status: Open Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: The first error happens at line 805 of main/SAPI.c Previous Comments: [2011-10-13 16:45:34] david dot gero at ec dot gc dot ca Sigh. Your bug system wouldn't let me upload the PHP file, saying it was "text/x-php", which apparently isn't text. So here it is: 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. ', PHP_EOL, $_SERVER['SERVER_SIGNATURE'], PHP_EOL; ?> Basic Authorization Test Basic Authorization Test Success! You have been authorized as user: [2011-10-13 16:37:50] david dot gero at ec dot gc dot ca Description: The attached "Patch file" is actually a PHP program that shows the problem. Command line was: php -S 127.0.0.1:8000 -t \html In a browser, goto http://localhost:8000/basic-auth-test.php 1. First error is that the browser's authorization request displays "at 0" instead of "at Admin Area", meaning the PHP CLI server is not sending the realm correctly. 2. Second error is that the PHP CLI server crashes when the browser sends the Authorization: Basic Test script: --- Patch file below is test script Expected result: Expect the PHP CLI server not to crash, and to see the following at the browser: Success! You have been authorized as user: foo Actual result: -- Windows PHP CLI server crashes -- Edit this bug report at https://bugs.php.net/bug.php?id=60056&edit=1
[PHP-BUG] Bug #60057 [NEW]: declare(encoding="UTF-8")=="Unsupported encoding"
From: Operating system: Vista Home Premium SP2 PHP version: 5.4.0beta1 Package: Unicode Engine related Bug Type: Bug Bug description:declare(encoding="UTF-8")=="Unsupported encoding" Description: This is on the precompiled Windows QA NTS build 2011-Sep-15 14:27:38, running on Apache 2.2 as CGI. Multibyte support is now included by default, and my php.ini file includes "zend.multibyte = On" as a directive. Any script that includes the line declare(encoding="UTF-8"); Triggers this warning: Warning: Unsupported encoding [UTF-8] in XXX on line YYY I have tried changing case and removing the dash. Presuming this derives from the same functionality as Multibyte Strings, this should be the correct name for this encoding: http://us2.php.net/manual/en/mbstring.supported-encodings.php Test script: --- declare(encoding="UTF-8"); Expected result: Silent parsing of the script as UTF-8. Actual result: -- Warning: Unsupported encoding [UTF8] in H:\webserver\pd\wwwroot\qwertyuiop\index.php on line 1 -- Edit bug report at https://bugs.php.net/bug.php?id=60057&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60057&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60057&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60057&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60057&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60057&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60057&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60057&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60057&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60057&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60057&r=support Expected behavior: https://bugs.php.net/fix.php?id=60057&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60057&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60057&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60057&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60057&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60057&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60057&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60057&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60057&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60057&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60057&r=mysqlcfg
Bug #54379 [Com]: PDO_OCI: UTF-8 output gets truncated
Edit report at https://bugs.php.net/bug.php?id=54379&edit=1
ID: 54379
Comment by: info-phpbug at ch2o dot info
Reported by:sms at inbox dot ru
Summary:PDO_OCI: UTF-8 output gets truncated
Status: Open
Type: Bug
Package:PDO related
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
i've issued the same bug with different version of oracle client (10.2) and the
patch i've resolved the problem.
Previous Comments:
[2011-08-06 08:17:20] mitans02 at gmail dot com
I have same problem with UTF8 database and UTF8 client.
PDO_OCI should set string buffer length correct to handling UTF8.
Check also oracle OCI documents below:
http://download.oracle.com/docs/cd/B10500_01/server.920/a96529/ch6.htm#1004620
- Database settings
SQL>
1 SELECT PARAMETER, VALUE
2FROM NLS_DATABASE_PARAMETERS
3* WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET')
PARAMETER VALUE
-- --
NLS_CHARACTERSET AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16
- Table for test
CREATE TABLE mytable (col1 NVARCHAR2(20));
- Test data
INSERT INTO mytable VALUES('12345678901234567890'); /* 20 signle byte char */
INSERT INTO mytable
VALUES('ããããããããããããããããã¡ã¤ã¦ã¨'); /* 20
double byte char, Japanese */
- Test Program
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$stmt = $db->prepare("SELECT * FROM mytable");
$stmt->execute();
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
?>
- Test Program Output
# php ocitest.php
NLS_LANG=Japanese_Japan.AL32UTF8
Warning: PDOStatement::fetchAll(): column 0 data was too large for buffer and
was truncated to fit it in /root/ocitest.php on line 9
array(2) {
[0]=>
array(1) {
["COL1"]=>
string(20) "12345678901234567890"
}
[1]=>
array(1) {
["COL1"]=>
string(40) "ããããããããããããã
}
}
- Client Environment
# uname -a
Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:35 EDT 2010
i686 i686 i386 GNU/Linux
# rpm -qa | grep oracle
oracle-instantclient11.2-devel-11.2.0.2.0-1
oracle-instantclient11.2-sqlplus-11.2.0.2.0-1
oracle-instantclient11.2-basic-11.2.0.2.0-1
# php -v
PHP 5.3.6 (cli) (built: Aug 5 2011 09:15:02)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
- Suggest fix
Patch to oci_statement.c
# diff -u oci_statement.c oci_statement.c.new
--- oci_statement.c 2011-08-06 01:07:53.0 -0700
+++ oci_statement.c.new 2011-08-06 01:08:03.0 -0700
@@ -529,7 +529,7 @@
(param, OCI_DTYPE_PARAM, &colname, &namelen,
OCI_ATTR_NAME, S->err));
col->precision = scale;
- col->maxlen = data_size;
+ col->maxlen = ( data_size + 1 ) * sizeof(utext);
col->namelen = namelen;
col->name = estrndup((char *)colname, namelen);
[2011-03-25 04:39:19] sms at inbox dot ru
Description:
Data is stored in ANSI charset (CL8MSWIN1251) while connection uses UTF-8.
PDOStatement::fetchAll() generates warning and fields containing non-english
characters gets truncated. For example, PDO outputs only 53 UTF-8 russian
characters for VARCHAR2(100) field.
MySQL's PDOStatement::fetchAll() works fine in the same situation.
Test script:
---
$pdo = new PDO('oci:dbname=[host];charset=UTF8', '[user]', '[pass]');
$cmd = $pdo->query('SELECT * FROM user');
var_dump($cmd->fetchAll());
Expected result:
Table field(s) not truncated, no warnings
Actual result:
--
Table field(s) gets truncated, PHP warning:
PDOStatement::fetchAll() [pdostatement.fetchall]: column 0 data was too
large for buffer and was truncated to fit it
--
Edit this bug report at https://bugs.php.net/bug.php?id=54379&edit=1
Bug #60056 [Opn]: Basic authorization crashes Windows CLI web server
Edit report at https://bugs.php.net/bug.php?id=60056&edit=1 ID: 60056 User updated by:david dot gero at ec dot gc dot ca Reported by:david dot gero at ec dot gc dot ca Summary:Basic authorization crashes Windows CLI web server Status: Open Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: Sigh. Your bug system wouldn't let me upload the PHP file, saying it was "text/x-php", which apparently isn't text. So here it is: 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. ', PHP_EOL, $_SERVER['SERVER_SIGNATURE'], PHP_EOL; ?> Basic Authorization Test Basic Authorization Test Success! You have been authorized as user: Previous Comments: [2011-10-13 16:37:50] david dot gero at ec dot gc dot ca Description: The attached "Patch file" is actually a PHP program that shows the problem. Command line was: php -S 127.0.0.1:8000 -t \html In a browser, goto http://localhost:8000/basic-auth-test.php 1. First error is that the browser's authorization request displays "at 0" instead of "at Admin Area", meaning the PHP CLI server is not sending the realm correctly. 2. Second error is that the PHP CLI server crashes when the browser sends the Authorization: Basic Test script: --- Patch file below is test script Expected result: Expect the PHP CLI server not to crash, and to see the following at the browser: Success! You have been authorized as user: foo Actual result: -- Windows PHP CLI server crashes -- Edit this bug report at https://bugs.php.net/bug.php?id=60056&edit=1
[PHP-BUG] Bug #60056 [NEW]: Basic authorization crashes Windows CLI web server
From: Operating system: Windows XP PHP version: 5.4.0beta1 Package: CGI/CLI related Bug Type: Bug Bug description:Basic authorization crashes Windows CLI web server Description: The attached "Patch file" is actually a PHP program that shows the problem. Command line was: php -S 127.0.0.1:8000 -t \html In a browser, goto http://localhost:8000/basic-auth-test.php 1. First error is that the browser's authorization request displays "at 0" instead of "at Admin Area", meaning the PHP CLI server is not sending the realm correctly. 2. Second error is that the PHP CLI server crashes when the browser sends the Authorization: Basic Test script: --- Patch file below is test script Expected result: Expect the PHP CLI server not to crash, and to see the following at the browser: Success! You have been authorized as user: foo Actual result: -- Windows PHP CLI server crashes -- Edit bug report at https://bugs.php.net/bug.php?id=60056&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60056&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60056&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60056&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60056&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60056&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60056&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60056&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60056&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60056&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60056&r=support Expected behavior: https://bugs.php.net/fix.php?id=60056&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60056&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60056&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60056&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60056&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60056&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60056&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60056&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60056&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60056&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60056&r=mysqlcfg
Bug #55801 [PATCH]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801&edit=1 ID: 55801 Patch added by: m...@php.net Reported by:mapi at pdepend dot org Summary:Behavior of unserialize has changed Status: Feedback Type: Bug Package:Variables related Operating System: Linux (Fedora 15) PHP Version:5.4.0beta1 Assigned To:mike Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318522878 URL: https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318522878 Previous Comments: [2011-10-13 14:39:40] m...@php.net Could you try attached patch, please? [2011-10-13 14:39:10] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318516750 URL: https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318516750 [2011-10-04 16:34:49] mapi at pdepend dot org To answer your question, I did't know my initial intention about the __temp__ property, but I remember that there was a reason. But it seems that this property is obsolete now. [2011-10-04 16:20:39] mapi at pdepend dot org Cool that you came up with a reproducable, I have tried it for a couple of hours and didn't get a working reproducable outside of PHP_Depend. But is it such an uncommon use case to serialize/unserialize additional data in an object's __sleep() or __wakeup() method? [2011-10-04 14:20:46] m...@php.net So, after digging a lot, I can only see two solutions: - either disallow serialize/unserialize in __sleep/__wakeup - or revert r299770 which introduced a "persistent" state for serialize() which allowed objects which implement the Serializable interface to keep reference info through recursive calls to serialize(), see FR #36424 The issue can probably be seen as follows: serialize(obj) -> obj->__sleep does serialize() (in your code) -> then internally serialize(obj->prop) happens unserialize(obj) -> internally unserialize(obj->prop) is done -> obj->__wakeup is called which does unserialize() (your code) As you can see the IDs of the referenced objects when unserializing cannot match the IDs at serialization time, because of the mixed up call order. 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 https://bugs.php.net/bug.php?id=55801 -- Edit this bug report at https://bugs.php.net/bug.php?id=55801&edit=1
Bug #52013 [Com]: Unable to decompress files in a compressed phar.
Edit report at https://bugs.php.net/bug.php?id=52013&edit=1 ID: 52013 Comment by: janani at us dot ibm dot com Reported by:frederic dot hardy at mageekbox dot net Summary:Unable to decompress files in a compressed phar. Status: Closed Type: Bug Package:PHAR related Operating System: FreeBSD PHP Version:5.3.2 Assigned To:bjori Block user comment: N Private report: N New Comment: This issue does not seem to be fixed on my RHEL6 box with php 5.3.3 with the patch for this applied. With the patch, instead of the failure being reported in the decompressFiles(),there is an error when trying to retrieve the decompressed files in file_get_contents(). Test Results while executing test script provided in the description of this bug: > php -f test1.php PHP Warning: file_get_contents(1.php): failed to open stream: No such file or directory in /tmp/test1.php on line 29 bool(false) PHP Warning: file_get_contents(10.php): failed to open stream: No such file or directory in /tmp/test1.php on line 29 bool(false) PHP Warning: file_get_contents(11.php): failed to open stream: No such file or directory in /tmp/test1.php on line 29 bool(false) Previous Comments: [2011-09-01 09:17:51] mbecc...@php.net Issue doesn't seem to be fixed on my FreeBSD 6.2 box even using latest 5.4 HEAD. The phar_stream_copy_to_stream() call returns failure due to an error in the underlying write(). Errno is 14 (Bad address) and my feeling is that the write len ends up being actually bigger than the source buffer. [2011-08-29 14:20:28] bj...@php.net This bug has been fixed in SVN. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-08-29 14:19:44] bj...@php.net Automatic comment from SVN on behalf of bjori Revision: http://svn.php.net/viewvc/?view=revision&revision=315703 Log: Fixed bug#52013 (Unable to decompress files in a compressed phar) [2010-07-02 04:46:45] ericstew...@php.net Automatic comment from SVN on behalf of ericstewart Revision: http://svn.php.net/viewvc/?view=revision&revision=300928 Log: Added test for bug 52013 to PHP_5_3. [2010-07-02 04:45:58] ericstew...@php.net Automatic comment from SVN on behalf of ericstewart Revision: http://svn.php.net/viewvc/?view=revision&revision=300927 Log: Added test for bug 52013 to trunk. 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 https://bugs.php.net/bug.php?id=52013 -- Edit this bug report at https://bugs.php.net/bug.php?id=52013&edit=1
[PHP-BUG] Bug #60054 [NEW]: get_headers() Redirect ../../ error
From: Operating system: Ubuntu PHP version: 5.3.8 Package: HTTP related Bug Type: Bug Bug description:get_headers() Redirect ../../ error Description: When i open with: get_headers() http://www.zebis.ch/Unterricht/Fach/Unterrichtsmaterialien/dateizeigen.php?id=4070&vz=ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv&file=symmetrien.doc I got 302 Found Location => ../../schublade/ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv/docs/symmetrien.doc PHP try open: GET /Unterricht/Fach/Unterrichtsmaterialien//../../schublade/ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv/docs/symmetrien.doc But it should be: GET /Unterricht/schublade/ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv/docs/symmetrien.doc Browsers can handle that (ie, ff, chrome) this means: get_headers() dont execute ../ like browser will do. Test script: --- http://www.zebis.ch/Unterricht/Fach/Unterrichtsmaterialien/dateizeigen.php?id=4070&vz=ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv&file=symmetrien.doc'; $headers = get_headers($url, 1); print_r($headers); Expected result: GET /Unterricht/schublade/ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv/docs/symmetrien.doc Actual result: -- GET /Unterricht/Fach/Unterrichtsmaterialien//../../schublade/ME4gDDrhrBwBKVWwrrubqqAFR9r4Hv/docs/symmetrien.doc -- Edit bug report at https://bugs.php.net/bug.php?id=60054&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60054&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60054&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60054&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60054&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60054&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60054&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60054&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60054&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60054&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60054&r=support Expected behavior: https://bugs.php.net/fix.php?id=60054&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60054&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60054&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60054&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60054&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60054&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60054&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60054&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60054&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60054&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60054&r=mysqlcfg
Bug #55801 [Ana->Fbk]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801&edit=1
ID: 55801
Updated by: m...@php.net
Reported by:mapi at pdepend dot org
Summary:Behavior of unserialize has changed
-Status: Analyzed
+Status: Feedback
Type: Bug
Package:Variables related
Operating System: Linux (Fedora 15)
PHP Version:5.4.0beta1
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Could you try attached patch, please?
Previous Comments:
[2011-10-13 14:39:10] m...@php.net
The following patch has been added/updated:
Patch Name: fix-serialize-in-sleep-and-wakeup
Revision: 1318516750
URL:
https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318516750
[2011-10-04 16:34:49] mapi at pdepend dot org
To answer your question, I did't know my initial intention about the __temp__
property, but I remember that there was a reason. But it seems that this
property
is obsolete now.
[2011-10-04 16:20:39] mapi at pdepend dot org
Cool that you came up with a reproducable, I have tried it for a couple of
hours
and didn't get a working reproducable outside of PHP_Depend.
But is it such an uncommon use case to serialize/unserialize additional data in
an object's __sleep() or __wakeup() method?
[2011-10-04 14:20:46] m...@php.net
So, after digging a lot, I can only see two solutions:
- either disallow serialize/unserialize in __sleep/__wakeup
- or revert r299770 which introduced a "persistent" state for serialize()
which
allowed objects which implement the Serializable interface to keep reference
info through recursive calls to serialize(), see FR #36424
The issue can probably be seen as follows:
serialize(obj)
-> obj->__sleep does serialize() (in your code)
-> then internally serialize(obj->prop) happens
unserialize(obj)
-> internally unserialize(obj->prop) is done
-> obj->__wakeup is called which does unserialize() (your code)
As you can see the IDs of the referenced objects when unserializing cannot
match
the IDs at serialization time, because of the mixed up call order.
[2011-10-04 08:25:40] m...@php.net
Ok, now got a reproduce case:
parent ? $this->parent . "/" . $this->path : $this->path;
}
function __construct(node $parent = null, $path = ".") {
$this->parent = $parent;
$this->path = $path;
if (is_dir($this)) foreach (scandir($this) as $p) {
if ($p[0] != ".") {
$this->nodes[] = new node($this, $p);
}
}
}
function __sleep() {
$this->temp = serialize($this->nodes);
return array("path", "temp");
}
function __wakeup() {
$this->nodes = unserialize($this->temp);
$this->temp = null;
foreach ($this->nodes as $n) {
$n->parent = $this;
}
}
function createWeirdConnections() {
foreach ($this->nodes as $n) {
$a = $this->nodes;
shuffle($a);
$n->nodes[] = current($a);
}
}
}
$tree = new node(null, @$_SERVER["argv"][1] ?: ".");
$tree->createWeirdConnections();
$s = serialize($tree);
$temp = unserialize($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
https://bugs.php.net/bug.php?id=55801
--
Edit this bug report at https://bugs.php.net/bug.php?id=55801&edit=1
Bug #55801 [PATCH]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801&edit=1
ID: 55801
Patch added by: m...@php.net
Reported by:mapi at pdepend dot org
Summary:Behavior of unserialize has changed
Status: Analyzed
Type: Bug
Package:Variables related
Operating System: Linux (Fedora 15)
PHP Version:5.4.0beta1
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix-serialize-in-sleep-and-wakeup
Revision: 1318516750
URL:
https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318516750
Previous Comments:
[2011-10-04 16:34:49] mapi at pdepend dot org
To answer your question, I did't know my initial intention about the __temp__
property, but I remember that there was a reason. But it seems that this
property
is obsolete now.
[2011-10-04 16:20:39] mapi at pdepend dot org
Cool that you came up with a reproducable, I have tried it for a couple of
hours
and didn't get a working reproducable outside of PHP_Depend.
But is it such an uncommon use case to serialize/unserialize additional data in
an object's __sleep() or __wakeup() method?
[2011-10-04 14:20:46] m...@php.net
So, after digging a lot, I can only see two solutions:
- either disallow serialize/unserialize in __sleep/__wakeup
- or revert r299770 which introduced a "persistent" state for serialize()
which
allowed objects which implement the Serializable interface to keep reference
info through recursive calls to serialize(), see FR #36424
The issue can probably be seen as follows:
serialize(obj)
-> obj->__sleep does serialize() (in your code)
-> then internally serialize(obj->prop) happens
unserialize(obj)
-> internally unserialize(obj->prop) is done
-> obj->__wakeup is called which does unserialize() (your code)
As you can see the IDs of the referenced objects when unserializing cannot
match
the IDs at serialization time, because of the mixed up call order.
[2011-10-04 08:25:40] m...@php.net
Ok, now got a reproduce case:
parent ? $this->parent . "/" . $this->path : $this->path;
}
function __construct(node $parent = null, $path = ".") {
$this->parent = $parent;
$this->path = $path;
if (is_dir($this)) foreach (scandir($this) as $p) {
if ($p[0] != ".") {
$this->nodes[] = new node($this, $p);
}
}
}
function __sleep() {
$this->temp = serialize($this->nodes);
return array("path", "temp");
}
function __wakeup() {
$this->nodes = unserialize($this->temp);
$this->temp = null;
foreach ($this->nodes as $n) {
$n->parent = $this;
}
}
function createWeirdConnections() {
foreach ($this->nodes as $n) {
$a = $this->nodes;
shuffle($a);
$n->nodes[] = current($a);
}
}
}
$tree = new node(null, @$_SERVER["argv"][1] ?: ".");
$tree->createWeirdConnections();
$s = serialize($tree);
$temp = unserialize($s);
[2011-10-03 11:41:36] m...@php.net
OTOH, the following working script suggests that this is not the source of
failure:
parent ? $this->parent . "/" . $this->path : $this->path;
}
function __construct(node $parent = null, $path = ".") {
$this->parent = $parent;
$this->path = $path;
if (is_dir($this)) foreach (scandir($this) as $p) {
if ($p[0] != ".") {
$this->nodes[] = new node($this, $p);
}
}
}
function __sleep() {
$this->temp = serialize($this->nodes);
return array("path", "temp");
}
function __wakeup() {
$this->nodes = unserialize($this->temp);
$this->temp = null;
foreach ($this->nodes as $n) {
$n->parent = $this;
}
}
}
$tree = new node(null, @$_SERVER["argv"][1] ?: ".");
$s = serialize($tree);
var_dump($s);
$temp = unserialize($s);
print_r($temp);
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
https://bugs.php.net/bug.php?id=55801
--
Edit this bug report at https://bugs.php.net/bug.php?id=55801&edit=1
Bug #59808 [Com]: Compilation error: too many arguments to function 'php_json_decode'
Edit report at https://bugs.php.net/bug.php?id=59808&edit=1 ID: 59808 Comment by: alex at discardmail dot com Reported by:eborned at gmail dot com Summary:Compilation error: too many arguments to function 'php_json_decode' Status: Open Type: Bug Package:solr Operating System: Debian PHP Version:5.2.17 Block user comment: N Private report: N New Comment: I have searched through the PHP source tree of 5.2 and 5.3 where it can be seen that the function php_json_decode (in php/ext/json/php_json.h) requires 5 arguments in PHP 5.3 and 4 in PHP 5.2: PHP 5.2: php_json_decode(zval *return_value, char *buf, int buf_len, zend_bool assoc TSRMLS_DC); PHP 5.3: php_json_decode(zval *return_value, char *str, int str_len, zend_bool assoc, long depth TSRMLS_DC) Solr-PECL wants to call php_json_decode with 5 parameters (in solr-1.0.1/solr_functions_helpers.c): php_json_decode(&json_decode_ret_val, (char *) json_string, json_string_length, 1, recursion_depth TSRMLS_CC); So it can not be compiled with PHP 5.2 in that way. Additionally the command "ZEND_EXTERN_MODULE_GLOBALS(json)" does not work with PHP 5.2. I've added a patch which uses the 4-argument-function and does not use "ZEND_EXTERN_MODULE_GLOBALS(json)" at PHP 5.2. I have not tested if php_json_decode is working after this patch, but at least PECL-solr can be compiled with PHP 5.2 and the other functions are working. Because of this bug it can not be installed via PECL/PEAR, but manually: wget http://pecl.php.net/get/solr-1.0.1.tgz tar xfz solr-1.0.1.tgz cd solr-1.0.1 wget -Opeclsolr.patch 'https://bugs.php.net/patch-display.php?bug_id=59808&patch=peclsolr.patch&revision=latest&download=1' patch solr_functions_helpers.c peclsolr.patch phpize ./configure make make install And then add the extension to your php.ini and restart Apache: extension = solr.so Previous Comments: [2011-10-11 15:18:59] php at discardmail dot com Same error on CentOS 5.3 and PHP 5.2.13: ./configure --enable-solr=yes --enable-solr-debug=no --with-curl=/usr/include/curl --with-libxml-dir=/usr/include/libxml2 make solr-1.0.1/solr_functions_helpers.c:23: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âjson_globalsâ solr-1.0.1/solr_functions_helpers.c: In function âsolr_json_to_php_nativeâ: solr-1.0.1/solr_functions_helpers.c:1123: error: too many arguments to function âphp_json_decodeâ make: *** [solr_functions_helpers.lo] Error 1 [2011-09-06 13:15:59] badllama77 at gmail dot com Same issue ubuntu 9.04/php 5.2.6 ubuntu 10.04/php 5.2.10 /home/emyers/src/solr-1.0.1/solr_functions_helpers.c:23: error: expected =, ,, ;, asm or __attribute__ before json_globals /home/emyers/src/solr-1.0.1/solr_functions_helpers.c: In function solr_json_to_php_native: /home/emyers/src/solr-1.0.1/solr_functions_helpers.c:1123: error: too many arguments to function php_json_decode [2011-09-05 07:51:07] james at siteace dot co dot uk I can confirm i have the same issue installing or upgrading on centOS/Plesk and PHP 5.2.10 I have installed the beta version without issue [2011-08-31 18:47:25] ken dot williams at meteorgames dot com Confirmed same issue with php 5.2.11 / Cent5.4 [2011-08-15 09:57:31] jeff at deepbass dot net Same issue. OSX/PHP 5.3.5 But the make stop right after solr_functions_helpers.c:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'json_globals' make: *** [solr_functions_helpers.lo] Error 1 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 https://bugs.php.net/bug.php?id=59808 -- Edit this bug report at https://bugs.php.net/bug.php?id=59808&edit=1
Req #60045 [Asn->Csd]: Number of updated files
Edit report at https://bugs.php.net/bug.php?id=60045&edit=1 ID: 60045 Updated by: yann...@php.net Reported by:b...@php.net Summary:Number of updated files -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Online Doc Editor problem PHP Version:5.4.0beta1 Assigned To:yannick Block user comment: N Private report: N New Comment: This bug has been fixed in SVN, and should show up online in an hour or three. Thank you for the report, and for helping us make PHP.net better. Previous Comments: [2011-10-13 13:58:59] yann...@php.net Automatic comment from SVN on behalf of yannick Revision: http://svn.php.net/viewvc/?view=revision&revision=318082 Log: New libel for 'Files need update' module : We indicate now the number of files for the current user, as asked by b...@php.net in feature request #60045 [2011-10-13 06:10:52] b...@php.net 2yann...@php.net: Yeah, that's it! [2011-10-12 19:27:28] yann...@php.net What do you mean ? You want to display the number of YOUR file who need to be updated ? Something like this, in the title of the module : Need update (6 files - 3 of yours) [2011-10-12 12:00:47] b...@php.net *maintainer could see number of files need to be updated. [2011-10-12 11:54:20] b...@php.net Description: It would be usefull if user could see which of translated files need to be updated. It would be better to add this number in string that contains all files that need to be updated. -- Edit this bug report at https://bugs.php.net/bug.php?id=60045&edit=1
Req #60053 [Com]: Allow throwing of strings and things
Edit report at https://bugs.php.net/bug.php?id=60053&edit=1 ID: 60053 Comment by: anon at anon dot anon Reported by:anon at anon dot anon Summary:Allow throwing of strings and things Status: Open Type: Feature/Change Request Package:Class/Object related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I'd like to add that since PHP is so dynamically-typed and prefers to cock programs up at run time instead of letting them be robustly specified from the get go, I once thought I *could* do this anyway. It's a valid syntax, but the first time one of my "exceptions" was thrown it blew up. Previous Comments: [2011-10-13 13:32:11] anon at anon dot anon Description: Here's my suggestion: when throwing something that's not an Exception, use it as the message of a new Exception (instead of dying). I.e., throw $x; where !($x instanceof Exception) would be interpreted as: throw new Exception($x); Then I could do this: throw "I can't be arsed to type new Exception() everywhere"; >inb4 one person looks at and rejects this for some bureaucratic reason and >it's never considered again. >I mean, er, have a nice day. -- Edit this bug report at https://bugs.php.net/bug.php?id=60053&edit=1
[PHP-BUG] Req #60053 [NEW]: Allow throwing of strings and things
From: Operating system: PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:Allow throwing of strings and things Description: Here's my suggestion: when throwing something that's not an Exception, use it as the message of a new Exception (instead of dying). I.e., throw $x; where !($x instanceof Exception) would be interpreted as: throw new Exception($x); Then I could do this: throw "I can't be arsed to type new Exception() everywhere"; >inb4 one person looks at and rejects this for some bureaucratic reason and it's never considered again. >I mean, er, have a nice day. -- Edit bug report at https://bugs.php.net/bug.php?id=60053&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60053&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60053&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60053&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60053&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60053&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60053&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60053&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60053&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60053&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60053&r=support Expected behavior: https://bugs.php.net/fix.php?id=60053&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60053&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60053&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60053&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60053&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60053&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60053&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60053&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60053&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60053&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60053&r=mysqlcfg
[PHP-BUG] Bug #60052 [NEW]: Integer returned as a 64bit integer on X64_86
From: Operating system: All (linux tested) PHP version: 5.3.8 Package: InterBase related Bug Type: Bug Bug description:Integer returned as a 64bit integer on X64_86 Description: Integer on firebird is treated as a 32 bit int and int64 is used as a 64 bit integer. In the pdo_firebird driver INT64 is not implemented and LONG (int32) is treated as a long integer. On an x86_64 machine this means that a SQL_LONG doesn't honor the bit-sign in a value and INT64 doesn't return anything. This patch should fix this value for x86_64 systems while leaving x86 systems unchanged. Test script: --- any firebirdSQL database with a integer field containing a negative value. retrieve the value with the pdo_firebird driver on a 64 bit machine and echo it to the screen. Expected result: negative values with integer and should be returned as a negative number. Actual result: -- negative values are returned as their unsigned counterpart. -- Edit bug report at https://bugs.php.net/bug.php?id=60052&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60052&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60052&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60052&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60052&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60052&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60052&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60052&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60052&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60052&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60052&r=support Expected behavior: https://bugs.php.net/fix.php?id=60052&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60052&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60052&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60052&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60052&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60052&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60052&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60052&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60052&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60052&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60052&r=mysqlcfg
Bug #52376 [Com]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
Edit report at https://bugs.php.net/bug.php?id=52376&edit=1
ID: 52376
Comment by: em at ducommun dot ch
Reported by:ryan at kisc dot edu dot np
Summary:opendir() cannot open UNC paths in IIS7 using
passthrough auth.
Status: Assigned
Type: Bug
Package:*Directory/Filesystem functions
Operating System: win64 - W2008R2
PHP Version:5.3.2
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I have exactly the same problem.
I have tried to map the share to a letter, exemple Z:/ same result.
This is not a permissions problem.
Please help.
Config: xampp running under w2k3r2 server, with php 5.3.5
Thanks!
Previous Comments:
[2011-08-05 15:14:58] marc dot seitz at ww-informatik dot de
Hi Guys,
we have exactly the same problem now.
We want to migrate to Windows Server 2008 R2 with IIS 7.5, FastCGI, PHP 5.3.6.
When I try to do a file_get_contents() or opendir() I
always will get the error:
Warning: fopen(): failed to open stream: Permission denied in
D:\inetpub\wwwroot\XXX.php on line 26
The Application-Pools of the IIS are running under a Domain-Account which has
access to the Network Share.
I don't know how to solve this problem.
Any ideas of you?
Thanks
Marc
[2011-01-13 04:24:50] mark at internode dot on dot net
Hi I am having the same problem with PHP 5.3.5 running under IIS 7.5, FastCGI,
Windows Server 2008 R2 where I am simply trying to access a file on another
server using a UNC path.
$uploadfile = "\.txt";
$fh = fopen($uploadfile, 'r') or die("Can't open file $uploadfile");
I have tried granting "everyone" full permissions for the share and the file
system but it still does not work.
This code works perfectly if the file is stored on the same server and is
accessed through a local path.
Other things I have tried inlcude:
- setting the defaultappool to use a specific user and granting that user
permissions on the share and file system
- using "network" as above
Any other ideas on this one?
[2010-07-20 04:42:43] ahar...@php.net
(Restoring status.)
As a fellow Chrome user, I feel your pain. :)
[2010-07-20 04:08:58] ryan at kisc dot edu dot np
sorry about the line breaks, apparently this site doesn't like what Chrome does
when I resize the text box. I'll be more careful in the future. Actually this
site seems to hate Chrome altogether.
I keep getting "incorrect username" constantly. The bug site is buggy, at least
in Chrome.
[2010-07-20 04:04:31] ryan at kisc dot edu dot np
Well, that allows me to browse to the folder via chrome and essentially does
the
same thing as the
workaround from #50542 but only on the one folder which could work. What it
does
not appear to do
is give me programmatic access to the folder. The instructions in that KB are
outdated as it uses
adsutil.vbs and the setting is the same as the "Physical Path Credentials" from
the IIS manager.
This could work, in a much less than ideal way, if there is some way to run
"opendir" on the
virtual directory without specifying the unc path (since the UNC path itself
still does not work).
I could just be unaware of how, since it seems to use the system paths and not
honor or even
acknowledge virtual directories. I tried lots of different formats against my
better judgement but
none worked. I even tried using the http path reference. Still no joy. I've
used
PHP since 1998 but
realize something could have changed at any one of the releases, however I'm
not
sure I see how a
virtual directory could solve the ability to use opendir. Fair enough if this
was just a try. I'm
happy to keep trying if it can help the community. This worked fabulously in
IIS6. I also confess
that it appears to be Microsoft's fault. Very frustrating.
I wonder if I can create a symbolic link equivalent. I've done this before in
older versions of
windows, but I don't think I've ever done it to a network share. In my case I
may be able to just
move the share to the IIS server and be done with it, but I'm willing to stick
this out if it will
help find a solution to this issue.
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
https://bugs.php.net/bug.php?id=52376
--
Edit this bug report at https://bugs.php.net/bug.php?id=52376&edit=1
Bug #12949 [Com]: ldap_bind issues warning
Edit report at https://bugs.php.net/bug.php?id=12949&edit=1 ID: 12949 Comment by: truc at moechofe dot com Reported by:rbohn at commnav dot com Summary:ldap_bind issues warning Status: Bogus Type: Bug Package:LDAP related Operating System: linux PHP Version:4.0.6 Block user comment: N Private report: N New Comment: But, when using a personal error_handler function, the warning is catched by this handler. This is really annoying. Previous Comments: [2001-08-24 12:49:24] sni...@php.net If you want to suppress error messages, either set the error_reporting to the level you like or use @ in front of the function of which errors you don't want to output. Not a bug. (This is how all php functions work..) --Jani [2001-08-24 12:32:12] rbohn at commnav dot com possible bug: inside the ldap_bind, if the credentials are invalid, php issues a warning. I think it should JUST return false. Is there a reasoning behind this? ~Ryan Bohn -- Edit this bug report at https://bugs.php.net/bug.php?id=12949&edit=1
[PHP-BUG] Bug #60051 [NEW]: Compiler is failing while generating phar.php
From: Operating system: aix 6.1 PHP version: 5.3.8 Package: Compile Failure Bug Type: Bug Bug description:Compiler is failing while generating phar.php Description: We are trying to compile php 5.3.8 on AIX 6.1 using configure options mentioned below. ./configure --prefix=/usr/local --with-apxs2=/export/opt/quikremit/apache2/bin/apxs --with-config-file-path=/export/opt/quikremit/apache2/conf --with-gd --with-zlib-dir=/opt/freeware/lib --enable-shared --enable-debug --disable-static --host=powerpc-ibm-aix6.1.0.0 but make is giveing below error: Generating phar.php exec(): 0509-036 Cannot load program /export/opt/quikremit/pqapp/php/php-5.3.8/sapi/cli/php because of the following errors: rtld: 0712-001 Symbol htmlDocDumpMemoryFormat was referenced from module php(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol xmlTextReaderSetup was referenced from module php(), but a runtime definition of the symbol was not found. make: *** [ext/phar/phar.php] Error 255 Test script: --- ext/phar/phar.php: /export/opt/quikremit/pqapp/php/php-5.3.8/ext/phar/build_precommand.php /export/opt/quikremit/pqapp/php/php-5.3.8/ext/phar/phar/*.inc /exp ort/opt/quikremit/pqapp/php/php-5.3.8/ext/phar/phar/*.php $(SAPI_CLI_PATH) -@echo "Generating phar.php" Expected result: Make should complete with successful results as BUILD COMPLETE Actual result: -- Generating phar.php exec(): 0509-036 Cannot load program /export/opt/quikremit/pqapp/php/php-5.3.8/sapi/cli/php because of the following errors: rtld: 0712-001 Symbol htmlDocDumpMemoryFormat was referenced from module php(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol xmlTextReaderSetup was referenced from module php(), but a runtime definition of the symbol was not found. make: *** [ext/phar/phar.php] Error 255 -- Edit bug report at https://bugs.php.net/bug.php?id=60051&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60051&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60051&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60051&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60051&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60051&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60051&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60051&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60051&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60051&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60051&r=support Expected behavior: https://bugs.php.net/fix.php?id=60051&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60051&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60051&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60051&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60051&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60051&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60051&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60051&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60051&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60051&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60051&r=mysqlcfg
Bug #60041 [Asn->Bgs]: ob_gzhandler and ob_clean
Edit report at https://bugs.php.net/bug.php?id=60041&edit=1 ID: 60041 Updated by: m...@php.net Reported by:jille at hexon dot cx Summary:ob_gzhandler and ob_clean -Status: Assigned +Status: Bogus Type: Bug Package:Output Control Operating System: n/a PHP Version:5.3.8 Assigned To:mike Block user comment: N Private report: N New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See http://bugs.php.net/bug.php?id=36514 Previous Comments: [2011-10-11 14:42:29] jille at hexon dot cx Description: Calling ob_clean() after starting the ob_gzhandler screws up. ob_get_clean() doesn't seem to behave perfectly either. There seem to be two problems: * The gzip headers gets lost or is incorrect. * The Content-Encoding header can be set even if the data is not gzip'ed (See test script 2) Test script: --- or Expected result: HTTP/1.1 200 OK Date: Tue, 11 Oct 2011 14:32:12 GMT Server: Apache Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 0 Connection: close Content-Type: text/html; charset=utf-8 Connection closed by foreign host. Actual result: -- HTTP/1.1 200 OK Date: Tue, 11 Oct 2011 14:32:12 GMT Server: Apache Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 0 Connection: close Content-Type: text/html; charset=utf-8 [some data] Connection closed by foreign host. -- Edit this bug report at https://bugs.php.net/bug.php?id=60041&edit=1
[PHP-BUG] Req #60050 [NEW]: var_export should not add space at end of line
From:
Operating system: Ubuntu - Linux
PHP version: 5.3.8
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:var_export should not add space at end of line
Description:
With an array that contains an array, the var_export adds an extra space at
end of line
=> It forces post treatment to suppress those extra spaces, before saving
output to a file
As spaces at end of line is not a recommended practice...
Test script:
---
array('foo'));
var_export($test);
?>
Expected result:
array (
'string' =>// <= the line should end with '=>', and not with a space e.g
'=> '
array (
0 => 'foo',
),
)
Actual result:
--
array (
'string' => // <= there's a space after the '=>' symbol
array (
0 => 'foo',
),
)
--
Edit bug report at https://bugs.php.net/bug.php?id=60050&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60050&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60050&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60050&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60050&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60050&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60050&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60050&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60050&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60050&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60050&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60050&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60050&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60050&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60050&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60050&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60050&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60050&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60050&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60050&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60050&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60050&r=mysqlcfg
[PHP-BUG] Bug #60049 [NEW]: Memcached does not handle invalid keys
From:
Operating system: Linux (Debian 5)
PHP version: 5.3.8
Package: memcached
Bug Type: Bug
Bug description:Memcached does not handle invalid keys
Description:
Calling Memcached with invalid keys (too long, invalid characters) leads to
strange behavior.
Calling get with an invalid key and after that getMulti with a valid key
does not
work (see below).
Versions:
memcached support => enabled
libmemcached version => 0.52
PECL:
memcached 1.0.2 stable
Test script:
---
addServer('127.0.0.1', 11211);
$mc->get(str_pad('', 300, 'x'));
// it is "NOT FOUND"
$this->assertEquals(Memcached::RES_BAD_KEY_PROVIDED,
$mc->getResultCode());
$mc->getMulti(array('foo'));
// it is "SERVER HAS FAILED AND IS DISABLED UNTIL TIMED RETRY"
$this->assertEquals(Memcached::RES_BAD_KEY_PROVIDED,
$mc->getResultCode());
}
}
Expected result:
The first $mc->get should lead to a result code "BAD KEY PROVIDED".
The second $mc->getMulti be "NOT FOUND" or "SUCCESS" depending on the cache
content.
Actual result:
--
The first $mc->get sets the result code to "NOT FOUND".
The second $mc->getMulti sets the result code to "SERVER HAS FAILED AND IS
DISABLED UNTIL TIMED RETRY".
--
Edit bug report at https://bugs.php.net/bug.php?id=60049&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60049&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60049&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60049&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60049&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60049&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60049&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60049&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60049&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60049&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60049&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60049&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60049&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60049&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60049&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60049&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60049&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60049&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60049&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60049&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60049&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60049&r=mysqlcfg
[PHP-BUG] Bug #60048 [NEW]: sa_len a #define on IRIX
From:
Operating system: IRIX 6.5
PHP version: 5.3.8
Package: Sockets related
Bug Type: Bug
Bug description:sa_len a #define on IRIX
Description:
on IRIX 6.5 defines sa_len as:
#define sa_len sa_union.sa_generic.sa_len2
Because of this, socket_accept() in ext/sockets/sockets.c cannot be
compiled on this platform because it uses sa_len as a variable:
PHP_FUNCTION(socket_accept)
{
zval *arg1;
php_socket *php_sock, *new_sock;
php_sockaddr_storage sa;
socklen_tsa_len = sizeof(sa);
The obvious fix is to rename "sa_len" to something like php_sa_len.
--
Edit bug report at https://bugs.php.net/bug.php?id=60048&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60048&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60048&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60048&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60048&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60048&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60048&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60048&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60048&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60048&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60048&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60048&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60048&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60048&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60048&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60048&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60048&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60048&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60048&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60048&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60048&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60048&r=mysqlcfg
Req #60044 [Com]: make is failing for date/lib/parse_tz.lo
Edit report at https://bugs.php.net/bug.php?id=60044&edit=1 ID: 60044 Comment by: sanjay dot d dot patil at oracle dot com Reported by:sanjay dot d dot patil at oracle dot com Summary:make is failing for date/lib/parse_tz.lo Status: Feedback Type: Feature/Change Request Package:Compile Failure Operating System: AIX 6.1 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Thanks, I followed your instructions i.e. Try disabling optimisation (-O0) instead of (-O2) while compiling. It worked for that file (parse_tz.lo). However I am encountering error for below file as make: *** [ext/phar/phar.php] Error 255 --detail error encountered as below:-- Generating phar.php exec(): 0509-036 Cannot load program /export/opt/quikremit/pqapp/php/php-5.3.8/sapi/cli/php because of the following errors: rtld: 0712-001 Symbol htmlDocDumpMemoryFormat was referenced from module php(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol xmlTextReaderSetup was referenced from module php(), but a runtime definition of the symbol was not found. make: *** [ext/phar/phar.php] Error 255 Previous Comments: [2011-10-12 11:14:31] der...@php.net This .s file is generated by your compiler. Perhaps it can't deal with so many states in a file? Try disabling optimisation (-O0) instead of (-O2) while compiling (you can just change that in the Makefile for the parze_tz file only. [2011-10-12 11:04:21] sanjay dot d dot patil at oracle dot com Description: configurung with this command line parameters: ./configure --prefix=/usr/local --with-apxs2=/export/opt/quikremit/apache2/bin/apxs --with-config-file-path=/export/opt/quikremit/apache2/conf --with-gd --with-zlib-dir=/opt/freeware/lib --enable-shared --disable-static --with-png --with-zlib --with-bz2 --with-xml --with-jpeg-dir=/opt/freeware/lib --with-png-dir=/opt/freeware/lib --with-xpm-dir=/opt/freeware/lib --host=powerpc-ibm-aix6.1.0.0 after this i am running make But it is failing with below error code: Assembler: /tmp//ccksvqSL.s: line 1541: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. make: *** [ext/date/lib/parse_tz.lo] Error 1 Test script: --- make is failing on below code: /bin/sh /export/opt/quikremit/pqapp/php/php-5.3.8/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/ -DPHP_ATOM_INC -I/export/opt/quikremit/pqapp/php/php-5.3.8/include -I/export/opt/quikremit/pqapp/php/php-5.3.8/main -I/export/opt/quikremit/pqapp/php/php-5.3.8 -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/lib -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/ereg/regex -I/usr/local/include/libxml2 -I/export/opt/quikremit/pqapp/php/php-5.3.8/ext/sqlite3/libsqlite -I/export/opt/quikremit/pqapp/php/php-5.3.8/TSRM -I/export/opt/quikremit/pqapp/php/php-5.3.8/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /export/opt/quikremit/pqapp/php/php-5.3.8/ext/date/lib/parse_tz.c -o ext/date/lib/parse_tz.lo Expected result: make should be successful with no errors Actual result: -- Assembler: /tmp//ccf46yBi.s: line 1541: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. make: *** [ext/date/lib/parse_tz.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=60044&edit=1
Bug #55475 [PATCH]: is_a() triggers autoloader
Edit report at https://bugs.php.net/bug.php?id=55475&edit=1 ID: 55475 Patch added by: ala...@php.net Reported by:mads at gartneriet dot dk Summary:is_a() triggers autoloader Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.3.7 Assigned To:dmitry Block user comment: N Private report: N CVE-ID: 2011-3379 New Comment: The following patch has been added/updated: Patch Name: final_patch_for_5_4_and_HEAD Revision: 1318491419 URL: https://bugs.php.net/patch-display.php?bug=55475&patch=final_patch_for_5_4_and_HEAD&revision=1318491419 Previous Comments: [2011-10-03 07:30:43] ala...@php.net Any comments on 5.4.* It seems like applying the 5.3 fix to 5.4 is the only option here, as there is no 'reasonable' way to flag the previous behavior as E_DEPRECIATED that works well as both forward and backward compatible. [2011-09-27 18:36:55] paj...@php.net Add CVE # [2011-09-27 09:35:31] ala...@php.net Automatic comment from SVN on behalf of alan_k Revision: http://svn.php.net/viewvc/?view=revision&revision=317382 Log: document fix for #55475 in NEWS [2011-09-26 19:57:09] paj...@php.net that's what I meant. [2011-09-26 19:54:23] henri at nerv dot fi CVE already requested with A LOT of conversation: http://www.openwall.com/lists/oss-security/2011/09/24/2 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 https://bugs.php.net/bug.php?id=55475 -- Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1
