#49496 [NEW]: xmlrpc_is_fault() should not throw a Notice when given argument is not an array
From: tor...@php.net
Operating system: *
PHP version: 5.3SVN-2009-09-08 (SVN)
PHP Bug Type: Feature/Change Request
Bug description: xmlrpc_is_fault() should not throw a Notice when given
argument is not an array
Description:
In bug #40793 and doc bug #49378 it is reported that xmlrpc_is_fault()
throws a Notice when the passed argument is not an array. In the comments
for #40793 tony2...@php.net states that this is by design, and indeed it
appears to be, but that would seem to be a broken design. xmlrpc_is_fault()
should simply return true if the passed argument represents an xmlrpc
fault, and false otherwise.
Patch for PHP 5.2:
Index: ext/xmlrpc/xmlrpc-epi-php.c
===
--- ext/xmlrpc/xmlrpc-epi-php.c (revision 287478)
+++ ext/xmlrpc/xmlrpc-epi-php.c (working copy)
@@ -1445,7 +1445,7 @@
/* }}} */
/* {{{ proto bool xmlrpc_is_fault(array)
- Determines if an array value represents an XMLRPC fault. */
+ Determines if the passed value represents an XMLRPC fault. */
PHP_FUNCTION(xmlrpc_is_fault)
{
zval **arg, **val;
@@ -1455,20 +1455,20 @@
}
if (Z_TYPE_PP(arg) != IS_ARRAY) {
- php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Array argument
expected");
- } else {
- /* The "correct" way to do this would be to call the xmlrpc
-* library XMLRPC_ValueIsFault() func. However, doing that
-* would require us to create an xmlrpc value from the php
-* array, which is rather expensive, especially if it was
-* a big array. Thus, we resort to this not so clever hackery.
-*/
- if (zend_hash_find(Z_ARRVAL_PP(arg), FAULT_CODE, FAULT_CODE_LEN
+ 1,
(void**) &val) == SUCCESS &&
- zend_hash_find(Z_ARRVAL_PP(arg), FAULT_STRING,
FAULT_STRING_LEN +
1, (void**) &val) == SUCCESS) {
- RETURN_TRUE;
- }
+ RETURN_FALSE;
}
+ /* The "correct" way to do this would be to call the xmlrpc
+* library XMLRPC_ValueIsFault() func. However, doing that
+* would require us to create an xmlrpc value from the php
+* array, which is rather expensive, especially if it was
+* a big array. Thus, we resort to this not so clever hackery.
+*/
+ if (zend_hash_find(Z_ARRVAL_PP(arg), FAULT_CODE, FAULT_CODE_LEN + 1,
(void**) &val) == SUCCESS &&
+ zend_hash_find(Z_ARRVAL_PP(arg), FAULT_STRING, FAULT_STRING_LEN + 1,
(void**) &val) == SUCCESS) {
+ RETURN_TRUE;
+ }
+
RETURN_FALSE;
}
/* }}} */
Patch for PHP 5.3:
Index: ext/xmlrpc/xmlrpc-epi-php.c
===
--- ext/xmlrpc/xmlrpc-epi-php.c (revision 287473)
+++ ext/xmlrpc/xmlrpc-epi-php.c (working copy)
@@ -1495,20 +1495,24 @@
Determines if an array value represents an XMLRPC fault. */
PHP_FUNCTION(xmlrpc_is_fault)
{
- zval *arg, **val;
+ zval **arg, **val;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a", &arg) ==
FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "Z", &arg) ==
FAILURE) {
return;
}
+ if (Z_TYPE_PP(arg) != IS_ARRAY) {
+ RETURN_FALSE;
+ }
+
/* The "correct" way to do this would be to call the xmlrpc
* library XMLRPC_ValueIsFault() func. However, doing that
* would require us to create an xmlrpc value from the php
* array, which is rather expensive, especially if it was
* a big array. Thus, we resort to this not so clever hackery.
*/
- if (zend_hash_find(Z_ARRVAL_P(arg), FAULT_CODE, FAULT_CODE_LEN + 1,
(void**) &val) == SUCCESS &&
- zend_hash_find(Z_ARRVAL_P(arg), FAULT_STRING, FAULT_STRING_LEN
+ 1,
(void**) &val) == SUCCESS) {
+ if (zend_hash_find(Z_ARRVAL_PP(arg), FAULT_CODE, FAULT_CODE_LEN + 1,
(void**) &val) == SUCCESS &&
+ zend_hash_find(Z_ARRVAL_PP(arg), FAULT_STRING, FAULT_STRING_LEN
+ 1,
(void**) &val) == SUCCESS) {
RETURN_TRUE;
}
--
Edit bug report at http://bugs.php.net/?id=49496&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49496&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49496&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49496&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49496&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49496&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49496&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49496&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49496&r=nee
#49495 [Opn->Bgs]: PHP doesn't run correct method
ID: 49495
User updated by: martin at spuetz dot net
Reported By: martin at spuetz dot net
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
I found the problem. It will work when you change the soap binding
style
to rpc.
doesn't work:
http://schemas.xmlsoap.org/soap/http"/>
works:
http://schemas.xmlsoap.org/soap/http"/>
Greetings from Germany
Martin
Previous Comments:
[2009-09-08 06:27:07] martin at spuetz dot net
Description:
I have two methods test1() and test2(), but PHP always runs the first
one.
You can see this on the following link:
http://www.spuetz.net/client.php
http://www.spuetz.net/source.txt
It does works, when I add a parameter (change the method signature?):
http://www.spuetz.net/client1.php
http://www.spuetz.net/source1.txt
The server is running 5.2.10 (http://www.spuetz.net/info.php), but I
tried it with 5.3.0, too.
The wsdl file was generated with Zend Studio.
Reproduce code:
---
class Testserver {
public function test1()
{
return "test1";
}
public function test2()
{
return "test2";
}
}
[...]
var_dump($client->test1());
var_dump($client->test2());
Expected result:
string(5) "test1"
string(5) "test2"
Actual result:
--
string(5) "test1"
string(5) "test1"
--
Edit this bug report at http://bugs.php.net/?id=49495&edit=1
#49497 [NEW]: No ability to supply a userland PHP function as a callback for a COM method.
From: RQuadling at GMail dot com Operating system: Windows XP SP3 PHP version: 5.3SVN-2009-09-08 (snap) PHP Bug Type: COM related Bug description: No ability to supply a userland PHP function as a callback for a COM method. Description: Hi. I think I'm pretty much on my own here, but here goes. I'm evaluating a COM tool to allow me to OCR documents. The COM object requires the registration of a callback to allow the object to send results as it finds them (events in their terminology) back to a handler for processing (say logging in a DB, etc.). According to their documentation, in C and VB, the registration is a trivial process of simply supplying the address of the function as the handler for the callback. Obviously, this won't work in PHP as a PHP function isn't accessible like a compiled function from outside of PHP. The "value" to be supplied is of type VT_I4. This is essentially just the address of the function (as I see things). So, I think that a proxy is needed. Something to act in the middle of the PHP script and the callback invocation by the COM object. Any ideas? -- Edit bug report at http://bugs.php.net/?id=49497&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49497&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49497&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49497&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49497&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49497&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49497&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49497&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49497&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49497&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49497&r=support Expected behavior: http://bugs.php.net/fix.php?id=49497&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49497&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49497&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49497&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49497&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49497&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49497&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49497&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49497&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49497&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49497&r=mysqlcfg
#49494 [Opn->Bgs]: php5apache2.dll not present in zip or msi
ID: 49494 Updated by: paj...@php.net Reported By: webmaster at pnmx dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Vista PHP Version: 5.3.0 New Comment: Download the thread safe version of our releases. NTS is for FastCGI and other non thread safe SAPI. Apache requires a thread safe SAPI. Previous Comments: [2009-09-08 04:40:57] webmaster at pnmx dot com FYI, there's no php5apache2_2.dll present either. There is a php5.dll but if you change httpd.conf to load that file, you get: Can't locate API module structure `php5_module' in file D:/Programs/PHP5.3/php5.dll So it's clearly not just misnamed. [2009-09-08 04:26:44] webmaster at pnmx dot com Description: php5papache2.dll mentioned in install.txt is not part of distributions on php.net. A couple of third party sources offer the dll, but their trustworthiness in unknown. Would prefer to download the file from php.net, the apache project, or at worst from sourceforge. Please don't say this doesn't indicate a bug in PHP. Duh! It's a bug in the distribution of PHP. That should matter too. This problem has been in every Windows version of PHP that I've ever installed. Why does it keep recurring? Reproduce code: --- Download and install php5.3 using either the Windows msi installer or by unpacking the 5.3 zip archive. In both cases, there is no php5papache2.dll or similar in the install directory. Expected result: php5papache2.dll available from php.net, ideally installed along with other elements of the configuration. Actual result: -- php5papache2.dll is not available from a trustworthy site. -- Edit this bug report at http://bugs.php.net/?id=49494&edit=1
#49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
ID: 49344
Comment by: Rockyjl at gmail dot com
Reported By: rockyjl at gmai dot com
Status: Open
Bug Type: PDO related
Operating System: win2003 X64
PHP Version: 5.2.11RC1
New Comment:
Apache/2.2.13 (Win32) PHP/5.2.11RC3-dev
Error:
[2009-09-08 17:34:13]
127.0.0.1
ApacheBench/2.3
SQLSTATE[] (null) (severity 0)
Help !!! Who can help me ? please !
Previous Comments:
[2009-09-03 09:26:14] rockyjl at gmail dot com
web server is Apache 2.2.11 and Apache 2.2.13 x86 no_ssl
[2009-08-27 08:27:57] rockyjl at gmail dot com
php-5.2.11RC2-dev-win32-VC6-x86 has the Bug too!
Anyone can help me ? Please !
[2009-08-25 02:08:48] rockyjl at gmail dot com
I upgrade to php-5.2.11RC2-dev-win32-VC6-x86 now !
Testing the bug
[2009-08-24 10:06:51] rockyjl at gmai dot com
Description:
in Bug #48539
[28 Jun 2:10am UTC] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed in 5.2 and HEAD.
5.3 in soon.
Thanks.
But the bug still often happen in PHP 5.2.11RC1 ...
Could you tell me which version(win32 zip) can work in the environment
of win2003 x64 + apache 2.2.11 + sql2005,and the pdo_mssql can connect
DB successfully ??
Reproduce code:
---
function db()
{
try
{
$db = new PDO(DB_DSN, DB_User, DB_Password);
return $db;
}
catch (PDOException $e)
{
die($e->getMessage());
}
}
Expected result:
connect DB Successful
Actual result:
--
SQLSTATE[] (null) (severity 0)
--
Edit this bug report at http://bugs.php.net/?id=49344&edit=1
#49489 [Bgs]: strftime('%P') generates "Invalid CRT parameters detected".
ID: 49489
Updated by: rquadl...@php.net
Reported By: RQuadling at GMail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-09-07 (snap)
New Comment:
Link is wrong. PHP uses VC++ not VC.NET. See
http://bugs.php.net/bug.php?id=49498
%p is correctly documented for the VC++ runtime reference.
Previous Comments:
[2009-09-07 11:39:18] rquadl...@php.net
Doh.
Seems that even the most recent MSDN docs
(http://msdn.microsoft.com/en-us/library/az4se3k1(VS.100).aspx and
http://msdn.microsoft.com/en-us/library/8kb3ddd4(VS.100).aspx) is out
of date.
No mention of %p, yet it works.
'aAdejuw',
'Week'=> 'UVW',
'Month' => 'bBhm',
'Year'=> 'CgGyY',
'Time'=> 'HIlMpPrRSTXzZ',
'Time and Date Stamps'=> 'cDFsx',
'Miscellaneous' => 'nt%',
'Unknown' => &$a_Remaining
);
foreach($a_Formats as $s_Group => $s_GroupFormats) {
echo $s_Group, PHP_EOL;
foreach(range(0, strlen($s_GroupFormats) - 1) as $i_Format) {
echo
"\t{$s_GroupFormats[$i_Format]} : ",
(!($s_Output = strftime('%' . $s_GroupFormats[$i_Format]))
? "\t\t\t[Unknown]"
: $s_Output),
PHP_EOL;
$a_Remaining = str_replace($s_GroupFormats[$i_Format], '',
$a_Remaining);
}
}
outputs ...
Day
a : Mon
A : Monday
d : 07
e : [Unknown]
j : 250
u : [Unknown]
w : 1
Week
U : 36
V : [Unknown]
W : 36
Month
b : Sep
B : September
h : [Unknown]
m : 09
Year
C : [Unknown]
g : [Unknown]
G : [Unknown]
y : 09
Y : 2009
Time
H : 12
I : 12
l : [Unknown]
M : 35
p : PM
P : [Unknown]
r : [Unknown]
R : [Unknown]
S : 03
T : [Unknown]
X : 12:35:03
z : GMT Standard Time
Z : GMT Standard Time
Time and Date Stamps
c : 09/07/09 12:35:03
D : [Unknown]
F : [Unknown]
s : [Unknown]
x : 09/07/09
Miscellaneous
n : [Unknown]
t : [Unknown]
% : %
Unknown
E : [Unknown]
J : [Unknown]
K : [Unknown]
L : [Unknown]
N : [Unknown]
O : [Unknown]
Q : [Unknown]
f : [Unknown]
i : [Unknown]
k : [Unknown]
o : [Unknown]
q : [Unknown]
v : [Unknown]
Thanks Derick. Next time I'll RTFM!
[2009-09-07 11:01:38] der...@php.net
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
Windows doesn\'t support all modifiers, see
http://msdn.microsoft.com/en-us/library/az4se3k1(VS.71).aspx for the
supported ones (and that link is in the manual at
http://uk3.php.net/strftime .
[2009-09-07 07:49:31] RQuadling at GMail dot com
Description:
Hi.
I was looking at the bug http://bugs.php.net/?id=49481 and saw
Derick's example at the bottom.
Tried running in and got some errors.
Retrieved latest Win32 VC9 x86 nts snapshot (PHP 5.3.2-dev (cli)
(built: Sep 7 2009 07:57:33))
Using %P causes the problem below. %p outputs AM (or PM if it is PM)
as expected.
Previous reports of this error (http://bugs.php.net/bug.php?id=48652)
says "Error in a dependency".
Not sure when this issue arose.
Reproduce code:
---
php -n -d date.timezone="Europe/London" -r "echo strftime('%P');"
Expected result:
am
Actual result:
--
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
---
#49499 [NEW]: get and set are not fixed
From: ies_clan at hotmail dot com
Operating system: Windows XP home
PHP version: 5.3.0
PHP Bug Type: Class/Object related
Bug description: get and set are not fixed
Description:
look @ the code
Reproduce code:
---
";
return $this->properties[$key];
}
public function __set($key, $val) {
echo "set $key to $val";
$this->properties[$key] = $val;
}
}
$c = new newclass;
$c->array['test'] = 'test';
Expected result:
get array
set array to test
Actual result:
--
get array
--
Edit bug report at http://bugs.php.net/?id=49499&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49499&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49499&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49499&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49499&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49499&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49499&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49499&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49499&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49499&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49499&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49499&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49499&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49499&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49499&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49499&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49499&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49499&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49499&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49499&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49499&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49499&r=mysqlcfg
#49344 [Opn->Fbk]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
ID: 49344
Updated by: fel...@php.net
Reported By: rockyjl at gmai dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: win2003 X64
PHP Version: 5.2.11RC1
-Assigned To:
+Assigned To: felipe
New Comment:
Hi, Can you try this patch in 5.2.11-dev?
http://felipe.c2zlabs.com/diff/bug49344.diff
Previous Comments:
[2009-09-08 09:37:12] Rockyjl at gmail dot com
Apache/2.2.13 (Win32) PHP/5.2.11RC3-dev
Error:
[2009-09-08 17:34:13]
127.0.0.1
ApacheBench/2.3
SQLSTATE[] (null) (severity 0)
Help !!! Who can help me ? please !
[2009-09-03 09:26:14] rockyjl at gmail dot com
web server is Apache 2.2.11 and Apache 2.2.13 x86 no_ssl
[2009-08-27 08:27:57] rockyjl at gmail dot com
php-5.2.11RC2-dev-win32-VC6-x86 has the Bug too!
Anyone can help me ? Please !
[2009-08-25 02:08:48] rockyjl at gmail dot com
I upgrade to php-5.2.11RC2-dev-win32-VC6-x86 now !
Testing the bug
[2009-08-24 10:06:51] rockyjl at gmai dot com
Description:
in Bug #48539
[28 Jun 2:10am UTC] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed in 5.2 and HEAD.
5.3 in soon.
Thanks.
But the bug still often happen in PHP 5.2.11RC1 ...
Could you tell me which version(win32 zip) can work in the environment
of win2003 x64 + apache 2.2.11 + sql2005,and the pdo_mssql can connect
DB successfully ??
Reproduce code:
---
function db()
{
try
{
$db = new PDO(DB_DSN, DB_User, DB_Password);
return $db;
}
catch (PDOException $e)
{
die($e->getMessage());
}
}
Expected result:
connect DB Successful
Actual result:
--
SQLSTATE[] (null) (severity 0)
--
Edit this bug report at http://bugs.php.net/?id=49344&edit=1
#49482 [Fbk->Opn]: SOAP encoding although WSDL requires use='LITERAL'
ID: 49482
User updated by: joep at clickhere dot nl
Reported By: joep at clickhere dot nl
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Ubuntu
PHP Version: 5.2.10
Assigned To: dmitry
New Comment:
Nothing is so obscure as the W3C documents. Therefore, "they"
(microsoft :-) convened the WS-I group to come to some type of "best
practices". But document/literal-wrapped is not a part of that. It
became a "de facto" standard because MS uses it, as do most Java
implementations. Nowhere this is described clearly (except perhaps in
this document:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Conclusion seems to be that xsi:type should not be sent.
Here http://jira.codehaus.org/browse/XFIRE-753 someone says that also
perl is in error when it sends "xsi:type".
So we think that the current PHP-implementation is not correct, type
information in document/literal is in the first place only given by the
xml-schema. On the other side the axis server complains about the
xsd:type and should just ignore it in this case to rely on the schema.
Previous Comments:
[2009-09-07 13:24:36] dmi...@php.net
This is not a bug. In case of 'use'='ENCODED' ext/soap always adds type
information and this check would just useless. In this place, it adds
type name specidied in 'classmap' for LITERAL encoding because without
it receiver won't be able to determine the real input type. Correct me
if I'm wrong (I can't be 100% sure as I don't see your code) and
demonstrate it with a small example.
BTW the 'classmap' concept is very limited. It was extended with
'typemap' concept which may give user the full control over generated
XML. Probably you need to use it.
[2009-09-06 10:29:52] joep at clickhere dot nl
Description:
I was hunting a bug in our soap-client. 'xsi:type' appears in the xml,
even when the WSDL states 'use="literal"'.
Our client works fine with 5.2.4, but since 5.2.7/5.2.8 its broken
(Also tested 5.2.9)
Came across this fix in ext/soap/php_encoding.c
+if (encode != enc && style == SOAP_LITERAL) {
add_type = 1;
-}
Shouldn't that be:
if (encode != enc && style == SOAP_ENCODED) {
add_type = 1;
}
--
Edit this bug report at http://bugs.php.net/?id=49482&edit=1
#33500 [Com]: imap_open() fails when the server advertises GSSAPI
ID: 33500 Comment by: 14908832 at sun dot ac dot za Reported By: ed2019 at columbia dot edu Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 5.2.9 Assigned To: pajoye New Comment: I had a similar problem, which I thought was caused by this bug/lack of feature, but was solved by a comment I found at the PHP manual's function description of imap_open. It merely required me to add '/user=' to the end of my list of protocols. I'm not sure whether this directly relates to this problem, but I hope it helps someone. Previous Comments: [2009-07-02 08:32:37] paj...@php.net Yes, have the patch but it was too late for 5.3.0. It will be committed in HEAD and after 5.3.1. [2009-07-01 17:38:37] hperrin at SPAMMENOTgmail dot com I'm running Group-Office and I have this same problem. I can get it to login to our Exchange 2007 server by running `kinit usern...@domain.com` on Apache's user. However, this causes all the Group-Office mail accounts to receive that user's emails, regardless of the credentials given to them. From my understanding, it is not technically incorrect to use c-client the way PHP currently does, but it is inefficient and limits the developers possibilities. So, it's been over a month since this request was updated. Is there any news on the status of this issue? Pajoye, if you can fix this, you will be my personal hero, and I'll name something after you. ;) [2009-05-21 09:23:43] paj...@php.net It is a feature request, if you read our last two comments you will see that we already agreed on that. [2009-05-20 22:00:16] hmandel at learningbygrace dot org While you guys are debating whether this is a bug or a feature request our coders here are still stuck at the end of developing some web apps because PHP and Exchange will not "exchange"... Damn it Jim, we can't get our emails off the Exchange server.:~) So since I can see you have all this expertise and are fully aware of the bug/feature request, I'd like to hire one of you to make this change and customize our darn PHP code so these guys (PHP and Exchange) can make up and talk again. ANyone up to it. I'll hire you so long as you REALLY can solve the problem and also I will not discriminate between those who believe this is a Feature Request and those who call i a Bug... we are equal opportunity here at Learning By Grace. My contact info is hmandel at learningbygrace dot org. Cell is two67-two49-five one67. Any takers? [2009-04-27 18:42:40] paj...@php.net ok, I was looking at mail_auth*. Then it should be possible to do it, I move the status to feature request (leaving it in the imap category but assigned to me, I will setup GSSAPI in my test exchange server box to valid the changes). Thanks for all the referecences, it will make the implementation easier. 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/33500 -- Edit this bug report at http://bugs.php.net/?id=33500&edit=1
#40740 [Com]: PDO::execute() errors when parameters are used in LIMIT clause
ID: 40740 Comment by: weblab dot solutions at gmail dot com Reported By: phpbugs at filofox dot com Status: No Feedback Bug Type: PDO related Operating System: Linux Debian Sarge 3.1 PHP Version: 5.2.1 Assigned To: wez New Comment: Try PHP 5.2.9 & 5.3.0 - get the same exception. Previous Comments: [2009-08-26 16:36:34] seb117 at free dot fr I don't understand why this bug does not solved ? It's very important, and we don't use PDO properly with this bug. [2009-08-22 05:59:07] marcel dot esser at gmail dot com Same problem on 5.2.6, Ubuntu Jaunty. [2009-06-16 17:49:09] tony at tonybibbs dot com Same issue on 5.3.0RC2 using pretty much the same code in the initial bug report. [2009-02-18 08:51:00] nduteil at freedev dot org Hi, Still not fixed in the 5.2.8 release. If PDOStatement::bindParam or PDOStatement::bindValue is used to specified the parameter type (ie : PDO::PARAM_INT) everything works as expected. Not forcing the parameter type to integer generates an error in Mysql. [2008-11-26 10:57:40] miha dot vrhovnik at domenca dot si I re-compiled pdo and pdo_mysql from 5.2.7 RC4 and overwritten libraries from php 5.2.6. Is this enough? If it is, then this issue is not fixed. 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/40740 -- Edit this bug report at http://bugs.php.net/?id=40740&edit=1
#40740 [Com]: PDO::execute() errors when parameters are used in LIMIT clause
ID: 40740 Comment by: weblab dot solutions at gmail dot com Reported By: phpbugs at filofox dot com Status: No Feedback Bug Type: PDO related Operating System: Linux Debian Sarge 3.1 PHP Version: 5.2.1 Assigned To: wez New Comment: And I really surprised this issue not fixed for more than 2 year. Previous Comments: [2009-09-08 12:56:51] weblab dot solutions at gmail dot com Try PHP 5.2.9 & 5.3.0 - get the same exception. [2009-08-26 16:36:34] seb117 at free dot fr I don't understand why this bug does not solved ? It's very important, and we don't use PDO properly with this bug. [2009-08-22 05:59:07] marcel dot esser at gmail dot com Same problem on 5.2.6, Ubuntu Jaunty. [2009-06-16 17:49:09] tony at tonybibbs dot com Same issue on 5.3.0RC2 using pretty much the same code in the initial bug report. [2009-02-18 08:51:00] nduteil at freedev dot org Hi, Still not fixed in the 5.2.8 release. If PDOStatement::bindParam or PDOStatement::bindValue is used to specified the parameter type (ie : PDO::PARAM_INT) everything works as expected. Not forcing the parameter type to integer generates an error in Mysql. 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/40740 -- Edit this bug report at http://bugs.php.net/?id=40740&edit=1
#49482 [Opn->Fbk]: SOAP encoding although WSDL requires use='LITERAL'
ID: 49482
Updated by: dmi...@php.net
Reported By: joep at clickhere dot nl
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: Ubuntu
PHP Version: 5.2.10
Assigned To: dmitry
New Comment:
Please provide a woring example code PHP+WSDL.
Previous Comments:
[2009-09-08 12:24:24] joep at clickhere dot nl
Nothing is so obscure as the W3C documents. Therefore, "they"
(microsoft :-) convened the WS-I group to come to some type of "best
practices". But document/literal-wrapped is not a part of that. It
became a "de facto" standard because MS uses it, as do most Java
implementations. Nowhere this is described clearly (except perhaps in
this document:
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Conclusion seems to be that xsi:type should not be sent.
Here http://jira.codehaus.org/browse/XFIRE-753 someone says that also
perl is in error when it sends "xsi:type".
So we think that the current PHP-implementation is not correct, type
information in document/literal is in the first place only given by the
xml-schema. On the other side the axis server complains about the
xsd:type and should just ignore it in this case to rely on the schema.
[2009-09-07 13:24:36] dmi...@php.net
This is not a bug. In case of 'use'='ENCODED' ext/soap always adds type
information and this check would just useless. In this place, it adds
type name specidied in 'classmap' for LITERAL encoding because without
it receiver won't be able to determine the real input type. Correct me
if I'm wrong (I can't be 100% sure as I don't see your code) and
demonstrate it with a small example.
BTW the 'classmap' concept is very limited. It was extended with
'typemap' concept which may give user the full control over generated
XML. Probably you need to use it.
[2009-09-06 10:29:52] joep at clickhere dot nl
Description:
I was hunting a bug in our soap-client. 'xsi:type' appears in the xml,
even when the WSDL states 'use="literal"'.
Our client works fine with 5.2.4, but since 5.2.7/5.2.8 its broken
(Also tested 5.2.9)
Came across this fix in ext/soap/php_encoding.c
+if (encode != enc && style == SOAP_LITERAL) {
add_type = 1;
-}
Shouldn't that be:
if (encode != enc && style == SOAP_ENCODED) {
add_type = 1;
}
--
Edit this bug report at http://bugs.php.net/?id=49482&edit=1
#49499 [Opn->Bgs]: get and set are not fixed
ID: 49499
Updated by: sjo...@php.net
Reported By: ies_clan at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP home
PHP Version: 5.3.0
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 __get() function returns a reference to the array, and this
reference is used to change the array.
Previous Comments:
[2009-09-08 11:32:21] ies_clan at hotmail dot com
Description:
look @ the code
Reproduce code:
---
";
return $this->properties[$key];
}
public function __set($key, $val) {
echo "set $key to $val";
$this->properties[$key] = $val;
}
}
$c = new newclass;
$c->array['test'] = 'test';
Expected result:
get array
set array to test
Actual result:
--
get array
--
Edit this bug report at http://bugs.php.net/?id=49499&edit=1
#49500 [NEW]: call_user_func object parameter is not passed as reference
From: casper at procurios dot nl
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: call_user_func object parameter is not passed as reference
Description:
When call_user_func is called with an object as it's second parameter,
it's not passed as reference. Instead the PHP warning 'Parameter 1 to
myFunction() expected to be a reference, value given' is cast.
myFunction() is not called at all.
This is a major compatibility break from 5.2.
Reproduce code:
---
class MyClass {
var $someVar = 'test';
}
function myFunction(&$Object) {
echo $Object->someVar . "\n";
}
$Object = new MyClass();
myFunction($Object);
call_user_func('myFunction', $Object);
Expected result:
test
test
Actual result:
--
test
PHP warning Parameter 1 to myFunction() expected to be a reference,
value given
--
Edit bug report at http://bugs.php.net/?id=49500&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49500&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49500&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49500&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49500&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49500&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49500&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49500&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49500&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49500&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49500&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49500&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49500&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49500&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49500&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49500&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49500&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49500&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49500&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49500&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49500&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49500&r=mysqlcfg
#49500 [Com]: call_user_func object parameter is not passed as reference
ID: 49500
Comment by: casper at procurios dot nl
Reported By: casper at procurios dot nl
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.0
New Comment:
My workaround code has a similar issue:
function workaroundforbug49500_call_user_func()
{
$params = func_get_args();
$func = array_shift($params);
return call_user_func_array($func, $params);
}
Casts: 'PHP warning Parameter 1 to myFunction() expected to be a
reference, value given' too.
func_get_args() seems affected too.
Previous Comments:
[2009-09-08 15:03:02] casper at procurios dot nl
Description:
When call_user_func is called with an object as it's second parameter,
it's not passed as reference. Instead the PHP warning 'Parameter 1 to
myFunction() expected to be a reference, value given' is cast.
myFunction() is not called at all.
This is a major compatibility break from 5.2.
Reproduce code:
---
class MyClass {
var $someVar = 'test';
}
function myFunction(&$Object) {
echo $Object->someVar . "\n";
}
$Object = new MyClass();
myFunction($Object);
call_user_func('myFunction', $Object);
Expected result:
test
test
Actual result:
--
test
PHP warning Parameter 1 to myFunction() expected to be a reference,
value given
--
Edit this bug report at http://bugs.php.net/?id=49500&edit=1
#49494 [Bgs]: php5apache2.dll not present in zip or msi
ID: 49494 User updated by: webmaster at pnmx dot com Reported By: webmaster at pnmx dot com Status: Bogus Bug Type: Apache2 related Operating System: Vista PHP Version: 5.3.0 New Comment: The VC9 x86 Thread Safe php 5.3 does not have the 2_2 dll, but the snapshot of the same version does! That's what I'm using now. Previous Comments: [2009-09-08 09:36:18] paj...@php.net Download the thread safe version of our releases. NTS is for FastCGI and other non thread safe SAPI. Apache requires a thread safe SAPI. [2009-09-08 04:40:57] webmaster at pnmx dot com FYI, there's no php5apache2_2.dll present either. There is a php5.dll but if you change httpd.conf to load that file, you get: Can't locate API module structure `php5_module' in file D:/Programs/PHP5.3/php5.dll So it's clearly not just misnamed. [2009-09-08 04:26:44] webmaster at pnmx dot com Description: php5papache2.dll mentioned in install.txt is not part of distributions on php.net. A couple of third party sources offer the dll, but their trustworthiness in unknown. Would prefer to download the file from php.net, the apache project, or at worst from sourceforge. Please don't say this doesn't indicate a bug in PHP. Duh! It's a bug in the distribution of PHP. That should matter too. This problem has been in every Windows version of PHP that I've ever installed. Why does it keep recurring? Reproduce code: --- Download and install php5.3 using either the Windows msi installer or by unpacking the 5.3 zip archive. In both cases, there is no php5papache2.dll or similar in the install directory. Expected result: php5papache2.dll available from php.net, ideally installed along with other elements of the configuration. Actual result: -- php5papache2.dll is not available from a trustworthy site. -- Edit this bug report at http://bugs.php.net/?id=49494&edit=1
#31323 [Com]: session file permissions differ randomly
ID: 31323
Comment by: maciejsliwa at op dot pl
Reported By: julien dot mathieu at gmail dot com
Status: No Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.1.2, 4.3.9
New Comment:
I have the same problem with O_RDWR, it happend in 20% of usage. It
strange, because on the same configuration, but only on diffrent
computer it works fine.
Computer on which i have problems
Notebook HP 6153ea dualcore 1,66Ghz
Windows XP Media Center Edition
PHP 5.3.0
server Apache
Server was instaled by EasyPHP 2.0
the second computer which configuration is identical is
AMD Athlon 1Ghz
Windows XP Profesional
PHP 5.3.0
server Apache
and on this its works fine
[Tue Sep 08 19:44:37 2009] [error] [client 127.0.0.1] PHP Warning:
session_start() [function.session-start]:
open(C:\\DOCUME~1\\Maciek\\LOCALS~1\\Tempsess_jcje64e16gqqtpktra8jndo990,
O_RDWR) failed: Permission denied (13) in C:\\Program
Files\\EasyPHP3_1\\www\\Magazyn\\magazynMain.php on line 3, referer:
http://127.0.0.1/Magazyn/magazyn.php
Previous Comments:
[2009-03-31 14:47:16] prikid at gmail dot com
We are experiencing similar problem with php 5.2.6 on freebsd and red
hat linux
[2008-08-12 16:21:03] linus dot norton at assertis dot co dot uk
I have also encountered this twice on redhat running apache 2.2.6 and
php 5.2.6.
Why has this been closed, no feedback was requested then the ticket is
just closed saying no feedback has been given.
[2006-11-09 14:44:35] mg at iceni dot pl
I can confirm this bug happening on php 4.4.2 build as apache 2 (with
prefork) module. It's extremaly difficult to reproduce, but with little
research it seems to be somehow umask related.
The following is from strace running on a apache process that creates
the files with wrong permissions
open("/tmp/sess_5b2929b94cf141335d0b2d1e5a38fc29", O_RDWR|O_CREAT,
0600) = 186
fstat64(186, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
So php creates file with 600 permissions but it has only 400 in final.
Note that's happening very rarely, normally file is created with 600.
I didn't have luck tracing how and when umask is changing during
request processing (probably something is changing it prior to the
request, so possibly it's not even php related), but I tried to make the
following very dirty workaround in ext/session/mod_files.c:
@@ -138,6 +138,7 @@
static void ps_files_open(ps_files *data, const char *key TSRMLS_DC)
{
char buf[MAXPATHLEN];
+ mode_t orig_mask;
if (data->fd < 0 || !data->lastkey || strcmp(key,
data->lastkey)) {
if (data->lastkey) {
@@ -156,8 +157,10 @@
data->lastkey = estrdup(key);
+ orig_mask = umask(0);
data->fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR |
O_BINARY, 0600);
-
+ umask(orig_mask);
+
No matter how ugly it is - it seems to do the job and session files
with wrong permissions are no longer created (this workaround is
probably bad idea on threaded severs though).
[2006-11-05 00:16:32] bclaydon at volved dot com
To provide further details, I am also using Debian (Sarge) with the
latest 4.3.10-16 PHP4 package.
My /var/liv/php4 looks exactly as 'pieter at q-go dot com' mentioned:
drwx-wx-wt 2 root root 4.0K 2006-11-04 18:58 ./
drwxr-xr-x 35 root root 4.0K 2006-09-08 19:11 ../
-rw--- 1 www-data www-data 77 2006-11-04 18:58
sess_7b8da94a2febce75775d9082cd20d58d
-rw--- 1 www-data www-data 116 2006-11-04 19:05
sess_856401c969cc1d4e68b6ffd75457c743
-rw--- 1 www-data www-data 116 2006-11-04 18:58
sess_b5419618a3586b7e3b940a0eaf137fb9
-rw--- 1 www-data www-data 116 2006-11-04 19:09
sess_f7d957b726ff923b4b1f6178f8db489f
I am seeing this issue fairly frequently during usage of CakePHP
framework which has fairly detailed usage of session functions.
I hope this is resolved at some point, especially if it is still open
as of 5.2.0
[2006-05-22 09:20:29] pieter at q-go dot com
We have similar problems on Debian with PHP 5.1.2 and 5.1.4.
Sessions are all created with correct permissions, but we get the same
permission denied error in 5% of the cases.
drwx-wx-wt 2 root root 4096 May 22 11:03 .
drwxr-xr-x 27 root root 4096 May 18 13:44 ..
-rw--- 1 www-data www-data0 May 22 11:03
sess_11f06ca5b4701f4be8be30b275e4e51e
-rw--- 1 www-data www-data 1569 May 22 11:00
sess_1856e3c4630f074a1b0490c4792c3e53
-rw--- 1 www-data www-data0 May 22 10:2
#27051 [Fbk]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051
Updated by: paj...@php.net
Reported By: ghoffer at globalscape dot com
Status: Feedback
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 5.3
Assigned To: pajoye
New Comment:
Just a quick note about the user profile, it is not set (by design) so
I won't try to access the profile data.
More on the impersonated problem later.
Previous Comments:
[2009-09-07 22:42:29] benadler at gmx dot net
I checked using Process Monitor - convert.exe is NOT started by the
correct user:
User: NT AUTHORITY\NETWORK SERVICE
Auth ID: :03e4
[2009-09-07 11:34:10] paj...@php.net
I'm not sure the users environment is set, that's a different thing.
But is it the correct user?
[2009-09-07 11:17:13] benadler at gmx dot net
Hope I'm not too verbose. Maybe it helps to see that calling this
exec("d:/programme/imagemagick/convert.exe -density $density
$baseDirectory/$bookId/document.pdf -quality 95
$baseDirectory/$bookId/$version/page_%04d.jpg", $output);
print_r($output);
in a script run by the webserver (as above) causes this:
Array
(
[0] => Error: /invalidfileaccess in --showpage--
[1] => Operand stack:
[2] =>--nostringval-- 1 true
[3] => Execution stack:
[4] =>%interp_exit .runexec2 --nostringval--
--nostringval-- --nostringval-- 2 %stopped_push --nostringval--
--nostringval-- --nostringval-- false 1 %stopped_push 1905
1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3
%oparray_pop --nostringval-- --nostringval-- 2 1 4
--nostringval-- %for_pos_int_continue --nostringval--
--nostringval-- 1777 1 9 %oparray_pop --nostringval--
--nostringval--
[5] => Dictionary stack:
[6] =>--dict:1155/1684(ro)(G)-- --dict:1/20(G)--
--dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)--
--dict:275/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)--
--dict:22/40(L)--
[7] => Current allocation mode is local
[8] => Last OS error: Bad file descriptor
)
[2009-09-07 11:11:06] benadler at gmx dot net
Ok, it works on the commandline but not using IIS6 and fastcgi with
fastcgi.impersonate = 1;.
This is test.php:
and this results in:
%USERNAME%Array
(
[0] => %USERNAME%
)
C:\Documents and Settings\Default UserArray
(
[0] => C:\Documents and Settings\Default User
)
So it seems the user's profile/environment is not correctly set up.
I think username should be either domain\deabjs1 or just deabjs1,
because this is what I use to log on to IIS using NTLM. I'm still using
the same snapshot I was using at [6 Sep 6:13pm UTC].
Thanks for your help!
ben
[2009-09-06 18:13:09] benadler at gmx dot net
I tried the newest snapshot and it seems to work - thank you!
But, could it be that the environment is not set up correctly?
Suddenly I start getting all those imagemagick-temp files in the
script's directory. I imagine the reason may be that the %TEMP% or
%TMP% system/user variables are not set correctly.
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/27051
--
Edit this bug report at http://bugs.php.net/?id=27051&edit=1
#49494 [Bgs]: php5apache2.dll not present in zip or msi
ID: 49494 User updated by: webmaster at pnmx dot com Reported By: webmaster at pnmx dot com Status: Bogus Bug Type: Apache2 related Operating System: Vista PHP Version: 5.3.0 New Comment: Yep. Found the php5apache2_2.dll in the VC9 ThreadSafe release alright. But Apache httpd doesn't like it. httpd started right up with the current snapshot. I don't know what's different, but Apache likes the snapshot - doesn't like the released version. Previous Comments: [2009-09-08 16:24:44] paj...@php.net Wrong, it has both the normal module and the filter module: php5apache2_2.dll php5apache2_2_filter.dll [2009-09-08 16:15:49] webmaster at pnmx dot com The VC9 x86 Thread Safe php 5.3 does not have the 2_2 dll, but the snapshot of the same version does! That's what I'm using now. [2009-09-08 09:36:18] paj...@php.net Download the thread safe version of our releases. NTS is for FastCGI and other non thread safe SAPI. Apache requires a thread safe SAPI. [2009-09-08 04:40:57] webmaster at pnmx dot com FYI, there's no php5apache2_2.dll present either. There is a php5.dll but if you change httpd.conf to load that file, you get: Can't locate API module structure `php5_module' in file D:/Programs/PHP5.3/php5.dll So it's clearly not just misnamed. [2009-09-08 04:26:44] webmaster at pnmx dot com Description: php5papache2.dll mentioned in install.txt is not part of distributions on php.net. A couple of third party sources offer the dll, but their trustworthiness in unknown. Would prefer to download the file from php.net, the apache project, or at worst from sourceforge. Please don't say this doesn't indicate a bug in PHP. Duh! It's a bug in the distribution of PHP. That should matter too. This problem has been in every Windows version of PHP that I've ever installed. Why does it keep recurring? Reproduce code: --- Download and install php5.3 using either the Windows msi installer or by unpacking the 5.3 zip archive. In both cases, there is no php5papache2.dll or similar in the install directory. Expected result: php5papache2.dll available from php.net, ideally installed along with other elements of the configuration. Actual result: -- php5papache2.dll is not available from a trustworthy site. -- Edit this bug report at http://bugs.php.net/?id=49494&edit=1
#49500 [Opn->Bgs]: call_user_func object parameter is not passed as reference
ID: 49500
Updated by: j...@php.net
Reported By: casper at procurios dot nl
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.0
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.
Previous Comments:
[2009-09-08 15:28:48] casper at procurios dot nl
My workaround code has a similar issue:
function workaroundforbug49500_call_user_func()
{
$params = func_get_args();
$func = array_shift($params);
return call_user_func_array($func, $params);
}
Casts: 'PHP warning Parameter 1 to myFunction() expected to be a
reference, value given' too.
func_get_args() seems affected too.
[2009-09-08 15:03:02] casper at procurios dot nl
Description:
When call_user_func is called with an object as it's second parameter,
it's not passed as reference. Instead the PHP warning 'Parameter 1 to
myFunction() expected to be a reference, value given' is cast.
myFunction() is not called at all.
This is a major compatibility break from 5.2.
Reproduce code:
---
class MyClass {
var $someVar = 'test';
}
function myFunction(&$Object) {
echo $Object->someVar . "\n";
}
$Object = new MyClass();
myFunction($Object);
call_user_func('myFunction', $Object);
Expected result:
test
test
Actual result:
--
test
PHP warning Parameter 1 to myFunction() expected to be a reference,
value given
--
Edit this bug report at http://bugs.php.net/?id=49500&edit=1
#49494 [Bgs]: php5apache2.dll not present in zip or msi
ID: 49494 Updated by: paj...@php.net Reported By: webmaster at pnmx dot com Status: Bogus Bug Type: Apache2 related Operating System: Vista PHP Version: 5.3.0 New Comment: I suppose you got apache from apache.org right? Then use the VC6 thread build. Or use apachelounge.com's version. There is no difference between the snapshot and the release version, the same libraries are used. Previous Comments: [2009-09-08 18:02:05] webmaster at pnmx dot com Yep. Found the php5apache2_2.dll in the VC9 ThreadSafe release alright. But Apache httpd doesn't like it. httpd started right up with the current snapshot. I don't know what's different, but Apache likes the snapshot - doesn't like the released version. [2009-09-08 16:24:44] paj...@php.net Wrong, it has both the normal module and the filter module: php5apache2_2.dll php5apache2_2_filter.dll [2009-09-08 16:15:49] webmaster at pnmx dot com The VC9 x86 Thread Safe php 5.3 does not have the 2_2 dll, but the snapshot of the same version does! That's what I'm using now. [2009-09-08 09:36:18] paj...@php.net Download the thread safe version of our releases. NTS is for FastCGI and other non thread safe SAPI. Apache requires a thread safe SAPI. [2009-09-08 04:40:57] webmaster at pnmx dot com FYI, there's no php5apache2_2.dll present either. There is a php5.dll but if you change httpd.conf to load that file, you get: Can't locate API module structure `php5_module' in file D:/Programs/PHP5.3/php5.dll So it's clearly not just misnamed. 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/49494 -- Edit this bug report at http://bugs.php.net/?id=49494&edit=1
#49501 [NEW]: Memory leak ending up in Out of Memory errors
From: romain dot riviere at gmail dot com
Operating system: Gentoo Linux 32bit
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: Memory leak ending up in Out of Memory errors
Description:
While trying to diagnose apparently random Out of Memory errors in various
PHP scripts (including Drupal among others), I ended up using the code
pasted below for testing purposes.
Browing the resulting page several times always results in an
ever-increasing VSZ for apache processes (up to 4GB in my case) and
eventually Out of Memory errors way before the script itself actually
reaches the limit. The script was called with size=61 in my case
(memory_limit=64M). On an 8GB system, it might take as many as 30 requests
to recreate the bug. With a higher memory limit and value of the "size"
parameter, it will probably happen much sooner.
PHP compiled with
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
For the first few runs, the script correctly displays the memory usage and
the value is consistent with the memory limit :
Memory limit: 64M
String length: 65011712
Actual result:
--
Memory limit: 64M
Fatal error: Out of memory (allocated 61341696) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on line
14
Subsequent runs :
Fatal error: Out of memory (allocated 262144) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on line
14
--
Edit bug report at http://bugs.php.net/?id=49501&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49501&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49501&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49501&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49501&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49501&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49501&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49501&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49501&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49501&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49501&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49501&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49501&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49501&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49501&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49501&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49501&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49501&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49501&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49501&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49501&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49501&r=mysqlcfg
#49503 [NEW]: "failed to open semaphore file"
From: mike at fuelsaver-mpg dot com Operating system: Linux 2.6.9-023stab048.6-enterpr PHP version: 5.2.10 PHP Bug Type: Session related Bug description: "failed to open semaphore file" Description: When I upgraded to php 5.2.10, I had my error log growing to 100s of MBs with error messages that it was unable to open its semaphore file. I un-commented the php.ini line: "session.save_path = ", created a directory that could be written to, and this resolved that particular error. However, I'm still getting the following errors, albeit on a less frequent basis. I got 53 of these in one day however: [07-Sep-2009 00:24:46] PHP Warning: PHP Startup: mm_create(0, /home/fuelsa5/tmp/php/session_mm_cgi32010) failed, err mm:core: failed to open semaphore file (File exists) in Unknown on line 0 There are files being created in the directory, so it's not a permissions issue. Per the warning, a duplicate file is attempting to be created. Expected result: I expect not to get so many error messages. I'm not even sure what's breaking. -- Edit bug report at http://bugs.php.net/?id=49503&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49503&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49503&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49503&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49503&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49503&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49503&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49503&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49503&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49503&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49503&r=support Expected behavior: http://bugs.php.net/fix.php?id=49503&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49503&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49503&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49503&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49503&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49503&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49503&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49503&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49503&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49503&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49503&r=mysqlcfg
#49501 [Opn]: Memory leak ending up in Out of Memory errors
ID: 49501
User updated by: romain dot riviere at gmail dot com
Reported By: romain dot riviere at gmail dot com
Status: Open
Bug Type: *General Issues
Operating System: Gentoo Linux 32bit
PHP Version: 5.2.10
New Comment:
The last line of the initial description should have read : PHP
compiled --with-pic.
For the record, the problem appeared in Drupal and was reported as
happening at zend_opcode.c:48. However, since it can obviously be
reproduced with something as simple as a string, I believe it is a more
general memory leak issue.
Previous Comments:
[2009-09-08 19:04:48] romain dot riviere at gmail dot com
Description:
While trying to diagnose apparently random Out of Memory errors in
various PHP scripts (including Drupal among others), I ended up using
the code pasted below for testing purposes.
Browing the resulting page several times always results in an
ever-increasing VSZ for apache processes (up to 4GB in my case) and
eventually Out of Memory errors way before the script itself actually
reaches the limit. The script was called with size=61 in my case
(memory_limit=64M). On an 8GB system, it might take as many as 30
requests to recreate the bug. With a higher memory limit and value of
the "size" parameter, it will probably happen much sooner.
PHP compiled with
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
For the first few runs, the script correctly displays the memory usage
and the value is consistent with the memory limit :
Memory limit: 64M
String length: 65011712
Actual result:
--
Memory limit: 64M
Fatal error: Out of memory (allocated 61341696) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
Subsequent runs :
Fatal error: Out of memory (allocated 262144) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
--
Edit this bug report at http://bugs.php.net/?id=49501&edit=1
#49501 [Opn]: Memory leak ending up in Out of Memory errors
ID: 49501
Updated by: ras...@php.net
Reported By: romain dot riviere at gmail dot com
Status: Open
Bug Type: *General Issues
Operating System: Gentoo Linux 32bit
PHP Version: 5.2.10
New Comment:
Are you saying you don't see it if you don't use --with-pic?
And I am curious, why do you want pic? libphp5.so isn't a
general-purpose shared library that can be linked into many different
things. It is a very targeted library compiled for a specific binary to
link and as such compiling it pic just adds unnecessary overhead.
Previous Comments:
[2009-09-08 20:42:30] romain dot riviere at gmail dot com
The last line of the initial description should have read : PHP
compiled --with-pic.
For the record, the problem appeared in Drupal and was reported as
happening at zend_opcode.c:48. However, since it can obviously be
reproduced with something as simple as a string, I believe it is a more
general memory leak issue.
[2009-09-08 19:04:48] romain dot riviere at gmail dot com
Description:
While trying to diagnose apparently random Out of Memory errors in
various PHP scripts (including Drupal among others), I ended up using
the code pasted below for testing purposes.
Browing the resulting page several times always results in an
ever-increasing VSZ for apache processes (up to 4GB in my case) and
eventually Out of Memory errors way before the script itself actually
reaches the limit. The script was called with size=61 in my case
(memory_limit=64M). On an 8GB system, it might take as many as 30
requests to recreate the bug. With a higher memory limit and value of
the "size" parameter, it will probably happen much sooner.
PHP compiled with
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
For the first few runs, the script correctly displays the memory usage
and the value is consistent with the memory limit :
Memory limit: 64M
String length: 65011712
Actual result:
--
Memory limit: 64M
Fatal error: Out of memory (allocated 61341696) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
Subsequent runs :
Fatal error: Out of memory (allocated 262144) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
--
Edit this bug report at http://bugs.php.net/?id=49501&edit=1
#44193 [Com]: snmp v3 noAuthNoPriv doesn't work
ID: 44193
Comment by: larryjadams at comcast dot net
Reported By: mavezeau at colubris dot com
Status: Open
Bug Type: SNMP related
Operating System: Mandriva 2005/linux
PHP Version: 5.2CVS-2008-10-27
New Comment:
That's not quite it. That section of the code simply needs to be
finished, let alone be documented.
Previous Comments:
[2008-10-27 16:33:50] mavezeau at colubris dot com
Now,
Some parts work. The security level AuthNoPriv and AuthPriv work but
noAuthNoPriv doesn't works because php doesn't accept null or '' to
auth_protocol and priv_protocol. I think this fix is simple the snmp v3
with noAuthNopriv is very similar of snmp v2c.
if I try:
snmp3_walk('192.168.130.124','test','noAuthNoPriv','MD5','','','','');
I have this error "error(snmp3_walk(): Could not generate key for
authentication pass phrase: MD5)"
if I try:
snmp3_walk('192.168.130.124','test','noAuthNoPriv',null,null,null,null,'');
or
snmp3_walk('192.168.130.124','test','noAuthNoPriv','',null,null,null,'');
I have this error "Invalid authenfication protocol:"
[2008-02-20 21:23:28] mavezeau at colubris dot com
Description:
I try to make a query with snmp v3 and I have an error: "snmp3_walk():
An error occurred" or "snmp3_walk(): No response from 192.168.130.124".
If I execute a query with net-snmp 5.4.1 the query is ok. If I execute
the similar query with php I have those errors.
Reproduce code:
---
AuthNoPriv
net-snmp Query:
snmpwalk -v 3 -l authNoPriv -a MD5 -A jesuisuntest -u test5
192.168.130.124
it Works!
Php snmp
snmp3_walk('192.168.130.124','test5','authNoPriv','MD5','jesuisuntest','','','');
Error !
noAuthNoPriv
net-snmp query:
snmpwalk -v 3 -l noAuthNoPriv -u test 192.168.130.124
it works!
PHP snmp
snmp3_walk('192.168.130.124','test','noAuthNoPriv','','','','','');
error(snmp3_walk(): Invalid authentication protocol)
if use the default
snmp3_walk('192.168.130.124','test','noAuthNoPriv','MD5','','','','');
error(snmp3_walk(): Could not generate key for authentication pass
phrase: MD5)
Expected result:
Similar return value than smnp v2c
Actual result:
--
all method make an error
--
Edit this bug report at http://bugs.php.net/?id=44193&edit=1
#49502 [NEW]: Display bug
From: tristan dot m at free dot fr Operating system: Multiple PHP version: 5.3.0 PHP Bug Type: Unknown/Other Function Bug description: Display bug Description: There is a bug when you add "/post" at the end of an URL. This bug is from servers side, not on all php versions/o.s. (unknow) examples here: http://www.creer-blog.fr/index.php/post http://www.6mablog.com/index.php/post -- Edit bug report at http://bugs.php.net/?id=49502&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49502&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49502&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49502&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49502&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49502&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49502&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49502&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49502&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49502&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49502&r=support Expected behavior: http://bugs.php.net/fix.php?id=49502&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49502&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49502&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49502&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49502&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49502&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49502&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49502&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49502&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49502&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49502&r=mysqlcfg
#46065 [Com]: snmp_set_quick_print() persists between requests
ID: 46065 Comment by: larryjadams at comcast dot net Reported By: php at painfullscratch dot nl Status: Open Bug Type: SNMP related Operating System: * PHP Version: 5.*, 6 New Comment: The snmp module needs a bit of rededesign. It should handle many of the commands from the native calls, like multiple OID get's in a single array, in other words, make the OID a mixed type for a get request. Also, the snmp functions should require a resource (aka snmp session) in order to work, just like is done in the API, for which it would be based. In that case, to setup a quick print, you start a session, receive a pointer to a (structure/resource) in return and then all subsequent calls need to also pass the resource to the function. Once you are done, you need to close the sessions. This will have to be a new class of calls though as simply changing thing around will make life difficult for everyone. TheWitness Previous Comments: [2008-10-24 08:56:21] j...@php.net It's pretty simple issue, propably need to add some netsnmp shutdown function in RINIT which clears all the settings between requests. [2008-09-12 13:27:09] php at painfullscratch dot nl Description: When PHP runs under Apache and snmp_set_quick_print(TRUE) is issued, the behavior of all SNMP-related functions will be "quick print" for the lifetime of the PID. NET-SNMP Support => enabled NET-SNMP Version => 5.4.1 PHP version: 5.2.4 There are two possibilities: 1) This behavior is "by design": If this is the case I think the manual page for snmp_set_quick_print() needs a warning for this behavior. 2) This is a bug: For each PID the behavior should be (re)set to the default behavior after execution of the script. Reproduce code: --- p...@workmate:/tmp$ sudo /etc/init.d/apache2 restart > /dev/null 2>&1 p...@workmate:/tmp$ for (( i=0; i<5; i++ )) ; do links -dump http://localhost/snmp_get_quick_print.php; done snmp_get_quick_print: '' | pid: '9402' snmp_get_quick_print: '' | pid: '9403' snmp_get_quick_print: '' | pid: '9404' snmp_get_quick_print: '' | pid: '9405' snmp_get_quick_print: '' | pid: '9406' p...@workmate:/tmp$ links -dump http://localhost/snmp_set_quick_print.php snmp_set_quick_print: '' | pid: '9406' p...@workmate:/tmp$ for (( i=0; i<5; i++ )) ; do links -dump http://localhost/snmp_get_quick_print.php; done snmp_get_quick_print: '' | pid: '9403' snmp_get_quick_print: '' | pid: '9404' snmp_get_quick_print: '' | pid: '9446' snmp_get_quick_print: '' | pid: '9405' snmp_get_quick_print: '1' | pid: '9406' -- Edit this bug report at http://bugs.php.net/?id=46065&edit=1
#49502 [Opn->Bgs]: Display bug
ID: 49502 Updated by: ras...@php.net Reported By: tristan dot m at free dot fr -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Multiple PHP Version: 5.3.0 New Comment: This has nothing to do with PHP. This is a path-related CSS/Javascript issue. Previous Comments: [2009-09-08 19:33:57] tristan dot m at free dot fr Description: There is a bug when you add "/post" at the end of an URL. This bug is from servers side, not on all php versions/o.s. (unknow) examples here: http://www.creer-blog.fr/index.php/post http://www.6mablog.com/index.php/post -- Edit this bug report at http://bugs.php.net/?id=49502&edit=1
#29085 [Opn->Asn]: bad default include_path on Windows
ID: 29085
Updated by: paj...@php.net
Reported By: christian at wenz dot org
-Status: Open
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 5.0.0RC3
-Assigned To:
+Assigned To: pajoye
New Comment:
Agreed. Let change it in trunk at least, or maybe in 5.3.2 as well.
Previous Comments:
[2009-09-07 23:43:37] php dot netsm at majorsite dot com
I, too, find this VERY confusing, and I can't seem to get around it.
Running Win2K Server (was to upgrade this year - market stopped
that...) and have had PHP running on 5.0.3 for awhile (in C:\Program
Files\PHP - the 'default' from the install).
Went to upgrade and found latest versions need Win2003 Server or
better, so I had to take 5.2.10, but I cannot get the .ini to read.
Install.txt file says to avoid \program files\ so I deleted that and
went for a 'clean' install to \php\
phpinfo() says I'm looking at loaded .ini from C:\PHP\php.ini I've
tried setting the php.ini include_path = ".;c:\php;c:\php\ext", yet
phpinfo() says include_path is .;C:\php5\pear
The comments on this page were from 2004 - and the 'fix' was that
"people want to run php4 and php5, though, how long has php4 been gone,
and this issue is still relevant 5 years on. this IS (IMHO) a BAD
thing and very confusing.
I look forward to some reply as I now have php running again, but none
of my databases run, none of my 'include' files work, etc.
And, please do not tell me to save my .ini file in some other location
- I've tried \winnt\system32, \winnt, c:\ and certainly c:\php - nothing
has worked. I am almost frustrated enough to try c:\php5 and even
c:\php5\pear, but I am trying to use the install instructions!
I think this php5 error is a bug and should be fixed - even in other
versions of php (for those of us that can't afford the upgrade).
[2005-02-15 01:08:11] tony2...@php.net
This is not a bug, but change request.
Reclassifying.
[2005-01-05 21:34:30] justin at telepop dot net
This setting just caused me some problems. Somehow my php.ini had a
bad path in its include_path setting. Rather than spit out an error, it
assumed that c:\php4\pear was my default include directory, and gave me
little information to figure out why. Once I fixed the path, my
declared settings took effect and everything worked fine, but it wasn't
a very intuitive leap to see why that include path was showing up.
[2004-08-06 08:54:57] christian at wenz dot org
sorry, here I completely disagree. Of course it _is_ possible to change
the include_path manually or within the script, however there is a
divergence between the installation section of the manual (where it says
"C:\php") and this built-in behavior of PHP ("C:\php5"). Also, I know of
only very few people who actually use both versions on one machine (only
few now of the possibility to store php.ini in the PHP directory and not
in the Windows directory; furthermore you have to use PHP as CGI).
This bug appears again and again; I am getting 2-3 reader mails about
this per month; and it is (IMO) just annoying. Therefore, one thing has
to change IMO: either the installation recommends installing PHP into
C:\php5, or the include_path is set to something that includes C:\php.
Of course, the latter is preferable. So I dare to reopen this one :)
[2004-08-05 23:33:44] ed...@php.net
Well this is a matter of opinion :) Most people prefer to be able to
run php4 and php5 on the same box right now. This might change in the
future. Anyway setting include_path in php.ini isn't that difficult, is
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/29085
--
Edit this bug report at http://bugs.php.net/?id=29085&edit=1
#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: woo at 126 dot com Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: As the currency in the Warhammer world, plays an important role in the economic system. Previous Comments: [2009-08-12 09:53:43] qiaosilver at 163 dot com http://www.uggboots-zone.com/ ugg boots http://www.ed-hardy.cc/ed-hardy-men-accessories/ed-hardy-scarves.html ed hardy scarves [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? [2005-11-25 15:14:33] lists at cyberlot dot net What OS are you testing on? All I have are Centos/Redhat based boxes to test on. Also if this helps I always download directly from MySQL I never use the DIST included rpms. 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#49501 [Opn]: Memory leak ending up in Out of Memory errors
ID: 49501
User updated by: romain dot riviere at gmail dot com
Reported By: romain dot riviere at gmail dot com
Status: Open
Bug Type: *General Issues
Operating System: Gentoo Linux 32bit
PHP Version: 5.2.10
New Comment:
I'm mentioning pic because it is the only thing slightly out of the
ordinary in this setup.
I am using pic because of disabled TEXTRELs in the PaX enabled kernel.
I'm willing to try without pic though. I'll add to this report in case
it changes anything.
Previous Comments:
[2009-09-08 20:57:05] ras...@php.net
Are you saying you don't see it if you don't use --with-pic?
And I am curious, why do you want pic? libphp5.so isn't a
general-purpose shared library that can be linked into many different
things. It is a very targeted library compiled for a specific binary to
link and as such compiling it pic just adds unnecessary overhead.
[2009-09-08 20:42:30] romain dot riviere at gmail dot com
The last line of the initial description should have read : PHP
compiled --with-pic.
For the record, the problem appeared in Drupal and was reported as
happening at zend_opcode.c:48. However, since it can obviously be
reproduced with something as simple as a string, I believe it is a more
general memory leak issue.
[2009-09-08 19:04:48] romain dot riviere at gmail dot com
Description:
While trying to diagnose apparently random Out of Memory errors in
various PHP scripts (including Drupal among others), I ended up using
the code pasted below for testing purposes.
Browing the resulting page several times always results in an
ever-increasing VSZ for apache processes (up to 4GB in my case) and
eventually Out of Memory errors way before the script itself actually
reaches the limit. The script was called with size=61 in my case
(memory_limit=64M). On an 8GB system, it might take as many as 30
requests to recreate the bug. With a higher memory limit and value of
the "size" parameter, it will probably happen much sooner.
PHP compiled with
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
For the first few runs, the script correctly displays the memory usage
and the value is consistent with the memory limit :
Memory limit: 64M
String length: 65011712
Actual result:
--
Memory limit: 64M
Fatal error: Out of memory (allocated 61341696) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
Subsequent runs :
Fatal error: Out of memory (allocated 262144) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
--
Edit this bug report at http://bugs.php.net/?id=49501&edit=1
#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: caiyilnlove at yahoo dot cn Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: chi hair iron http://www.chihaironline.com Classic Cardy Ugg Boots http://www.myuggboots100.com/classic-cardy-ugg-boots.html Previous Comments: [2009-09-09 02:12:46] woo at 126 dot com As the currency in the Warhammer world, plays an important role in the economic system. [2009-08-12 09:53:43] qiaosilver at 163 dot com http://www.uggboots-zone.com/ ugg boots http://www.ed-hardy.cc/ed-hardy-men-accessories/ed-hardy-scarves.html ed hardy scarves [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#41187 [Com]: DateTime::setDefaultFormat for standard __toString() output of DateTime objects
ID: 41187 Comment by: grodny at oneclick dot sk Reported By: r dot korving at xit dot nl Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 5.2.2RC1 New Comment: This would be nice to implement at least into 5.3 version. Previous Comments: [2007-04-25 15:00:31] r dot korving at xit dot nl Description: it would be nice if a static function DateTime::setDefaultFormat() was added to the DateTime class, which can set a default output format which can be used by DateTime's __toString() - which is also currently non-existing. -- Edit this bug report at http://bugs.php.net/?id=41187&edit=1
#49501 [Opn]: Memory leak ending up in Out of Memory errors
ID: 49501
User updated by: romain dot riviere at gmail dot com
Reported By: romain dot riviere at gmail dot com
Status: Open
Bug Type: *General Issues
Operating System: Gentoo Linux 32bit
PHP Version: 5.2.10
New Comment:
Just to confirm: the problem is still present without pic.
Previous Comments:
[2009-09-09 03:23:14] romain dot riviere at gmail dot com
I'm mentioning pic because it is the only thing slightly out of the
ordinary in this setup.
I am using pic because of disabled TEXTRELs in the PaX enabled kernel.
I'm willing to try without pic though. I'll add to this report in case
it changes anything.
[2009-09-08 20:57:05] ras...@php.net
Are you saying you don't see it if you don't use --with-pic?
And I am curious, why do you want pic? libphp5.so isn't a
general-purpose shared library that can be linked into many different
things. It is a very targeted library compiled for a specific binary to
link and as such compiling it pic just adds unnecessary overhead.
[2009-09-08 20:42:30] romain dot riviere at gmail dot com
The last line of the initial description should have read : PHP
compiled --with-pic.
For the record, the problem appeared in Drupal and was reported as
happening at zend_opcode.c:48. However, since it can obviously be
reproduced with something as simple as a string, I believe it is a more
general memory leak issue.
[2009-09-08 19:04:48] romain dot riviere at gmail dot com
Description:
While trying to diagnose apparently random Out of Memory errors in
various PHP scripts (including Drupal among others), I ended up using
the code pasted below for testing purposes.
Browing the resulting page several times always results in an
ever-increasing VSZ for apache processes (up to 4GB in my case) and
eventually Out of Memory errors way before the script itself actually
reaches the limit. The script was called with size=61 in my case
(memory_limit=64M). On an 8GB system, it might take as many as 30
requests to recreate the bug. With a higher memory limit and value of
the "size" parameter, it will probably happen much sooner.
PHP compiled with
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
For the first few runs, the script correctly displays the memory usage
and the value is consistent with the memory limit :
Memory limit: 64M
String length: 65011712
Actual result:
--
Memory limit: 64M
Fatal error: Out of memory (allocated 61341696) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
Subsequent runs :
Fatal error: Out of memory (allocated 262144) at
/var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/ext/standard/string.c:4599
(tried to allocate 1048577 bytes) in /home/acrm/OF-svn/2.0/test.php on
line 14
--
Edit this bug report at http://bugs.php.net/?id=49501&edit=1
#49494 [Bgs]: php5apache2.dll not present in zip or msi
ID: 49494 Updated by: paj...@php.net Reported By: webmaster at pnmx dot com Status: Bogus Bug Type: Apache2 related Operating System: Vista PHP Version: 5.3.0 New Comment: Wrong, it has both the normal module and the filter module: php5apache2_2.dll php5apache2_2_filter.dll Previous Comments: [2009-09-08 16:15:49] webmaster at pnmx dot com The VC9 x86 Thread Safe php 5.3 does not have the 2_2 dll, but the snapshot of the same version does! That's what I'm using now. [2009-09-08 09:36:18] paj...@php.net Download the thread safe version of our releases. NTS is for FastCGI and other non thread safe SAPI. Apache requires a thread safe SAPI. [2009-09-08 04:40:57] webmaster at pnmx dot com FYI, there's no php5apache2_2.dll present either. There is a php5.dll but if you change httpd.conf to load that file, you get: Can't locate API module structure `php5_module' in file D:/Programs/PHP5.3/php5.dll So it's clearly not just misnamed. [2009-09-08 04:26:44] webmaster at pnmx dot com Description: php5papache2.dll mentioned in install.txt is not part of distributions on php.net. A couple of third party sources offer the dll, but their trustworthiness in unknown. Would prefer to download the file from php.net, the apache project, or at worst from sourceforge. Please don't say this doesn't indicate a bug in PHP. Duh! It's a bug in the distribution of PHP. That should matter too. This problem has been in every Windows version of PHP that I've ever installed. Why does it keep recurring? Reproduce code: --- Download and install php5.3 using either the Windows msi installer or by unpacking the 5.3 zip archive. In both cases, there is no php5papache2.dll or similar in the install directory. Expected result: php5papache2.dll available from php.net, ideally installed along with other elements of the configuration. Actual result: -- php5papache2.dll is not available from a trustworthy site. -- Edit this bug report at http://bugs.php.net/?id=49494&edit=1
#48754 [Com]: mysql_close() crash php when no handle specified
ID: 48754
Comment by: louis at steelbytes dot com
Reported By: busia at tiscali dot it
Status: Verified
Bug Type: MySQL related
Operating System: *
PHP Version: 5.3.0 (as of 21-07-2008)
Assigned To: mysql
New Comment:
repro on 5.3.0 on Win2003 using php.exe in command shell. didn't have
this problem with 5.2.10
Previous Comments:
[2009-08-28 23:27:08] empacc100 at seznam dot cz
WinXP SP3, PHP 5.3.0 VC9 TS, Apache 2.2.13 (apachelounge) + mod_fcgid
2.2b, MySQL 5.1.37 == same bug (php-cgi.exe crash)
/*
* php-cgi.exe OK
*/
$a=mysql_connect('127.0.0.1:3306', 'root', 'fdgdfgd'));
mysql_close($a);
/*
* php-cgi.exe CRASH
*/
mysql_connect('127.0.0.1:3306', 'root', 'fdgdfgd'));
mysql_close();
[2009-08-26 05:13:12] jfb at zer7 dot com
I get this as well. I had avoided upgrading my ancient PHP code (some
of it was from PHP4); turns out it being that ancient also means it uses
old patterns, like not using handles. :)
Likely that newer code will not encounter this, so it'll be folks
upgrading slowly and cautiously.
[2009-07-16 14:34:19] guillermog at tricuspide dot com
Still in the release, I really think lot's of people are having the
same
problem with their sctripts!!
I filled a bug report hours ago to later accidentally find that it was
a
very simple problem. Once I found the problem I looked for mysql_close
and version 5.3 to find this bug report.
Uff finnally after the whole day!!!
Regards,
Guillermo
[2009-07-14 01:50:03] sujoe_2006 at 163 dot com
my development evioronment is
windows xp sp2
apache 2.2
php 5.3.0
mysql 5.1.36
I write some code in test.php
then ,I Will be catched a error by apache 2.2,it is:
"...
0x006e2072 in httpd.exe: 0xC005:
Access violation when reading location 0x.
..."
but when check the mysql_close function like this for test.php
it will work no any error.
so ,i want to know its reason of the mysql_close(),please mail to me
Thanks!
[2009-07-07 14:47:28] xektrum at gmail dot com
Description:
--
I can confirm this, I'm having the same issue with php 5.3 and apache2
when calling mysql_close without a mysql_link as parameter.
Reproduce code:
--
Workaround/not crashing:
--
Exception :
--
Not handled Exception in 0x006e2072 in httpd.exe: 0xC005:
Access violation when reading location 0x.
Note : The Exception has been translated so it is not literal
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/48754
--
Edit this bug report at http://bugs.php.net/?id=48754&edit=1
#49461 [Com]: parse_ini_file: semicolon in section header
ID: 49461
Comment by: oc3ans at gmail dot com
Reported By: sebastian dot schleussner at angstrom dot uu dot se
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.3.0
New Comment:
According to accepted standards of ini files the semicolon is starting
a
comment that lasts till the end of the line, so IMHO this is not a bug,
if you want to include semicolons in the keys or sections you should
escape it with a backslash.
Previous Comments:
[2009-09-03 20:17:37] sebastian dot schleussner at angstrom dot uu dot
se
Description:
This is a follow-up to Bug #49443.
The character breaking parse_ini_file of PHP 5.3.0 with browscap.ini is
actually the comment character ";" inside section headers - not one of
the special characters.
Reproduce code:
---
;sample1.ini
; demonstration of what works in 5.2 and 5.3
[a(b){c}&~![^]
x=y
;sample2.ini
; demonstration of the problem
[a;b];c
x=y
Code:
-
Expected result:
As in PHP 5.2.10 -- the header's square brackets being interpreted as
quoting:
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
Array
(
[a;b] => Array
(
[x] => y
)
)
Actual result:
--
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
PHP Warning: syntax error, unexpected $end, expecting ']' in
sample2.ini on line 1
--
Edit this bug report at http://bugs.php.net/?id=49461&edit=1
#49341 [Com]: add SO_REUSEPORT support for socket_set_option()
ID: 49341
Comment by: netnghia at yahoo dot com
Reported By: jolan at gormsby dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: OpenBSD 4.6-current
PHP Version: 5.2.10
New Comment:
After I add define SO_REUSEPORT to ext/sockets/sockets.c
I configure, make, make install php-5.2.9 again, I have error:
Warning: socket_set_option(): unable to set socket option [92]:
Protocol not available in /usr/share/gds_ftps/gds_ftpd.php on line 985
I don't know what to do to fix. It seem SO_REUSEPORT still cannot use.
Any suggestion?
Previous Comments:
[2009-08-24 00:26:04] jolan at gormsby dot com
Description:
SO_REUSEPORT is needed to allow separate processes to bind to the same
port. Add the following to ext/sockets/sockets.c after SO_REUSEADDR:
#ifdef SO_REUSEPORT
REGISTER_LONG_CONSTANT("SO_REUSEPORT", SO_REUSEPORT, CONST_CS
| CONST_PERSISTENT);
#endif
I believe SO_REUSEPORT is not available under Windows, hence the ifdef.
--
Edit this bug report at http://bugs.php.net/?id=49341&edit=1
#29085 [Asn]: bad default include_path on Windows
ID: 29085
User updated by: christian at wenz dot org
Reported By: christian at wenz dot org
Status: Assigned
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 5.0.0RC3
Assigned To: pajoye
New Comment:
great to see that this bug/change request gets some lovin' after over
five years ;-) This should do the trick in win32/build/config.w32:
---SNIP---
107c107
< PHP_PREFIX = "C:\\php" + PHP_VERSION;
---
> PHP_PREFIX = "C:\\php";
---SNIP---
Not sure if this should go into 5.x -- of course I'd love to see it,
but we would probably change the current behavior, and some people might
actually have installed PHP into C:\php5 and expect the include_path to
contain that automatically.
Previous Comments:
[2009-09-08 23:50:05] paj...@php.net
Agreed. Let change it in trunk at least, or maybe in 5.3.2 as well.
[2009-09-07 23:43:37] php dot netsm at majorsite dot com
I, too, find this VERY confusing, and I can't seem to get around it.
Running Win2K Server (was to upgrade this year - market stopped
that...) and have had PHP running on 5.0.3 for awhile (in C:\Program
Files\PHP - the 'default' from the install).
Went to upgrade and found latest versions need Win2003 Server or
better, so I had to take 5.2.10, but I cannot get the .ini to read.
Install.txt file says to avoid \program files\ so I deleted that and
went for a 'clean' install to \php\
phpinfo() says I'm looking at loaded .ini from C:\PHP\php.ini I've
tried setting the php.ini include_path = ".;c:\php;c:\php\ext", yet
phpinfo() says include_path is .;C:\php5\pear
The comments on this page were from 2004 - and the 'fix' was that
"people want to run php4 and php5, though, how long has php4 been gone,
and this issue is still relevant 5 years on. this IS (IMHO) a BAD
thing and very confusing.
I look forward to some reply as I now have php running again, but none
of my databases run, none of my 'include' files work, etc.
And, please do not tell me to save my .ini file in some other location
- I've tried \winnt\system32, \winnt, c:\ and certainly c:\php - nothing
has worked. I am almost frustrated enough to try c:\php5 and even
c:\php5\pear, but I am trying to use the install instructions!
I think this php5 error is a bug and should be fixed - even in other
versions of php (for those of us that can't afford the upgrade).
[2005-02-15 01:08:11] tony2...@php.net
This is not a bug, but change request.
Reclassifying.
[2005-01-05 21:34:30] justin at telepop dot net
This setting just caused me some problems. Somehow my php.ini had a
bad path in its include_path setting. Rather than spit out an error, it
assumed that c:\php4\pear was my default include directory, and gave me
little information to figure out why. Once I fixed the path, my
declared settings took effect and everything worked fine, but it wasn't
a very intuitive leap to see why that include path was showing up.
[2004-08-06 08:54:57] christian at wenz dot org
sorry, here I completely disagree. Of course it _is_ possible to change
the include_path manually or within the script, however there is a
divergence between the installation section of the manual (where it says
"C:\php") and this built-in behavior of PHP ("C:\php5"). Also, I know of
only very few people who actually use both versions on one machine (only
few now of the possibility to store php.ini in the PHP directory and not
in the Windows directory; furthermore you have to use PHP as CGI).
This bug appears again and again; I am getting 2-3 reader mails about
this per month; and it is (IMO) just annoying. Therefore, one thing has
to change IMO: either the installation recommends installing PHP into
C:\php5, or the include_path is set to something that includes C:\php.
Of course, the latter is preferable. So I dare to reopen this one :)
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/29085
--
Edit this bug report at http://bugs.php.net/?id=29085&edit=1
#49461 [Opn]: parse_ini_file: semicolon in section header
ID: 49461
User updated by: sebastian dot schleussner at angstrom dot uu dot se
Reported By: sebastian dot schleussner at angstrom dot uu dot se
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.3.0
New Comment:
Okay, classification as "bug" may be debatable, and note that I have
made this a "Feature/Change Request".
At the very least, it is an undocumented and irritating change of
functionality.
Next, it is a change that breaks normal parsing of the widely used
browscaps.ini, which PHP's own get_browser still reads flawlessly.
Most importantly, semicolons ARE allowed inside quotes, and I think it
is very logical to interpret the square brackets of section titles as
quoting, too (as pre-5.3 PHP did). There is no legitimate use of a
semicolon *for starting a comment* before the closing square bracket, so
there is no reason to interpret it as such. If one wants to add a
comment on the title line, one can do so after the closing bracket.
As to accepted standards: On the one hand my experience is that there
is a lot of variation in the format of INI files, so a parser should be
reasonably lenient. On the other hand I have never seen backslash
escaping in INI files and I'm not at all sure it is part of any
"accepted standard" for them.
It only works partly anyway, and inconsistently.
Take this file:
;sample3.ini
[a\;b];c
x=y\;z
y="a;b"
z="a\;b"
and run print_r(parse_ini_file("sample3.ini", true));
You get (PHP 5.2.10 and 5.3.0):
Array
(
[a\;b] => Array
(
[x] => y\
[y] => a;b
[z] => a\;b
)
)
No bailout, but (a) the backslash remains inside title and quotes, (b)
the escaping does not work in values. No good, IMHO.
Variable z shows that titles and quoted strings are still considered
equally in terms of backslashes, and x demos that unquoted ;'s are
always filtered, but while the unescaped ; in y is allowed, it's not in
the title in 5.3 -- that's inconsistent and should be reverted.
I rest my case.
Previous Comments:
[2009-09-09 05:40:48] oc3ans at gmail dot com
According to accepted standards of ini files the semicolon is starting
a
comment that lasts till the end of the line, so IMHO this is not a bug,
if you want to include semicolons in the keys or sections you should
escape it with a backslash.
[2009-09-03 20:17:37] sebastian dot schleussner at angstrom dot uu dot
se
Description:
This is a follow-up to Bug #49443.
The character breaking parse_ini_file of PHP 5.3.0 with browscap.ini is
actually the comment character ";" inside section headers - not one of
the special characters.
Reproduce code:
---
;sample1.ini
; demonstration of what works in 5.2 and 5.3
[a(b){c}&~![^]
x=y
;sample2.ini
; demonstration of the problem
[a;b];c
x=y
Code:
-
Expected result:
As in PHP 5.2.10 -- the header's square brackets being interpreted as
quoting:
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
Array
(
[a;b] => Array
(
[x] => y
)
)
Actual result:
--
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
PHP Warning: syntax error, unexpected $end, expecting ']' in
sample2.ini on line 1
--
Edit this bug report at http://bugs.php.net/?id=49461&edit=1
#49461 [Opn]: parse_ini_file: semicolon in section header
ID: 49461
User updated by: sebastian dot schleussner at angstrom dot uu dot se
Reported By: sebastian dot schleussner at angstrom dot uu dot se
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.3.0
New Comment:
Just tried the second part of your suggestion, oc3ans. Here's another
inconsistency.
A *key* with an escaped semicolon is *ignored* in PHP 5.2.10.
But in PHP 5.3.0 it causes the parsing to quit silently - it does not
fail as with unescaped semicolons in sections, and returns the lines
before the "malformed" one, but does not read any further.
Previous Comments:
[2009-09-09 06:30:02] sebastian dot schleussner at angstrom dot uu dot
se
Okay, classification as "bug" may be debatable, and note that I have
made this a "Feature/Change Request".
At the very least, it is an undocumented and irritating change of
functionality.
Next, it is a change that breaks normal parsing of the widely used
browscaps.ini, which PHP's own get_browser still reads flawlessly.
Most importantly, semicolons ARE allowed inside quotes, and I think it
is very logical to interpret the square brackets of section titles as
quoting, too (as pre-5.3 PHP did). There is no legitimate use of a
semicolon *for starting a comment* before the closing square bracket, so
there is no reason to interpret it as such. If one wants to add a
comment on the title line, one can do so after the closing bracket.
As to accepted standards: On the one hand my experience is that there
is a lot of variation in the format of INI files, so a parser should be
reasonably lenient. On the other hand I have never seen backslash
escaping in INI files and I'm not at all sure it is part of any
"accepted standard" for them.
It only works partly anyway, and inconsistently.
Take this file:
;sample3.ini
[a\;b];c
x=y\;z
y="a;b"
z="a\;b"
and run print_r(parse_ini_file("sample3.ini", true));
You get (PHP 5.2.10 and 5.3.0):
Array
(
[a\;b] => Array
(
[x] => y\
[y] => a;b
[z] => a\;b
)
)
No bailout, but (a) the backslash remains inside title and quotes, (b)
the escaping does not work in values. No good, IMHO.
Variable z shows that titles and quoted strings are still considered
equally in terms of backslashes, and x demos that unquoted ;'s are
always filtered, but while the unescaped ; in y is allowed, it's not in
the title in 5.3 -- that's inconsistent and should be reverted.
I rest my case.
[2009-09-09 05:40:48] oc3ans at gmail dot com
According to accepted standards of ini files the semicolon is starting
a
comment that lasts till the end of the line, so IMHO this is not a bug,
if you want to include semicolons in the keys or sections you should
escape it with a backslash.
[2009-09-03 20:17:37] sebastian dot schleussner at angstrom dot uu dot
se
Description:
This is a follow-up to Bug #49443.
The character breaking parse_ini_file of PHP 5.3.0 with browscap.ini is
actually the comment character ";" inside section headers - not one of
the special characters.
Reproduce code:
---
;sample1.ini
; demonstration of what works in 5.2 and 5.3
[a(b){c}&~![^]
x=y
;sample2.ini
; demonstration of the problem
[a;b];c
x=y
Code:
-
Expected result:
As in PHP 5.2.10 -- the header's square brackets being interpreted as
quoting:
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
Array
(
[a;b] => Array
(
[x] => y
)
)
Actual result:
--
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
PHP Warning: syntax error, unexpected $end, expecting ']' in
sample2.ini on line 1
--
Edit this bug report at http://bugs.php.net/?id=49461&edit=1
