#26545 [Com]: Cannot extract() variables into class scope
ID: 26545
Comment by: james dot relyea at zifiniti dot com
Reported By: kmsluder at optonline dot net
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux 2.4.2
PHP Version: 4.3.4
New Comment:
Adding in ability to specifiy scope would be highly useful for Objects.
Previous Comments:
[2004-01-10 10:41:10] and...@php.net
What's the deal to use extract() to add dynamically member variables to
the object?
[2003-12-06 16:53:27] der...@php.net
It's still not a bug as extract() was never meant to do this. Making it
a feature-request.
[2003-12-06 16:20:21] kmsluder at optonline dot net
Note to anyone that says that the extra two lines aren't a big deal:
it's a lot more than two if you need to emulate some of the more
sophisticated (and rather useful) features of extract().
[2003-12-06 16:11:31] kmsluder at optonline dot net
Description:
extract() cannot be used inside an object member function to set object
var's. Using extract normally brings the variables into the scope of
the function (as expected), but there is no way to bring array key/value
pairs to object scope without a foreach statement.
It would be nice to specify what scope the variables should be created
in, or even create a different function specifically to set the member
variables of an object.
Reproduce code:
---
class MyClass
{
var $m1; // Imagine a class with fifty variables,
var $m2; // Not all of which must be set.
var $m3; // This is why you would want to use extract().
function Init($info)
{
extract($info, EXTR_OVERWRITE); // Doesn't work; extracted to
function scope
extract($info, EXTR_PREFIX_ALL, $this-); // Stupid idea; not
a valid variable name
foreach($info as $key = $value)
{
$this-$key = $value; // Works, but ugly
}
}
}
--
Edit this bug report at http://bugs.php.net/?id=26545edit=1
#47517 [Opn-Fbk]: php-cgi.exe missing UAC manifest
ID: 47517 Updated by: paj...@php.net Reported By: louis at steelbytes dot com -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Win32 PHP Version: 5.2.9 New Comment: Why do you need one? php can be used in any situations and inherits (or is set by) the UAC from the caller (in case of fcgi or another SAPI for example). Previous Comments: [2009-02-27 06:23:35] louis at steelbytes dot com reason: so that UAC won't virtualize file read/writes. [2009-02-27 03:51:48] louis at steelbytes dot com Description: php-cgi.exe (and I guess other php .exe's) should have a UAC manifest stating asInvoker Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=47517edit=1
#44578 [Com]: Strange Behavior of PHP using COM Object
ID: 44578
Comment by: hargael at gmail dot com
Reported By: hargael at gmail dot com
Status: Open
Bug Type: COM related
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
Is there a way I can help in order to make this bug evolve ?
I can provide any requested logs and can perform tests to help to solve
this problem because I really need this feature.
I'm not really keen on using an ASP page to make this single function.
Regards.
Previous Comments:
[2008-07-08 12:46:07] spijoel at gmail dot com
I have the same problem (Fatal error: Can't use method return value in
write context in ...), with PHP 5.2.6 , Apache 2.2.9 , and Windows 2003
Server.
I'm not able to do this:
$obj-Attribute('data1') = test;
This is also not working like this:
$obj-Attribute['data1'] = test;
and it's working in VBS so I know it should work here also.
[2008-03-31 12:39:49] hargael at gmail dot com
Description:
I've a problem with COM objects.
It's very similar to the bug #33734. In fact, I think that it is the
same problem but the bug is supposed to be fixed since 5.1.0. I use the
5.2.5 and have the same problem.
Excuse me for my clumsy english, I hope that my report will be
readable.
Reproduce code:
---
Here is the code :
?php
// Creation of the COM object $obj_persist
$obj_persist = new COM(PERSIST.PersistCtrl.1)or die(Error);
$obj_appli = $obj_persist-Applications-Add($path);
$obj_unite = $obj_appli-Units-Add(foo);
$obj_instance = $obj_unite-objects-add($nom_instance);
$sous_objet = $obj_instance-collection(Objects);
$propriete = $sous_objet-Item(alm);
echo Label Value : . $propriete-Value(Label,0); //Returns the
good Value
// Test 1
$propriete-Value(Label,0) = New Label;
// Fatal Error
//Test 2
$propriete-Value[Label,0] = New Label;
// Invalid number of parameters.
Expected result:
I've tried many ways of writing the $propriete-Value[Label,0]. With
(), [], mix of both. I cannot write on the value.
I though it was a read-only value but when I tried with VBa, it worked
perfectly. Here is the code.
Dim SsObjs as PrsCollObjects
Set SsObjs = MyInst.Collection(Objects)
Set MyObject = SsObjs.Item(Fault)
MyObject.Value(Label, 0) = Défaut pompe 1
Actual result:
--
Result of TEST 1 with () :
Fatal error: Can't use method return value in write context in
C:\wamp\www\Test COM\index.php on line 71
Result of TEST 2 with [] :
Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x8002000e] Nombre de param?tres non valide. ' in C:\wamp\www\Test
COM\index.php:69 Stack trace: #0 C:\wamp\www\Test COM\index.php(69):
unknown() #1 {main} thrown in C:\wamp\www\Test COM\index.php on line 69
Depending on the way I write with [], I also have an Unexpected ','
error.
--
Edit this bug report at http://bugs.php.net/?id=44578edit=1
#47519 [NEW]: array key access reports notice
From: markus dot staab at redaxo dot de Operating system: Vista Business PHP version: 5.2.9 PHP Bug Type: Arrays related Bug description: array key access reports notice Description: access a array key results in a undefined string offset notice. When swapping lines $params = $params['params']; $divider = $params['divider']; to $divider = $params['divider']; $params = $params['params']; no notice is reported.. PS: Appears in PHP4 and also PHP5.2.8 (5.2.9 not yet tested) Reproduce code: --- $params = array ( 'id' = 1, 'name' = 'Home', 'clang' = 0, 'params' = '', 'divider' = '', 'extension_point' = 'URL_REWRITE', 'subject' = '', ); $id = $params['id']; $name= $params['name']; $clang = $params['clang']; $params = $params['params']; $divider = $params['divider']; // line reports notice Expected result: no notices at all Actual result: -- Notice: Uninitialized string offset: 0 -- Edit bug report at http://bugs.php.net/?id=47519edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47519r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47519r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47519r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47519r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47519r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47519r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47519r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47519r=needscript Try newer version: http://bugs.php.net/fix.php?id=47519r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47519r=support Expected behavior: http://bugs.php.net/fix.php?id=47519r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47519r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47519r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47519r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47519r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47519r=dst IIS Stability: http://bugs.php.net/fix.php?id=47519r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47519r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47519r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47519r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47519r=mysqlcfg
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: danger at FreeBSD dot org Reported By: danger at FreeBSD dot org Status: Assigned Bug Type: Date/time related Operating System: FreeBSD PHP Version: 5.2.8 Assigned To: derick New Comment: verified to still leak with: r...@[temp /basejail/usr/ports/lang/php5]# php -v PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Previous Comments: [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2009-02-17 15:45:07] danger at FreeBSD dot org I did so yesterday as well... [2009-02-17 14:47:21] maarten at vivesta dot com Ok, I've sent you login details to a testmachine by e-mail. [2009-02-15 12:54:34] der...@php.net Please send me account details (by email), as I still can't reproduce this. 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/47285 -- Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47520 [NEW]: PHP segfaulted in preg_replace on processing long string
From: pahan at hubbitus dot spb dot su
Operating system: Linux
PHP version: 5.3.0beta1
PHP Bug Type: PCRE related
Bug description: PHP segfaulted in preg_replace on processing long string
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?(?:[^']|(?=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file named
test.php):
for (( i=100; i0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by length
of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (? ... ) to speedup and dissallow
recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 , http://bugs.php.net/bug.php?id=47376
, http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
?
$cont = ' . str_pad('', 5000, '-');-//1: Always segmantation fault
//$cont = ' . str_pad('', 4000, '-');//2: Never (Is I can see in 1000
iterations) segmantation fault
//$cont = ' . str_pad('', 4965, '-');//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = ' . str_pad('', 4967, '-');//4: Segfaulted 50/50%
$reg = #'((?(?:[^']|(?=\\\)')*))'#;
preg_replace($reg, '', $cont);
echo OK\n;
?
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=47520edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47520r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47520r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47520r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47520r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47520r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47520r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47520r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47520r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47520r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47520r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47520r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47520r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47520r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47520r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47520r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47520r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47520r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47520r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47520r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47520r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47520r=mysqlcfg
#47285 [Asn]: strtotime() still leaks memory
ID: 47285 Updated by: der...@php.net Reported By: danger at FreeBSD dot org Status: Assigned Bug Type: Date/time related Operating System: FreeBSD PHP Version: 5.2.8 Assigned To: derick New Comment: I am not forgetting about this, but at the moment just really occupied. Just as a quick question, this is the *stock* PHP without any ports patches, also, if you set the error level to also show e_Strict messages, do you see anything? Also, do you have the date.timezone setting made in PHP.ini? Previous Comments: [2009-02-27 10:41:02] danger at FreeBSD dot org verified to still leak with: r...@[temp /basejail/usr/ports/lang/php5]# php -v PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2009-02-17 15:45:07] danger at FreeBSD dot org I did so yesterday as well... [2009-02-17 14:47:21] maarten at vivesta dot com Ok, I've sent you login details to a testmachine by e-mail. 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/47285 -- Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: danger at FreeBSD dot org Reported By: danger at FreeBSD dot org Status: Assigned Bug Type: Date/time related Operating System: FreeBSD PHP Version: 5.2.8 Assigned To: derick New Comment: Hey there, I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything else) with ./configure make. When I run my test script as this: r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php /root/test.php No modified php.ini is being used, no additional extensions are being loaded. I can still verify that it leaks. Previous Comments: [2009-02-27 11:44:35] der...@php.net I am not forgetting about this, but at the moment just really occupied. Just as a quick question, this is the *stock* PHP without any ports patches, also, if you set the error level to also show e_Strict messages, do you see anything? Also, do you have the date.timezone setting made in PHP.ini? [2009-02-27 10:41:02] danger at FreeBSD dot org verified to still leak with: r...@[temp /basejail/usr/ports/lang/php5]# php -v PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2009-02-17 15:45:07] danger at FreeBSD dot org I did so yesterday as well... 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/47285 -- Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: danger at FreeBSD dot org Reported By: danger at FreeBSD dot org Status: Assigned Bug Type: Date/time related Operating System: FreeBSD PHP Version: 5.2.8 Assigned To: derick New Comment: I tried to run my script with php -d error_reporting=E_STRICT test.php and been receiving this error until I stopped the script: Strict Standards: strtotime(): It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line 10 Previous Comments: [2009-02-27 13:25:37] danger at FreeBSD dot org Hey there, I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything else) with ./configure make. When I run my test script as this: r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php /root/test.php No modified php.ini is being used, no additional extensions are being loaded. I can still verify that it leaks. [2009-02-27 11:44:35] der...@php.net I am not forgetting about this, but at the moment just really occupied. Just as a quick question, this is the *stock* PHP without any ports patches, also, if you set the error level to also show e_Strict messages, do you see anything? Also, do you have the date.timezone setting made in PHP.ini? [2009-02-27 10:41:02] danger at FreeBSD dot org verified to still leak with: r...@[temp /basejail/usr/ports/lang/php5]# php -v PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies 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/47285 -- Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47467 [Asn-Fbk]: The crc32b polynomial result has a wrong endianess
ID: 47467
Updated by: paj...@php.net
Reported By: php at twinmail dot de
-Status: Assigned
+Status: Feedback
Bug Type: hash related
-Operating System: Windows XP SP2
+Operating System: *
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
Are you sure you are using the same PHP version on all systems (try
5.2.8 on linux)?
I can't reproduce the problem on any of my tests hosts. The only
difference is with php version prior to 5.2.6, but that's due to the bug
#45028 which is now fixed.
Previous Comments:
[2009-02-20 22:21:03] paj...@php.net
Windows has no specific endianess but the processor. However I can
reproduce on windows (vc6 and vc9). Weird, needs more analyze.
[2009-02-20 21:24:26] php at twinmail dot de
Description:
The polynomial result of the crc32b hash function has since 5.2.8 a
wrong byte endianess on Windows. This also affects the CVS snapshot. I
cannot reproduce this error on any linux (debian / debian / gentoo /
opensuse) box I have, so I think this bug only affects Windows
versions.
I tested different versions of PHP on my Windows system:
PHP 5.2.9RC4-dev (cli) (built: Feb 20 2009 15:57:39): affected
PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23): affected
PHP 5.2.6 (cli) (built: May 2 2008 18:02:07): NOT affected
The bug #45028 is maybe related to this one.
Reproduce code:
---
print hash('crc32b', 'Lorem Ipsum');
Expected result:
5dd48a35
Actual result:
--
358ad45d
--
Edit this bug report at http://bugs.php.net/?id=47467edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: maarten at vivesta dot com Reported By: danger at FreeBSD dot org Status: Assigned Bug Type: Date/time related Operating System: FreeBSD PHP Version: 5.2.8 Assigned To: derick New Comment: Same here. I've added a date_default_timezone_set() before using strtotime() and it removed the error but not the leak. Previous Comments: [2009-02-27 13:53:29] danger at FreeBSD dot org I tried to run my script with php -d error_reporting=E_STRICT test.php and been receiving this error until I stopped the script: Strict Standards: strtotime(): It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line 10 [2009-02-27 13:25:37] danger at FreeBSD dot org Hey there, I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything else) with ./configure make. When I run my test script as this: r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php /root/test.php No modified php.ini is being used, no additional extensions are being loaded. I can still verify that it leaks. [2009-02-27 11:44:35] der...@php.net I am not forgetting about this, but at the moment just really occupied. Just as a quick question, this is the *stock* PHP without any ports patches, also, if you set the error level to also show e_Strict messages, do you see anything? Also, do you have the date.timezone setting made in PHP.ini? [2009-02-27 10:41:02] danger at FreeBSD dot org verified to still leak with: r...@[temp /basejail/usr/ports/lang/php5]# php -v PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago 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/47285 -- Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47519 [Opn-Bgs]: array key access reports notice
ID: 47519 Updated by: ka...@php.net Reported By: markus dot staab at redaxo dot de -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Vista Business PHP Version: 5.2.9 New Comment: Its because your overridding the $params array by assigning a new value, and since the [] operator also can be used for string offsets then that notice is produced, not a bug. Previous Comments: [2009-02-27 10:37:13] markus dot staab at redaxo dot de Description: access a array key results in a undefined string offset notice. When swapping lines $params = $params['params']; $divider = $params['divider']; to $divider = $params['divider']; $params = $params['params']; no notice is reported.. PS: Appears in PHP4 and also PHP5.2.8 (5.2.9 not yet tested) Reproduce code: --- $params = array ( 'id' = 1, 'name' = 'Home', 'clang' = 0, 'params' = '', 'divider' = '', 'extension_point' = 'URL_REWRITE', 'subject' = '', ); $id = $params['id']; $name= $params['name']; $clang = $params['clang']; $params = $params['params']; $divider = $params['divider']; // line reports notice Expected result: no notices at all Actual result: -- Notice: Uninitialized string offset: 0 -- Edit this bug report at http://bugs.php.net/?id=47519edit=1
#47521 [NEW]: In jquery ajax. When I send variables thru 'get' it works but not on 'post'
From: mandar dot dhotre at yahoo dot co dot in Operating system: Windows PHP version: 5.2CVS-2009-02-27 (snap) PHP Bug Type: Unknown/Other Function Bug description: In jquery ajax. When I send variables thru 'get' it works but not on 'post' Description: I am using jquery ajax. When I send the variables thru get method it works but wen I send them thru POST and try to catch them using REQUEST or POST it doesnt work. I need to use POST only as m using it for username-password. -- Edit bug report at http://bugs.php.net/?id=47521edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47521r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47521r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47521r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47521r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47521r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47521r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47521r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47521r=needscript Try newer version: http://bugs.php.net/fix.php?id=47521r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47521r=support Expected behavior: http://bugs.php.net/fix.php?id=47521r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47521r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47521r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47521r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47521r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47521r=dst IIS Stability: http://bugs.php.net/fix.php?id=47521r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47521r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47521r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47521r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47521r=mysqlcfg
#47522 [NEW]: __toString() segfault
From: ms419 at freezone dot co dot uk Operating system: Debian PHP version: 5.2CVS-2009-02-27 (snap) PHP Bug Type: Reproducible crash Bug description: __toString() segfault Description: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/core I am experiencing a reproducible segfault. I experience it with PHP 5.2.4 and 5.2.6. The segfault occurs at this expression: strlen($repository) where $repository is an object with a __toString() method. By substituting this expression, the segfault does not occur: strlen($repository-__toString()) To try to debug this segfault, I compiled a recent 5.2 snapshot with --enable-debug. It produced the above linked core file, which I opened with gdb to print a backtrace: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/screenlog I am not sure what should be my next steps to help fix this segfault? -- Edit bug report at http://bugs.php.net/?id=47522edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47522r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47522r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47522r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47522r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47522r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47522r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47522r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47522r=needscript Try newer version: http://bugs.php.net/fix.php?id=47522r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47522r=support Expected behavior: http://bugs.php.net/fix.php?id=47522r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47522r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47522r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47522r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47522r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47522r=dst IIS Stability: http://bugs.php.net/fix.php?id=47522r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47522r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47522r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47522r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47522r=mysqlcfg
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994 Comment by: alex at alexi dot ch Reported By: dbarrett at vistaprint dot com Status: Assigned Bug Type: Program Execution Operating System: win32 only - 2003 Server, 64-bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: Hi all, I can fully confirm the above behaviour on the Windows platform. We are using Apache FOP to create PDF-Files out of PHP, so we are invoking exec() to start the command line FOP processor. With several versions of PHP 5.2.x (5.2.4, 5.2.6, 5.2.8), this problem occurs soon as more than one user is invoking the exec(). Luckily we could not reproduce this behaviour using PHP 5.1.x, so downgrading to a 5.1.x version might also be an option for you. Regards alex Previous Comments: [2009-01-16 17:17:44] schreiber at cs-itc dot de Same problems on w2k3 server x64 SP2 with apache 2.2.8 + 2.2.11 and php 5.2.0 up to 5.2.8 - using exec() the shellproc cmd.exe hangs and httpd is blocked for further ops, can just be cured by restart of apache services. Workaround with COM object helps, but thats no lucky solution... [2009-01-13 18:44:15] irdev at rogers dot com I have been experiencing this issue as well. The server is Windows 2003 with all patches up to date running IIS. PHP version is 5.2.5. I am running a commandline process using exec(). I have also tried passthru and shell_exec with the same results. Problem is intermittent and can not be replicated on demand. The processes themselves can not be killed until the IIS worker process is killed first although they do complete all the work they are supposed to. The commands do not die on script timeout. [2008-12-02 14:34:25] brem at martinbreton dot com If that's any help, I'm using a COM object as a workaround for this bug, and while it makes this bug appear less frequently, it still happens, randomly, from time to time. Here's what i did as a workaround using the exec() function call: $WshShell = new COM(WScript.Shell); $OutputFile = C:\\Temp\\output.txt; $Command = cmd /C MyApp.exe $OutputFile; $WshShell-Run( $Command, 0, true ); file_get_contents( $OutputFile ) ); unlink( $OutputFile ); [2008-11-18 08:46:34] bernd dot ebert at gmx dot net Same Problem here with an commandline-script calling other php-commandline-scripts. It seems to happen more frequently if you have a lot of exec-calls. [2008-08-19 02:58:37] jkflash at gmail dot com Sorry, I take that last comment back, it still hangs annoyingly intermittently with shell_exec as well. It's a killer :( 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/44994 -- Edit this bug report at http://bugs.php.net/?id=44994edit=1
#47522 [Opn-Fbk]: __toString() segfault
ID: 47522 Updated by: fel...@php.net Reported By: ms419 at freezone dot co dot uk -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Debian PHP Version: 5.2CVS-2009-02-27 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2009-02-27 18:52:36] ms419 at freezone dot co dot uk Description: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/core I am experiencing a reproducible segfault. I experience it with PHP 5.2.4 and 5.2.6. The segfault occurs at this expression: strlen($repository) where $repository is an object with a __toString() method. By substituting this expression, the segfault does not occur: strlen($repository-__toString()) To try to debug this segfault, I compiled a recent 5.2 snapshot with --enable-debug. It produced the above linked core file, which I opened with gdb to print a backtrace: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/screenlog I am not sure what should be my next steps to help fix this segfault? -- Edit this bug report at http://bugs.php.net/?id=47522edit=1
#47520 [Opn-Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520
Updated by: fel...@php.net
Reported By: pahan at hubbitus dot spb dot su
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
Please, check the previous reports about this issue:
http://bugs.php.net/search.php?search_for=boolean=1limit=10order_by=iddirection=DESCcmd=displaystatus=Bogusbug_type%5B%5D=PCRE+relatedphp_os=phpver=assign=author_email=bug_age=0
http://docs.php.net/manual/en/pcre.configuration.php
Previous Comments:
[2009-02-27 11:13:58] pahan at hubbitus dot spb dot su
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?(?:[^']|(?=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file
named test.php):
for (( i=100; i0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by
length of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (? ... ) to speedup and
dissallow recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 ,
http://bugs.php.net/bug.php?id=47376 ,
http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
?
$cont = ' . str_pad('', 5000, '-');-//1: Always segmantation
fault
//$cont = ' . str_pad('', 4000, '-');//2: Never (Is I can see in
1000 iterations) segmantation fault
//$cont = ' . str_pad('', 4965, '-');//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = ' . str_pad('', 4967, '-');//4: Segfaulted 50/50%
$reg = #'((?(?:[^']|(?=\\\)')*))'#;
preg_replace($reg, '', $cont);
echo OK\n;
?
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47520edit=1
#47520 [Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
I'm thrice check the previous reports about this issue. And what? All
closed as bogus, but segmentatoin fault still here! Where
solution/fix??? Even common workaraund of problem is absent.
Why it is bogus but not bug???
And also, please again read note: I use Once-only subpattern, so,
this should prevent recursion as I can understand. Or not?
Previous Comments:
[2009-02-27 19:37:00] fel...@php.net
Please, check the previous reports about this issue:
http://bugs.php.net/search.php?search_for=boolean=1limit=10order_by=iddirection=DESCcmd=displaystatus=Bogusbug_type%5B%5D=PCRE+relatedphp_os=phpver=assign=author_email=bug_age=0
http://docs.php.net/manual/en/pcre.configuration.php
[2009-02-27 11:13:58] pahan at hubbitus dot spb dot su
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?(?:[^']|(?=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file
named test.php):
for (( i=100; i0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by
length of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (? ... ) to speedup and
dissallow recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 ,
http://bugs.php.net/bug.php?id=47376 ,
http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
?
$cont = ' . str_pad('', 5000, '-');-//1: Always segmantation
fault
//$cont = ' . str_pad('', 4000, '-');//2: Never (Is I can see in
1000 iterations) segmantation fault
//$cont = ' . str_pad('', 4965, '-');//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = ' . str_pad('', 4967, '-');//4: Segfaulted 50/50%
$reg = #'((?(?:[^']|(?=\\\)')*))'#;
preg_replace($reg, '', $cont);
echo OK\n;
?
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47520edit=1
#46025 [Com]: zend_bailout can deadlock APC
ID: 46025
Comment by: pierre at archlinux dot de
Reported By: askalski at gmail dot com
Status: Suspended
Bug Type: Reproducible crash
Operating System: redhat
PHP Version: 5.2.6
New Comment:
This problem is still reproducable with version 5.2.9. The cgi version
is affected, too (as expected).
Previous Comments:
[2009-02-15 00:01:20] dan at archlinux dot org
Any progress here? This is definitely reproducible and we have seen it
on archlinux.org about once every 3 or 4 days- it kind of stinks. Is
there any current workaround besides increasing the timeout value and
hoping for the best?
Running:
Apache 2.2.11
PHP 5.2.8
APC 3.0.19
[2008-09-09 00:46:09] scott...@php.net
This is essentially what http://wiki.php.net/rfc/zendsignals is for, it
was considered for PHP 5.3 but has been deferred for the moment.
[2008-09-08 23:56:04] askalski at gmail dot com
Reproduced with latest checkouts from both the PHP_5_2 and PHP_5_3
tags.
X-Powered-By: PHP/5.2.7-dev
X-Powered-By: PHP/5.3.0alpha3-dev
[2008-09-08 21:16:43] j...@php.net
Can you reproduce this with latest CVS checkout of PHP_5_2 (and
preferrably PHP_5_3) ??
[2008-09-08 20:50:12] askalski at gmail dot com
To assist with implementing a fix:
I wrote up a local fix that uses two executor globals:
/* HANDLE_BLOCK_INTERRUPTIONS nesting depth */
zend_uint blocking_interruptions;
/* true if a bailout was deferred while interruptions were blocked
*/
zend_bool deferred_bailout;
In my testing, I quickly realized that APC in conjunction with Zend was
making nested calls to HANDLE_BLOCK_INTERRUPTIONS(), so to keep from
unblocking prematurely, it was necessary to track nesting depth.
Example from my debugging:
Block 0 /tmp/APC-3.0.19/php_apc.c:559
Block 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1876
Unblock 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1913
Unblock 0 /tmp/APC-3.0.19/php_apc.c:592
My updated macros:
#define HANDLE_BLOCK_INTERRUPTIONS()if
(!EG(blocking_interruptions)++) { if (zend_block_interruptions) {
zend_block_interruptions(); } }
#define HANDLE_UNBLOCK_INTERRUPTIONS() if
(EG(blocking_interruptions) !--EG(blocking_interruptions)) { if
(zend_unblock_interruptions) { zend_unblock_interruptions(); } if
(EG(deferred_bailout)) { zend_bailout(); } }
And my mod to _zend_bailout:
if (EG(blocking_interruptions))
{
EG(deferred_bailout) = 1;
return;
}
EG(deferred_bailout) = 0;
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/46025
--
Edit this bug report at http://bugs.php.net/?id=46025edit=1
#47467 [Com]: The crc32b polynomial result has a wrong endianess
ID: 47467
Comment by: php at twinmail dot de
Reported By: php at twinmail dot de
Status: Feedback
Bug Type: hash related
Operating System: *
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
You are right: I tested this issue against PHP versions on linux which
were below 5.2.8 and therefore affected by #45028. Before posting a new
bug I also checked against some online calculators of crc32b, but they
were also affected by #45028. So I thought 5dd48a35 is the correct
result, but it isn't! 358ad45d is indeed the correct result, so PHP
5.2.8 is correctly calculating crc32b.
This means everything is fine, except that I am an idiot! ;-) Sorry for
reporting this bug.
Previous Comments:
[2009-02-27 14:33:35] paj...@php.net
Are you sure you are using the same PHP version on all systems (try
5.2.8 on linux)?
I can't reproduce the problem on any of my tests hosts. The only
difference is with php version prior to 5.2.6, but that's due to the bug
#45028 which is now fixed.
[2009-02-20 22:21:03] paj...@php.net
Windows has no specific endianess but the processor. However I can
reproduce on windows (vc6 and vc9). Weird, needs more analyze.
[2009-02-20 21:24:26] php at twinmail dot de
Description:
The polynomial result of the crc32b hash function has since 5.2.8 a
wrong byte endianess on Windows. This also affects the CVS snapshot. I
cannot reproduce this error on any linux (debian / debian / gentoo /
opensuse) box I have, so I think this bug only affects Windows
versions.
I tested different versions of PHP on my Windows system:
PHP 5.2.9RC4-dev (cli) (built: Feb 20 2009 15:57:39): affected
PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23): affected
PHP 5.2.6 (cli) (built: May 2 2008 18:02:07): NOT affected
The bug #45028 is maybe related to this one.
Reproduce code:
---
print hash('crc32b', 'Lorem Ipsum');
Expected result:
5dd48a35
Actual result:
--
358ad45d
--
Edit this bug report at http://bugs.php.net/?id=47467edit=1
#47467 [Fbk-Bgs]: The crc32b polynomial result has a wrong endianess
ID: 47467
Updated by: paj...@php.net
Reported By: php at twinmail dot de
-Status: Feedback
+Status: Bogus
Bug Type: hash related
Operating System: *
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
Not a bug bogus.
Previous Comments:
[2009-02-27 20:35:50] php at twinmail dot de
You are right: I tested this issue against PHP versions on linux which
were below 5.2.8 and therefore affected by #45028. Before posting a new
bug I also checked against some online calculators of crc32b, but they
were also affected by #45028. So I thought 5dd48a35 is the correct
result, but it isn't! 358ad45d is indeed the correct result, so PHP
5.2.8 is correctly calculating crc32b.
This means everything is fine, except that I am an idiot! ;-) Sorry for
reporting this bug.
[2009-02-27 14:33:35] paj...@php.net
Are you sure you are using the same PHP version on all systems (try
5.2.8 on linux)?
I can't reproduce the problem on any of my tests hosts. The only
difference is with php version prior to 5.2.6, but that's due to the bug
#45028 which is now fixed.
[2009-02-20 22:21:03] paj...@php.net
Windows has no specific endianess but the processor. However I can
reproduce on windows (vc6 and vc9). Weird, needs more analyze.
[2009-02-20 21:24:26] php at twinmail dot de
Description:
The polynomial result of the crc32b hash function has since 5.2.8 a
wrong byte endianess on Windows. This also affects the CVS snapshot. I
cannot reproduce this error on any linux (debian / debian / gentoo /
opensuse) box I have, so I think this bug only affects Windows
versions.
I tested different versions of PHP on my Windows system:
PHP 5.2.9RC4-dev (cli) (built: Feb 20 2009 15:57:39): affected
PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23): affected
PHP 5.2.6 (cli) (built: May 2 2008 18:02:07): NOT affected
The bug #45028 is maybe related to this one.
Reproduce code:
---
print hash('crc32b', 'Lorem Ipsum');
Expected result:
5dd48a35
Actual result:
--
358ad45d
--
Edit this bug report at http://bugs.php.net/?id=47467edit=1
#47524 [NEW]: register_func_function()
From: shaunspiller at gmail dot com Operating system: Irrelevant PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: register_func_function() Description: Hi developers! I have a little feature suggestion for you... I've been developing a large proxy server-ish thingy using standalone PHP, with a basic kernel loop that handles deferred procedure calls and timers, and uses stream_select to handle incoming traffic for the network connections and dispatch them to their watcher objects. (It's co-operative multitasking!) The problem is the server is very, very complicated and difficult to debug. Functions nest very deeply. So I added a function called func_log, which calls PHP's very useful debug_backtrace() and uses it to fill a log file with a list of every single function call everywhere and (a cut-down listing of) their parameters. The log file soon becomes gigantic, but it's a phenomenally helpful and wonderful way to debug problems and get an overview of the code. I can review the entire file to find out exactly what goes wrong, and it helped locate a tricky couple of objects that were spuriously crashing PHP by recursively calling each other's Close functions(). (Running out of stack space is difficult to detect otherwise, since PHP logs no error before crashing.) So what's my suggestion? Well the problem with this type of debugging is the need to manually insert the call to the debugging/logging function at the start of every custom function (which I've done). It's an awkward hacky sort of solution, and the function is still called even when debugging/logging isn't wanted, so it always hurts performance. I thought about using declare(ticks) and register_tick_function() instead, but that can't be tuned to just function calls, so it would have to be called far too many times. So wouldn't it be wonderful to have some way to register a function to fire on every function call? E.g.,: bool register_func_function( callback function, [, int flags] ) flags would determine whether it should fire for just user functions, just built-in/extension functions, or both. Obviously it would have to disable as the callback is entered, and re-enable once it exits. Perhaps not the best name for it, but anyway, this would be useful for anyone and everyone trying to debug complex scripts. I'm not familiar with PHP's internals, but having a simple boolean to check if register_func_function is enabled shouldn't hurt performance at all really, right? That's my suggestion. Thanks very much for reading. Apologies if this has already been suggested, but I couldn't find it. -- Edit bug report at http://bugs.php.net/?id=47524edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47524r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47524r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47524r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47524r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47524r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47524r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47524r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47524r=needscript Try newer version: http://bugs.php.net/fix.php?id=47524r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47524r=support Expected behavior: http://bugs.php.net/fix.php?id=47524r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47524r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47524r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47524r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47524r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47524r=dst IIS Stability: http://bugs.php.net/fix.php?id=47524r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47524r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47524r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47524r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47524r=mysqlcfg
#47513 [Com]: when using date, H shows 01 instead of 00
ID: 47513
Comment by: shaunspiller at gmail dot com
Reported By: usrhlp at yahoo dot com
Status: Open
Bug Type: Date/time related
Operating System: Debian
PHP Version: 5.2.8
New Comment:
It's the time zone on your machine. The number 5 refers to the time
January 1 1970 @ 00:00:05 UTC, which date() will format as something
different if you're in CET, etc.
Use the format codes 'O' or 'P' to show the timezone offset.
If you want it always fixed at UTC, use gmdate() instead of date().
Or use date_default_timezone_set first. E.g.,
if (version_compare(PHP_VERSION, '5.1.0', '=')) {
date_default_timezone_set('UTC');
}
Previous Comments:
[2009-02-26 23:07:57] usrhlp at yahoo dot com
I just tried it on another server I have with php 5.2.6 and i get this
result
18:00.01
18:00.10
18:01.40
18:16.40
20:46.40
21:46.40
07:46.40
12:46.40
That has totally thrown me off.
[2009-02-26 22:59:30] usrhlp at yahoo dot com
Description:
I am probably doing something wrong but I cannot for the life of me
figure out what it is.
I am trying to convert a small number to 24 hour time format. For
example I'm parsing the number 5 through the date function and I am
receiving the answer
01:00.05
I checked the PHP documentation and it shows as this for date()
H 24-hour format of an hour with leading zeros00 through 23
According to the documentation 00 is a possible output of the H
formatting within date and should be what is coming out.
Reproduce code:
---
echo(date(H:i.s ,1));
echo(date(H:i.s ,10));
echo(date(H:i.s ,100));
echo(date(H:i.s ,1000));
echo(date(H:i.s ,1));
echo(date(H:i.s ,10));
echo(date(H:i.s ,100));
echo(date(H:i.s ,1000));
Expected result:
time: 00:00.01
time: 00:00.10
time: 00:01.40
time: 00:16.40
time: 03:46.40
time: 04:46.40
time: 14:46.40
time: 18:46.40
Actual result:
--
time: 01:00.01
time: 01:00.10
time: 01:01.40
time: 01:16.40
time: 03:46.40
time: 04:46.40
time: 14:46.40
time: 18:46.40
--
Edit this bug report at http://bugs.php.net/?id=47513edit=1
#42718 [Com]: FILTER_UNSAFE_RAW not applied when configured as default filter, even with flags
ID: 42718 Comment by: sultant08 at gmail dot com Reported By: arnaud dot lb at gmail dot com Status: Assigned Bug Type: Filter related Operating System: * PHP Version: 5CVS-2008-11-01 Assigned To: pajoye New Comment: ÇáÑÌÇÁ ÊÛíÑ ÇááÛÉ Çáí ÇáÚÑÈíÉ áåÐÇ ÇáÇÕÏÇÑ Previous Comments: [2009-01-09 18:37:04] tarmuli at hotmail dot com Thaks!baybay [2008-12-06 19:20:34] paj...@php.net Yes, revert was the best option for now. I will dig into it on Monday and re read the discussions about that (there was some discussions about this whole thing when we added filter to core). [2008-12-06 19:17:09] lbarn...@php.net That's wrong This is exactly what you said one year ago, just before it was demonstrated that FILTER_UNSAFE_RAW actually does something (according to documentation, code, and examples), and the bug has been assigned to you. That said, I'm not rejecting the fault on anyone, and the important is to revert, which is done. [2008-12-06 18:25:20] paj...@php.net ooch. I did not catch in this bug before, but there is a major misunderstanding in the first comment. The unsafe_raw filter does nothing by default, but it can optionally strip or encode special characters, and it is the only filter which is able to do that without doing any other filtering. That's wrong. UNSAFE_RAW, the key word here is RAW. It means that the data is returned unfiltered, without flag, nothing, nada. If this behavior has been changed then please revert it. I did not check if it is present in 5.2.7 (it seems to be, as said in this report or another), that may require a quick fix release (Ilia?). [2008-12-06 17:52:37] lbarn...@php.net All my apologizes for this broken fix. A quick workaround for 5.2.7 users is to add the following in the php.ini: filter.default_flags=0 Scott has reverted this and this bug is not present in CVS. 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/42718 -- Edit this bug report at http://bugs.php.net/?id=42718edit=1
#47243 [Asn]: oci_fetch_assoc() causes Apache 2.2.11 crashed and restarted (SQL CURSOR)
ID: 47243
Updated by: s...@php.net
Reported By: pcdinh at gmail dot com
Status: Assigned
Bug Type: OCI8 related
Operating System: Windows XP SP3
PHP Version: 5.3.0beta1
Assigned To: sixd
New Comment:
Fix is being reviewed prior to testing.
Previous Comments:
[2009-02-03 02:16:21] s...@php.net
Reproduces on Windows. Also crashes with --enable-maintainer-zts mode
on Linux
[2009-01-30 04:47:03] kureikain at gmail dot com
I don't think that is a bug!I have ever had same problem(MySQL)!Because
i used wrong version of libmysql.dll!I copied frm XAMPP to System32!
when i install PHP from zip package,i forget to overwrite libmysql.dll
in system32!Apache keep crashing whenever PHP execs query
[2009-01-29 19:19:15] pcdinh at gmail dot com
Description:
I wrote code to retrieve data that was returned from a query with
Oracle cursor. However oci_fetch_assoc() causes Apache 2.2.11 being
crashed and restarted. I am not sure if it is a Oracle client native
library or OCI8 issue.
Reproduce code:
---
?php
$conn = oci_connect(hr, hr, 'xe');
$sql = SELECT department_id, department_name, CURSOR(SELECT
COUNT(employee_id) num_empl
FROM employees e
WHERE
e.department_id = d.department_id) AS empl_count
FROM departments d;
$stmt = oci_parse($conn, $sql);
oci_execute($stmt);
while ($data = oci_fetch_assoc($stmt))
{
}
oci_free_statement($stmt);
oci_close($conn);
?
Expected result:
Those code is a slightly modified version taken from PHP Manual
http://vn2.php.net/oci_new_cursor
It should be executed without any crash and data can be retrieved
normally (as guided by PHP Manual)
Actual result:
--
Apache crashes and restarts
Type of Analysis Performed Crash Analysis
Machine Name HOME-4F44218659
Operating System Windows XP Service Pack 3
Number Of Processors 2
Process ID 2200
Process Image C:\server\Apache2.2\bin\httpd.exe
System Up-Time 10:12:12
Process Up-Time 00:01:07
Thread 169 - System ID 2128
Entry point msvcrt!endthreadex+3a
Create time 1/30/2009 1:57:53 AM
Time spent in user mode 0 Days 0:0:0.15
Time spent in kernel mode 0 Days 0:0:0.93
Function Arg 1 Arg 2 Arg 3 Source
OraClient10!kpufhndl0+33 4e5f544e 0002
OraClient10!kpufhndl+10 4e5f544e 0002 049ff9e8
OraClient10!OCIHandleFree+1a 4e5f544e 0002 0084eef0
oci!OCIHandleFree+1d 4e5f544e 0002 01b8a9d8
php_oci8!php_oci_statement_free+121 05ecf448 01b8a9d8
0083aa23
php_oci8!php_oci_statement_list_dtor+11 05ed09b8 01b8a9d8
01be5278
php5ts!list_entry_destructor+43 05ed09b8 01b8a9d8 05ed0988
php5ts!zend_hash_apply_deleter+97 01be5278 05ed0988
01b8a9d8
php5ts!zend_hash_apply_with_argument+5a 01be5278 01976a90
0022
php_oci8!zm_deactivate_oci+8a 0001 0029 01b8a9d8
php5ts!module_registry_cleanup+1c 00fd4ec8 01b8a9d8
01b8a9d8
php5ts!zend_hash_apply+40 00cd7340 007882c0 01b8a9d8
php5ts!zend_deactivate_modules+62 049fffa4
56433230
php5ts!zend_deactivate_modules+48 01b82a01
05ecc7c0
php5ts!php_end_ob_buffers+26 01b8a9d8 0073a040 01b8a9d8
php5ts!php_request_shutdown+247 00622fb6 01b82a18
php5apache2_2!php_apache_request_dtor+8 01b82a18 01b8a9d8
0005
php5apache2_2!php_handler+646 01b82a18 0073a040 01b82a18
libhttpd!ap_run_handler+21 01b82a18 01b82a18 01b82a18
libhttpd!ap_invoke_handler+ae 01b7d9c0 049fff38
libhttpd!ap_die+29e 01b82a18 007447a8
libhttpd!ap_get_request_note+1c9c 01b7d9c0 01b7d9c0
01b7d9c0
libhttpd!ap_run_process_connection+21 01b7d9c0 007121e8
049fff80
libhttpd!ap_process_connection+33 01b7d9c0 01b76990
00e4
libhttpd!ap_regkey_value_remove+c7c 01b7d9b8 00e4
00e8
msvcrt!endthreadex+a9 01b73958 00e4 00e8
kernel32!GetModuleFileNameA+1b4 77c3a341 01b73958
ORACLIENT10!KPUFHNDL0+33WARNING - DebugDiag was not able to locate
debug symbols for OraClient10.Dll, so the information below may be
incomplete.
In
httpd__PID__2200__Date__01_30_2009__Time_01_59_00AM__328__Second_Chance_Exception_C005.dmp
the assembly instruction at OraClient10!kpufhndl0+33 in
C:\oraclexe\app\oracle\product\10.2.0\server\BIN\OraClient10.Dll from
#47520 [Bgs-Fbk]: PHP segfaulted in preg_replace on processing long string
ID: 47520
Updated by: fel...@php.net
Reported By: pahan at hubbitus dot spb dot su
-Status: Bogus
+Status: Feedback
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
I cannot download the coredump file: You don't have permission to
access /_temp/php-pcre-bug/2/core.10135 on this server.
Can you give us a backtrace?
Previous Comments:
[2009-02-27 20:06:13] pahan at hubbitus dot spb dot su
I'm thrice check the previous reports about this issue. And what? All
closed as bogus, but segmentatoin fault still here! Where
solution/fix??? Even common workaraund of problem is absent.
Why it is bogus but not bug???
And also, please again read note: I use Once-only subpattern, so,
this should prevent recursion as I can understand. Or not?
[2009-02-27 19:37:00] fel...@php.net
Please, check the previous reports about this issue:
http://bugs.php.net/search.php?search_for=boolean=1limit=10order_by=iddirection=DESCcmd=displaystatus=Bogusbug_type%5B%5D=PCRE+relatedphp_os=phpver=assign=author_email=bug_age=0
http://docs.php.net/manual/en/pcre.configuration.php
[2009-02-27 11:13:58] pahan at hubbitus dot spb dot su
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?(?:[^']|(?=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file
named test.php):
for (( i=100; i0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by
length of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (? ... ) to speedup and
dissallow recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 ,
http://bugs.php.net/bug.php?id=47376 ,
http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
?
$cont = ' . str_pad('', 5000, '-');-//1: Always segmantation
fault
//$cont = ' . str_pad('', 4000, '-');//2: Never (Is I can see in
1000 iterations) segmantation fault
//$cont = ' . str_pad('', 4965, '-');//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = ' . str_pad('', 4967, '-');//4: Segfaulted 50/50%
$reg = #'((?(?:[^']|(?=\\\)')*))'#;
preg_replace($reg, '', $cont);
echo OK\n;
?
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47520edit=1
#47525 [NEW]: value returned from __call copied prematurely
From: rodricg at sellingsource dot com
Operating system: linux
PHP version: 5.2.9
PHP Bug Type: Class/Object related
Bug description: value returned from __call copied prematurely
Description:
Values returned from the magic __call method are copied immediately
resulting in increased memory usage.
Reproduce code:
---
?php
function mem($msg='') { echo ($msg ? $msg.: :
'').number_format(memory_get_usage(1)).\n; }
class A
{
public $str;
public function __construct() { $this-str = str_repeat(a, 100);
}
public function __call($m, $a) {return $this-str;}
public function getStr() {return $this-str;}
}
$a = new A(); mem('new A()');
$b = $a-str; mem('$a-str');
$c = $a-getStr(); mem('$a-getStr()');
$d = $a-magic(); mem('$a-magic()');
?
Expected result:
new A(): 1,310,720
$a-str: 1,310,720
$a-getStr(): 1,310,720
$a-magic(): 1,310,720
Actual result:
--
new A(): 1,310,720
$a-str: 1,310,720
$a-getStr(): 1,310,720
$a-magic(): 2,359,296
--
Edit bug report at http://bugs.php.net/?id=47525edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47525r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47525r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47525r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47525r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47525r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47525r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47525r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47525r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47525r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47525r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47525r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47525r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47525r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47525r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47525r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47525r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47525r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47525r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47525r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47525r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47525r=mysqlcfg
#47517 [Fbk-Opn]: php-cgi.exe missing UAC manifest
ID: 47517 User updated by: louis at steelbytes dot com Reported By: louis at steelbytes dot com -Status: Feedback +Status: Open Bug Type: Feature/Change Request Operating System: Win32 PHP Version: 5.2.9 New Comment: Why do you need one? as originally stated, to avoid Vista's (or 2k8's) virtualisation of the file system. eg if from a script I attempt to write to c:\ProgramData\MyCompany\MyApp\file.ext and I don't have enough NTFS perms, then vista virtualises this into %USERPROFILE%\AppData\Local\VirtualStore\ProgramData\MyCompany\MyApp\file.ext instead of giving me an access denied error. inherits the UAC from the caller no, but yes, but no. it the caller is elevated, then yes the spawned task (php) inherits this elevation. this is not the same thing that I am talking about though. if an app has this manifest embedded, then no matter what the elevation status or what perms the user has, file and reg operations won't be virtulised. .. note: this probably has very little relavence when run as cgi/fcgi on a webserver, but when running as a cli for misc scripts on my pc then it matters. really there is no reason to not have one that I can see. Previous Comments: [2009-02-27 09:13:05] paj...@php.net Why do you need one? php can be used in any situations and inherits (or is set by) the UAC from the caller (in case of fcgi or another SAPI for example). [2009-02-27 06:23:35] louis at steelbytes dot com reason: so that UAC won't virtualize file read/writes. [2009-02-27 03:51:48] louis at steelbytes dot com Description: php-cgi.exe (and I guess other php .exe's) should have a UAC manifest stating asInvoker Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=47517edit=1
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: jochen at keutel dot de Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: I'd definitely need this patch going into an official PHP release. We're using PHP-LDAP to access the corporate directory - including authentication against the directory. We definitely need to support password policies. This patch would be the perfect solution. Regards, Jochen. Previous Comments: [2009-02-13 15:34:13] bartzy at gmail dot com Hi, I wanted to ask if there's anything new with this patch ? When will it be integrated into a PHP release ? Thank you ! [2009-01-12 03:38:01] Tyron dot Delean at unisa dot edu dot au I really really really really need Paging support for PHP LDAP calls. This is a super super super high priority for me to get an App working. Could somebody please tell me when the support for Paged Results from LDAP calls will be available, and what version of PHP will support it. I have checked the latest source versions for PHP 5.3 PHP 6.0 snapshots and can't see it in there. I hope I am missing something. Extremely concerned. Tyron [2009-01-03 20:48:50] nelg at linuxsolutions dot co dot nz Hi, I am really keen to see this patch applied, as without it, the is some things that cannot easily be done in LDAP with PHP. Any progress? last comment seems to indicate it was going to be committed soon, but I don't see it in the php source tree yet. [2008-11-16 23:22:00] iarenuno at eteo dot mondragon dot edu pajoye, thanks a lot for your work to get this patch into core. This was a much needed feature in big LDAP installations. Saludos. Iñaki. [2008-11-16 14:57:56] paj...@php.net Alexey has ported the patch to 5.3, it will committed in the next days. 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060edit=1
#47504 [Com]: error SQLSTATE[HY000]: General error: 2014 with sql comments
ID: 47504
Comment by: admin at ifyouwantblood dot de
Reported By: admin at ifyouwantblood dot de
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP 3
PHP Version: 5.2.8
New Comment:
also appears in 5.2.9
Previous Comments:
[2009-02-25 21:07:16] admin at ifyouwantblood dot de
Description:
i get this error with following code:
-
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other
unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql, you
may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. HY000
#0 D:\_projects\web\1.php(13): PDO-query('INSERT INTO `te...')
#1 {main}
--
removing !SQL COMMENTS! will solve this. this only appears on windows
(XP), linux is fine. mysql version is 5.0.51a. latest XAMPP package was
used to test this (without modifications).
Reproduce code:
---
?php
set_exception_handler('ehandler');
$pdo=new PDO('mysql:dbname=barcodescanner;host=127.0.0.1','root','');
$pdo-setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$pdo-query(' CREATE TABLE IF NOT EXISTS `test` (
`some` VARCHAR( 100 ) NOT NULL
) ENGINE = INNODB ');
$pdo-query('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE');
$pdo-query('START TRANSACTION');
$pdo-query(INSERT INTO `test` (some) VALUES (''),
('1'); -- I AM AN SQL COMMENT, REMOVING ME WILL SOLVE THIS
PROBLEM);
$pdo-query(INSERT INTO `test` (some) VALUES (''),
('1'));
$pdo-query('COMMIT');
function ehandler($exception)
{
echo 'pre'.\r\n;
echo $exception-getMessage().' '.$exception-getCode();
echo \r\n\r\n;
echo $exception-getTraceAsString();
echo '/pre';
}
Expected result:
nothing
Actual result:
--
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other
unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql, you
may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. HY000
#0 D:\_projects\web\1.php(13): PDO-query('INSERT INTO `te...')
#1 {main}
--
Edit this bug report at http://bugs.php.net/?id=47504edit=1
