[PHP-BUG] Bug #61782 [NEW]: __clone/__destruct do not match other methods when checking access controls
From:
Operating system:
PHP version: 5.4.1RC2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:__clone/__destruct do not match other methods when checking
access controls
Description:
__clone and __destruct check access to protected methods differently from
other
methods. They have
custom implementation and while other methods allow access to siblings in
the
same tree to protected
functions, those do not. See implementation for regular ones:
if (UNEXPECTED(!zend_check_protected(zend_get_function_root_class(fbc),
EG(scope {
if (zobj->ce->__call) {
fbc = zend_get_user_call_function(zobj->ce, method_name,
method_len);
} else {
zend_error_noreturn(E_ERROR, "Call to %s method %s::%s() from
context '%s'",
zend_visibility_string(fbc->common.fn_flags), ZEND_FN_SCOPE_NAME(fbc),
method_name, EG(scope) ?
EG(scope)->name : "");
}
}
and for __clone:
if (UNEXPECTED(!zend_check_protected(clone->common.scope, EG(scope {
zend_error_noreturn(E_ERROR, "Call to protected %s::__clone() from
context '%s'", ce->name,
EG(scope) ? EG(scope)->name : "");
}
it can be seen that __clone does not use zend_get_function_root_class().
Same
happens for destructor.
I see no reason for that and I think they should be brought in sync with
the
rest of the code. See also:
http://www.mail-archive.com/internals@lists.php.net/msg57424.html
Test script:
---
abstract class BaseClass {
abstract protected function __clone();
}
class MommasBoy extends BaseClass {
protected function __clone() {
echo __METHOD__, "\n";
}
}
class LatchkeyKid extends BaseClass {
public function __construct() {
echo 'In ', __CLASS__, ":\n";
$kid = new MommasBoy();
$kid = clone $kid;
}
public function __clone() {}
}
$obj = new LatchkeyKid();
Expected result:
In LatchkeyKid:
MommasBoy::__clone
Actual result:
--
Fatal error: Call to protected MommasBoy::__clone() from context
'LatchkeyKid' in
bug.php on line 16
--
Edit bug report at https://bugs.php.net/bug.php?id=61782&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61782&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61782&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61782&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61782&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61782&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61782&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61782&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61782&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61782&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61782&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61782&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61782&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61782&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61782&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61782&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61782&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61782&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61782&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61782&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61782&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61782&r=mysqlcfg
Bug #54197 [Com]: [PATH=] sections incompatibility with user_ini.filename set to null
Edit report at https://bugs.php.net/bug.php?id=54197&edit=1 ID: 54197 Comment by: julientld at free dot fr Reported by:julientld at free dot fr Summary:[PATH=] sections incompatibility with user_ini.filename set to null Status: Closed Type: Bug Package:PHP options/info functions Operating System: Windows Server 2003 SP2 PHP Version:5.3.5 Assigned To:ab Block user comment: N Private report: N New Comment: Thanks for this fix! PS: Windows Snaps links are dead at this time (404 error) Previous Comments: [2012-04-20 02:15:42] fel...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Thanks for the patch and for testing! [2012-04-20 02:15:17] fel...@php.net Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=c3b0fb4fbe20e46266a792cb1f332d08ef40923b Log: - Fixed bug #54197 ([PATH=] sections incompatibility with user_ini.filename set to null) patch by a...@php.net [2012-03-01 22:20:18] mattfic...@php.net I can reproduce this problem on Windows 2003 (and also Windows 2008r2). The attached patch, when php recompiled, fixes the problem for me. It fixes it both on 5.3.5 and 5.3.10 on Windows 2003 and Windows 2008r2. [2012-03-01 11:16:18] julientld at free dot fr Hi, Thanks for the patch. I will try it as soon as it is avaible in a beta version of PHP 5.3.x. Julien [2012-03-01 10:35:42] a...@php.net The bug was still in the 5.3 trunk, but it's section independent as there was an attepmpt to free an uninitialized variable. The bug is windows only. With the patch, putting user_ini.filename = outside the path section, both local and global values are null. Putting it into the section only local value is null. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54197 -- Edit this bug report at https://bugs.php.net/bug.php?id=54197&edit=1
Bug #61774 [Fbk->Csd]: Public object variables with numbers as name are not public after unserialize
Edit report at https://bugs.php.net/bug.php?id=61774&edit=1 ID: 61774 User updated by:pandenitz at mail dot ru Reported by:pandenitz at mail dot ru Summary:Public object variables with numbers as name are not public after unserialize -Status: Feedback +Status: Closed Type: Bug Package:Class/Object related Operating System: Win 7 64x PHP Version:5.3.11RC2 Block user comment: N Private report: N New Comment: Yes, I can confirm that it is fixed in recent 5.3.10. Closing issue. Previous Comments: [2012-04-19 22:51:40] ni...@php.net Actually, I just tried again with a more updated 5.3 build and it works fine there. The issue was fixed in http://svn.php.net/viewvc?view=revision&revision=317438 which shipped with PHP 5.3.9. Could you check a PHP 5.3 build >= 5.3.9 and see whether the issue persists? [2012-04-19 22:38:40] ni...@php.net Can repro on PHP 5.3, but not on 5.4. Everything fine there. [2012-04-19 14:43:30] pandenitz at mail dot ru Description: Object variables with numbers as name are not public after unserialize. So i.e. get_object_vars() doesn't return this vars because they are not public Test script: --- $varname = 1; $a->test = 1; var_dump($a); print_r($a); echo ''; $s = serialize($a); $a2 = unserialize($s); var_dump($a2); print_r($a2); echo ''; var_dump(get_object_vars($a2)); print_r(get_object_vars($a2)); Expected result: Such vars should be public after unserialize. Actual result: -- Vars are not actually public. -- Edit this bug report at https://bugs.php.net/bug.php?id=61774&edit=1
Bug #61767 [Opn->Ana]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Updated by: larue...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
-Status: Open
+Status: Analyzed
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I attached a fix for this, maybe need dmitry to review it.
Previous Comments:
[2012-04-20 06:01:10] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61767.patch
Revision: 1334901670
URL:
https://bugs.php.net/patch-display.php?bug=61767&patch=bug61767.patch&revision=1334901670
[2012-04-20 05:52:05] larue...@php.net
a E_NOTICE "undefined variable" has been triggered before the FATAL_ERROR.
hmm,
the same thing as #60909
[2012-04-19 22:56:56] ni...@php.net
This seems related: https://bugs.php.net/bug.php?id=60909
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #61767 [PATCH]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Patch added by: larue...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61767.patch
Revision: 1334901670
URL:
https://bugs.php.net/patch-display.php?bug=61767&patch=bug61767.patch&revision=1334901670
Previous Comments:
[2012-04-20 05:52:05] larue...@php.net
a E_NOTICE "undefined variable" has been triggered before the FATAL_ERROR.
hmm,
the same thing as #60909
[2012-04-19 22:56:56] ni...@php.net
This seems related: https://bugs.php.net/bug.php?id=60909
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #61767 [Opn]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Updated by: larue...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
a E_NOTICE "undefined variable" has been triggered before the FATAL_ERROR.
hmm,
the same thing as #60909
Previous Comments:
[2012-04-19 22:56:56] ni...@php.net
This seems related: https://bugs.php.net/bug.php?id=60909
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #61775 [Com]: Preg_match does not support unicode.
Edit report at https://bugs.php.net/bug.php?id=61775&edit=1 ID: 61775 Comment by: asersz at gmail dot com Reported by:asersz at gmail dot com Summary:Preg_match does not support unicode. Status: Not a bug Type: Bug Package:PCRE related Operating System: MacOS Lion 10.7.2 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Warning: preg_match(): Compilation failed: unknown option bit(s) set at offset 0 in /Users/zhangyowei/Web/lieqee/test.php on line 5 bool(false) NULL Your expression trigger a warning too. Previous Comments: [2012-04-20 03:11:57] asersz at gmail dot com But this expression works fine in the PHP 5.3.x (and 5.2.x). And works fine without the Modifier "u". Why does not works fine in PHP 5.4? [2012-04-19 21:09:09] cataphr...@php.net Your expression is wrong. Version 8.02 of PCRE, which you're using, gives that rather cryptic error, but more recent versions, including the one bundled with PHP say: Warning: preg_match(): Compilation failed: unrecognized character after (?P at offset 4 in - on line 3 Probably you want something like: \w+)\/(?P\d+)\/$/u'; var_dump(preg_match($r,'test/3423/',$m), $m); [2012-04-19 17:07:44] asersz at gmail dot com Description: I am not good at english. A warning: preg_match(): Compilation failed: unknown option bit(s) set at offset 0 OS: MacOSX Lion 10.7.2 Web Server: apache 2 PHP : 5.4.0 PCRE (Perl Compatible Regular Expressions) Support: enabled PCRE Library Version: 8.02 2010-03-19 By the way: the php 5.4.0 released is stable or not ? thanks. Test script: --- https://bugs.php.net/bug.php?id=61775&edit=1
Bug #61775 [Nab]: Preg_match does not support unicode.
Edit report at https://bugs.php.net/bug.php?id=61775&edit=1 ID: 61775 User updated by:asersz at gmail dot com Reported by:asersz at gmail dot com Summary:Preg_match does not support unicode. Status: Not a bug Type: Bug Package:PCRE related Operating System: MacOS Lion 10.7.2 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: But this expression works fine in the PHP 5.3.x (and 5.2.x). And works fine without the Modifier "u". Why does not works fine in PHP 5.4? Previous Comments: [2012-04-19 21:09:09] cataphr...@php.net Your expression is wrong. Version 8.02 of PCRE, which you're using, gives that rather cryptic error, but more recent versions, including the one bundled with PHP say: Warning: preg_match(): Compilation failed: unrecognized character after (?P at offset 4 in - on line 3 Probably you want something like: \w+)\/(?P\d+)\/$/u'; var_dump(preg_match($r,'test/3423/',$m), $m); [2012-04-19 17:07:44] asersz at gmail dot com Description: I am not good at english. A warning: preg_match(): Compilation failed: unknown option bit(s) set at offset 0 OS: MacOSX Lion 10.7.2 Web Server: apache 2 PHP : 5.4.0 PCRE (Perl Compatible Regular Expressions) Support: enabled PCRE Library Version: 8.02 2010-03-19 By the way: the php 5.4.0 released is stable or not ? thanks. Test script: --- https://bugs.php.net/bug.php?id=61775&edit=1
Bug #54197 [Ana->Csd]: [PATH=] sections incompatibility with user_ini.filename set to null
Edit report at https://bugs.php.net/bug.php?id=54197&edit=1 ID: 54197 Updated by: fel...@php.net Reported by:julientld at free dot fr Summary:[PATH=] sections incompatibility with user_ini.filename set to null -Status: Analyzed +Status: Closed Type: Bug Package:PHP options/info functions Operating System: Windows Server 2003 SP2 PHP Version:5.3.5 Assigned To:ab Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Thanks for the patch and for testing! Previous Comments: [2012-04-20 02:15:17] fel...@php.net Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=c3b0fb4fbe20e46266a792cb1f332d08ef40923b Log: - Fixed bug #54197 ([PATH=] sections incompatibility with user_ini.filename set to null) patch by a...@php.net [2012-03-01 22:20:18] mattfic...@php.net I can reproduce this problem on Windows 2003 (and also Windows 2008r2). The attached patch, when php recompiled, fixes the problem for me. It fixes it both on 5.3.5 and 5.3.10 on Windows 2003 and Windows 2008r2. [2012-03-01 11:16:18] julientld at free dot fr Hi, Thanks for the patch. I will try it as soon as it is avaible in a beta version of PHP 5.3.x. Julien [2012-03-01 10:35:42] a...@php.net The bug was still in the 5.3 trunk, but it's section independent as there was an attepmpt to free an uninitialized variable. The bug is windows only. With the patch, putting user_ini.filename = outside the path section, both local and global values are null. Putting it into the section only local value is null. [2012-03-01 10:23:10] a...@php.net The following patch has been added/updated: Patch Name: fix_unintialized_doc_root Revision: 1330597390 URL: https://bugs.php.net/patch-display.php?bug=54197&patch=fix_unintialized_doc_root&revision=1330597390 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54197 -- Edit this bug report at https://bugs.php.net/bug.php?id=54197&edit=1
Bug #61766 [Opn->Nab]: call_user_func sends scrambled class name to autoload
Edit report at https://bugs.php.net/bug.php?id=61766&edit=1
ID: 61766
Updated by: ahar...@php.net
Reported by:admin dot windows at gmail dot com
Summary:call_user_func sends scrambled class name to
autoload
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: ALL
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
We really can't support any third party extensions. It could be any or none of
them.
Since you're unable to disable those extensions, I'm going to close this bug
for
now. If you are able to get your host to disable all third party extensions,
including the Suhosin patch, and the behaviour recurs, please reopen the bug.
Previous Comments:
[2012-04-19 10:37:07] admin dot windows at gmail dot com
Unfortunately I don't have rights to enable or disable modules on my cloud, I
would pass this issue to my hosting support.
Also I noticed that server is protected with the Suhosin Patch 0.9.10 can it
cause
this behavior?
[2012-04-19 09:21:26] johan...@php.net
Please disable ionCube Loader, Zend Guard Loader and XCache as all of these 3rd
party modules change the engine's behaviour.
[2012-04-19 09:06:56] admin dot windows at gmail dot com
Hi,
I have following extensions enabled on my hosting (Rackspace):
Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype,
hash, filter, ftp, gettext, gmp, SPL, iconv, Reflection, session, standard,
shmop, SimpleXML, sockets, exif, tokenizer, xml, apache2handler, bcmath, curl,
dba, dom, fileinfo, gd, imagick, imap, intl, json, ldap, pdf, mbstring, mcrypt,
memcache, mongo, mssql, mysql, mysqli, odbc, PDO, pdo_dblib, pdo_mysql,
PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, recode, redis,
snmp, soap, sysvmsg, sysvsem, sysvshm, tidy, uploadprogress, wddx, xmlreader,
xmlrpc, xmlwriter, xsl, yaz, zip, ionCube Loader, Zend Guard Loader, XCache
[2012-04-19 07:07:33] ahar...@php.net
I can't reproduce this.
What extensions do you have enabled?
[2012-04-18 15:19:23] admin dot windows at gmail dot com
Description:
I have discovered weird behaviour of call_user_func that breaks class
autoloader by providing scrambled class name for example instead of "myObject"
it provides "zw87zl18".
This event only occurs if you are using custom class autoloader and requesting
static method that is not declared as static.
Test script:
---
//FILE: myObject.php
class myObject {
public static function method1(){var_dump(__METHOD__);}
public function method2(){var_dump(__METHOD__);}
}
//FILE: index.php
ini_set('display_errors', TRUE);
function __autoload($className) {
include sprintf('%s/%s.php', getcwd(), $className);
}
call_user_func(array('myObject', 'method1'));//works fine
call_user_func(array('myObject', 'method2'));//produce an error
Expected result:
string(17) "myObject::method1"
string(17) "myObject::method2"
Actual result:
--
string(17) "myObject::method1"
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
string(17) "myObject::method2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61766&edit=1
Bug #60185 [Opn->Ver]: Unable to send the process to background, In PHP CLI mode,
Edit report at https://bugs.php.net/bug.php?id=60185&edit=1
ID: 60185
Updated by: s...@php.net
Reported by:s dot vijayarangan at gmail dot com
Summary:Unable to send the process to background, In PHP CLI
mode,
-Status: Open
+Status: Verified
Type: Bug
Package:CGI/CLI related
Operating System: Cent OS 6 (64bit)
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Happens to me too. Backtrace when it stops:
#0 0x90b99aca in ioctl ()
#1 0x90ba0a63 in tcsetattr ()
#2 0x00d50fb1 in tty_init ()
#3 0x00d42794 in el_init ()
#4 0x00d48eef in rl_initialize ()
#5 0x005e37e2 in zm_startup_readline (type=1, module_number=36) at
/Users/smalyshev/php-5.3/ext/readline/readline.c:168
66 PHP_MINIT_FUNCTION(readline)
167 {
168 using_history();
169 return SUCCESS;
170 }
Previous Comments:
[2011-11-04 03:26:03] s dot vijayarangan at gmail dot com
No it's not compiled with readline module
Below is the phpinfo() details
PHP Version => 5.3.8
System => Linux localhost.localdomain 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun
27 19:49:27 BST 2011 x86_64
Build Date => Sep 25 2011 11:32:47
Configure Command => './configure' '--build=x86_64-unknown-linux-gnu'
'--host=x86_64-unknown-linux-gnu' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share'
'--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-libdir=lib64' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic'
'--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin'
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr'
'--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext'
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--with-kerberos'
'--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar'
'--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--with-mhash'
'--enable-force-cgi-redirect' '--libdir=/usr/lib64/php' '--enable-pcntl'
'--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared'
'--enable-mbregex' '--with-gd=shared' '--enable-bcmath=shared'
'--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared'
'--with-ldap=shared' '--with-ldap-sasl' '--enable-mysqlnd=shared'
'--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd'
'--with-oci8=shared,instantclient,/usr/lib64/oracle/11.2/client64/lib,11.2'
'--with-pdo-oci=shared,instantclient,/usr,11.2'
'--with-interbase=shared,/usr/lib64/firebird'
'--with-pdo-firebird=shared,/usr/lib64/firebird' '--enable-dom=shared'
'--with-pgsql=shared' '--enable-wddx=shared' '--with-snmp=shared,/usr'
'--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared'
'--enable-xmlwriter=shared' '--with-curl=shared,/usr' '--enable-fastcgi'
'--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr'
'--with-pdo-mysql=shared,mysqlnd' '--with-pdo-pgsql=shared,/usr'
'--with-pdo-sqlite=shared,/usr' '--with-pdo-dblib=shared,/usr'
'--with-sqlite3=shared,/usr' '--with-sqlite=shared,/usr' '--enable-json=shared'
'--enable-zip=shared' '--without-readline' '--with-libedit'
'--with-pspell=shared' '--enable-phar=shared' '--with-mcrypt=shared,/usr'
'--with-tidy=shared,/usr' '--with-mssql=shared,/usr' '--enable-sysvmsg=shared'
'--enable-sysvshm=shared' '--enable-sysvsem=shared' '--enable-posix=shared'
'--with-unixODBC=shared,/usr' '--enable-fileinfo=shared' '--enable-intl=shared'
'--with-icu-dir=/usr' '--with-enchant=shared,/usr' '--with-recode=shared,/usr'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
Additional .ini files parsed => /etc/php.d/curl.ini,
/etc/php.d/fileinfo.ini,
/etc/php.d/json.ini,
/etc/php.d/phar.ini,
/etc/php.d/zip.ini
PHP API => 20090626
PHP Extension => 20090626
Zend Extension => 220090626
Zend Extension Build => API220090626,NTS
PHP Extension Build => API20090626,NTS
Debug Build => no
Thread Safety => disabled
Zend Memory Manager => enabled
Zend Multibyte Support => disabled
IPv6 Support => enabled
Registered PHP Streams => https, ftps, compress.zlib, compress.bzip2, php,
file, glob, data, http, ftp, phar, zip
Registered Stream Socket Transports => tcp, udp, unix, udg, ss
Bug #61246 [Opn->Csd]: Error when running PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=61246&edit=1 ID: 61246 Updated by: fel...@php.net Reported by:osmanungur at gmail dot com Summary:Error when running PHP-FPM -Status: Open +Status: Closed Type: Bug Package:FPM related Operating System: Mac Os X 10.7.3 PHP Version:5.4.0 -Assigned To: +Assigned To:felipe Block user comment: N Private report: N Previous Comments: [2012-03-31 18:50:13] kaplanlior at gmail dot com Seems like a duplicate of #61238 which was already fixed in APC at revision 324146. [2012-03-28 10:36:42] wdauchy at gmail dot com I also tested with the last revision of apc (r324329 in my case); it fixes the problem. I guess this bug should be considered as fixed. [2012-03-28 10:09:23] wdauchy at gmail dot com I also have the same problem with debian 5.4.0-3 packages. Disabling apc (apc.enabled = 0) is a workaround which make php-fpm start. [2012-03-16 08:14:05] ben at customerparadigm dot com Hello, I am currently running the following setup for PHP: --configure-options [--with-libdir=lib64 --with-gd --enable-fpm --with-mcrypt - -with-curl --with-mysql --with-pdo-mysql] --version [5.4.0] --vernum[50400] I checked out the following APC revision: 324292 >From there I recompiled, and re-installed APC. Finally, restarted php-fpm and everything is working fine so far! --Ben Korn [2012-03-13 15:25:59] gonperes at gmail dot com Greetings. I just downloaded latest dev version (5.4.1RC1-dev) and i'm still having this problem: Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: free(): invalid pointer: 0x2aedda63c698 *** (...) and a bunch of lines after this (...) Everything seems to be working though. It's just this annoying error message. My setup: './configure' '--enable-fpm' '--with-fpm-user=www-data' '--with-fpm-group=www- data' '--with-curl' '--with-gd' '--with-jpeg-dir' '--with-freetype-dir' '-- enable-gd-native-ttf' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with- pear' '--enable-soap' '--with-imap' '--with-imap-ssl' '--with-kerberos' '-- disable-pdo' '--with-zlib' '--with-openssl' '--enable-zip' make make install pecl install apc Cheers! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61246 -- Edit this bug report at https://bugs.php.net/bug.php?id=61246&edit=1
Bug #60569 [Asn]: Nullbyte truncates Exception $message.
Edit report at https://bugs.php.net/bug.php?id=60569&edit=1 ID: 60569 Updated by: fel...@php.net Reported by:hanskrentel at yahoo dot de Summary:Nullbyte truncates Exception $message. Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Fedora 14 PHP Version:5.3.8 Assigned To:iliaa Block user comment: N Private report: N New Comment: I got the expected result: Original Message..: Null Char Test. Processed Message.: Null Char Test. Previous Comments: [2012-04-18 09:45:23] larue...@php.net Automatic comment on behalf of iliaa Revision: http://git.php.net/?p=php-src.git;a=commit;h=d4f05fbffc6f63e094c0f737e0477e27f1bf5f7f Log: Fixed bug #60569 (Nullbyte truncates Exception $message). [2012-03-19 11:50:54] hanskrentel at yahoo dot de Re-open because it is not fixed. [2012-03-14 10:52:47] hanskrentel at yahoo dot de Tested against PHP trunk Revision: 324199 (Windows), there still is truncation on the NULL char. $original = "Null Char \0 Test."; echo "Original Message..: ", $original, "\n"; $e = new Exception($original); $processed = $e->getMessage(); echo "Processed Message.: ", $processed, "\n"; [2012-03-11 18:15:12] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-11 18:15:03] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=324112 Log: Fixed bug #60569 (Nullbyte truncates Exception $message). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60569 -- Edit this bug report at https://bugs.php.net/bug.php?id=60569&edit=1
Bug #61506 [Opn->Asn]: insteadof cause memory leak if class is not binded
Edit report at https://bugs.php.net/bug.php?id=61506&edit=1
ID: 61506
Updated by: fel...@php.net
Reported by:xuefer at gmail dot com
Summary:insteadof cause memory leak if class is not binded
-Status: Open
+Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.4.0
-Assigned To:
+Assigned To:gron
Block user comment: N
Private report: N
Previous Comments:
[2012-03-26 16:28:02] yohg...@php.net
Changed package from Compile Issue.
[2012-03-26 05:49:39] xuefer at gmail dot com
Description:
when class is not binded, "insteadof" cause a detected memory leak. see the
following script and output
==
after days tracking, i lock on _destroy_zend_class_traits_info
if (ce->trait_precedences) {
size_t i = 0;
while (ce->trait_precedences[i]) {
efree((char*)ce->trait_precedences[i]->trait_method->method_name);
efree((char*)ce->trait_precedences[i]->trait_method->class_name);
efree(ce->trait_precedences[i]->trait_method);
if (ce->trait_precedences[i]->exclude_from_classes) {
efree(ce->trait_precedences[i]->exclude_from_classes); <-
before this line
}
ce->trait_precedences[i]->exclude_from_classes[0] is string, should but not
efree'ed, this is why it's leaking. however when the class is bind, it is
zend_class_entry and should not efree
Test script:
---
https://bugs.php.net/bug.php?id=61506&edit=1
[PHP-BUG] Bug #61780 [NEW]: Inconsistent PCRE captures in match results
From:
Operating system:
PHP version: 5.4.0
Package: PCRE related
Bug Type: Bug
Bug description:Inconsistent PCRE captures in match results
Description:
Named and unnamed captures in both preg_match and preg_match_all (and
probably preg_replace and the other PCRE functions too but I haven't tested
them all) can capture the wrong number of parentheses if alternation or a
zero-or-more quantifier is used.
If the pattern '/(?b)|(?c)|(?d)/' is used to match 'c', both 'b'
and 'c' will be set in the results array but 'd' won't be. 'b' should not
be set (even to an empty string) as it failed to match anything. However,
if it was trying to match '/(?b?)(?c)/' (note: optional 'b' AND
mandatory 'c'), 'b' _should_ be set to '' as it's allowed to match a
zero-length string. If a match gets tried but it fails and a capture later
in the pattern works, the skipped capture should never produce a key in the
results array. It should be OK to leave holes in the numbered sequence
(e.g. match 0 and 2 but not 1).
Currently, you need to use PREG_OFFSET_CAPTURE and test to see if the key
exists, and if it does, test to see if the capture position is -1. If this
bug is fixed, capture positions will never be -1 as the key won't exist.
Alternatively, an additional flag could be added (e.g.
PREG_KEEP_NONMATCHES) to create keys for ALL captures whether used or not
(so, in the first pattern above, keys would be created for 'b', 'c' and 'd'
in all cases, and if matching the string 'c' the offsets for both 'b' and
'd' would be -1).
In summary, if the pattern '/(?b)|(?c)|(?d)/' is used to match
'c', by default it should only ever create a key for 'c'. If desired, an
additional flag could be added so that it creates keys for all captures:
'b', 'c' and 'd'. The current behaviour where it creates a key for 'b' and
'c' but not 'd' should be considered a bug and fixed.
Test script:
---
print('');
$offset = 0;
while (preg_match('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec',
$matches, PREG_OFFSET_CAPTURE, $offset)) {
$offset = $matches[0][1] + strlen($matches[0][0]);
var_export($matches);
print("\n\n");
}
print("\n\n");
preg_match_all('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec', $matches,
PREG_OFFSET_CAPTURE | PREG_SET_ORDER);
var_export($matches);
print('');
Expected result:
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
)
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
)
array (
0 =>
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
),
1 =>
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
),
2 =>
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
),
)
Actual result:
--
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => '',
1 => -1,
),
2 =>
array (
0 => '',
1 => -1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
)
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
)
array (
0 =>
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
Bug #61778 [Opn->Csd]: Crash when overloaded method called from class constructor
Edit report at https://bugs.php.net/bug.php?id=61778&edit=1
ID: 61778
Updated by: ni...@php.net
Reported by:james dot thomsen at gmail dot com
Summary:Crash when overloaded method called from class
constructor
-Status: Open
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: Windows 2003
PHP Version:5.4.0
-Assigned To:
+Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
Just checked again: This was already fixed in
https://github.com/php/php-src/commit/da6465a268d9ece2ffd38447890b206dd94b3250,
that's why it was running fine for me.
So this should be fixed in PHP 5.4.1 :)
Previous Comments:
[2012-04-20 00:31:47] james dot thomsen at gmail dot com
Yes, it crashes at the command line too. The windows event logs record the
crash.
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 4/19/2012
Time: 1:40:27 PM
User: N/A
Computer: SPWEB01
Description:
Faulting application php-cgi.exe, version 5.4.0.0, faulting module php5.dll,
version 5.4.0.0, fault address 0x002f8b80.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 70 68 70 ure php
0018: 2d 63 67 69 2e 65 78 65 -cgi.exe
0020: 20 35 2e 34 2e 30 2e 305.4.0.0
0028: 20 69 6e 20 70 68 70 35in php5
0030: 2e 64 6c 6c 20 35 2e 34 .dll 5.4
0038: 2e 30 2e 30 20 61 74 20 .0.0 at
0040: 6f 66 66 73 65 74 20 30 offset 0
0048: 30 32 66 38 62 38 30 02f8b80
[2012-04-20 00:19:44] ni...@php.net
This script runs fine on CLI for me. Could you see whether running on CLI works
for you?
[2012-04-19 20:20:31] james dot thomsen at gmail dot com
Description:
If a class overrides a method but with a different signature and that method is
called in the constructor and if error_reporting is set to display strict
errors and if the classes are defined in reverse order, PHP will crash. In my
test script, if class one is defined before class two, PHP won't crash. I
realize that overridden methods need to have identical signatures, but I would
expect a warning and not a crash.
Test script:
---
error_reporting(-1);
class two extends one{
public function __construct(){
$this->error(7);
}
private function error($n){
echo 'two';
}
}
class one{
private function error(){
echo 'one';
}
}
new two;
Expected result:
two
Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.
Error Details:
The FastCGI process exited unexpectedly
Error Number: -2147467259 (0x80004005).
Error Description: Unspecified error
HTTP Error 500 - Server Error.
Internet Information Services (IIS)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61778&edit=1
Bug #61778 [Opn]: Crash when overloaded method called from class constructor
Edit report at https://bugs.php.net/bug.php?id=61778&edit=1
ID: 61778
User updated by:james dot thomsen at gmail dot com
Reported by:james dot thomsen at gmail dot com
Summary:Crash when overloaded method called from class
constructor
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Windows 2003
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Yes, it crashes at the command line too. The windows event logs record the
crash.
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 4/19/2012
Time: 1:40:27 PM
User: N/A
Computer: SPWEB01
Description:
Faulting application php-cgi.exe, version 5.4.0.0, faulting module php5.dll,
version 5.4.0.0, fault address 0x002f8b80.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 70 68 70 ure php
0018: 2d 63 67 69 2e 65 78 65 -cgi.exe
0020: 20 35 2e 34 2e 30 2e 305.4.0.0
0028: 20 69 6e 20 70 68 70 35in php5
0030: 2e 64 6c 6c 20 35 2e 34 .dll 5.4
0038: 2e 30 2e 30 20 61 74 20 .0.0 at
0040: 6f 66 66 73 65 74 20 30 offset 0
0048: 30 32 66 38 62 38 30 02f8b80
Previous Comments:
[2012-04-20 00:19:44] ni...@php.net
This script runs fine on CLI for me. Could you see whether running on CLI works
for you?
[2012-04-19 20:20:31] james dot thomsen at gmail dot com
Description:
If a class overrides a method but with a different signature and that method is
called in the constructor and if error_reporting is set to display strict
errors and if the classes are defined in reverse order, PHP will crash. In my
test script, if class one is defined before class two, PHP won't crash. I
realize that overridden methods need to have identical signatures, but I would
expect a warning and not a crash.
Test script:
---
error_reporting(-1);
class two extends one{
public function __construct(){
$this->error(7);
}
private function error($n){
echo 'two';
}
}
class one{
private function error(){
echo 'one';
}
}
new two;
Expected result:
two
Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.
Error Details:
The FastCGI process exited unexpectedly
Error Number: -2147467259 (0x80004005).
Error Description: Unspecified error
HTTP Error 500 - Server Error.
Internet Information Services (IIS)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61778&edit=1
Bug #61778 [Com]: Crash when overloaded method called from class constructor
Edit report at https://bugs.php.net/bug.php?id=61778&edit=1
ID: 61778
Comment by: ni...@php.net
Reported by:james dot thomsen at gmail dot com
Summary:Crash when overloaded method called from class
constructor
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Windows 2003
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
This script runs fine on CLI for me. Could you see whether running on CLI works
for you?
Previous Comments:
[2012-04-19 20:20:31] james dot thomsen at gmail dot com
Description:
If a class overrides a method but with a different signature and that method is
called in the constructor and if error_reporting is set to display strict
errors and if the classes are defined in reverse order, PHP will crash. In my
test script, if class one is defined before class two, PHP won't crash. I
realize that overridden methods need to have identical signatures, but I would
expect a warning and not a crash.
Test script:
---
error_reporting(-1);
class two extends one{
public function __construct(){
$this->error(7);
}
private function error($n){
echo 'two';
}
}
class one{
private function error(){
echo 'one';
}
}
new two;
Expected result:
two
Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.
Error Details:
The FastCGI process exited unexpectedly
Error Number: -2147467259 (0x80004005).
Error Description: Unspecified error
HTTP Error 500 - Server Error.
Internet Information Services (IIS)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61778&edit=1
Bug #60909 [Com]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Comment by: ni...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: I tried adding an EG(exception) = NULL; at the start of php_request_shutdown() and it indeed fixes the issue. Though probably that's not the right way to fix this. Previous Comments: [2012-04-19 23:40:57] ni...@php.net So, this is what I think is happening here: 1. The first non-fatal error (here warning) throws an Exception, i.e. sets EG(exception) 2. The second fatal error then causes a zend_bailout() moving us directly to php_request_shutdown() 3. During the shutdown sequence PHP will try to call the shutdown handler using call_user_function(). 4. As EG(exception) is still set, the call is not allows (see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#775). [2012-04-19 23:06:26] ni...@php.net Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') [2012-02-09 14:33:57] jpa...@php.net Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
Bug #61697 [Ana->Asn]: spl_autoload_functions returns lambda functions incorrectly
Edit report at https://bugs.php.net/bug.php?id=61697&edit=1 ID: 61697 Updated by: fel...@php.net Reported by:stadli at gmx dot de Summary:spl_autoload_functions returns lambda functions incorrectly -Status: Analyzed +Status: Assigned Type: Bug Package:SPL related PHP Version:5.4.0 -Assigned To: +Assigned To:colder Block user comment: N Private report: N Previous Comments: [2012-04-12 05:21:32] larue...@php.net I have made a patch for this, but there is a BC break, that is, spl_autoload_functions return lambad_function with name "__lambad_function" previously. after patched, it will return string like "lambad_1". [2012-04-12 05:19:39] larue...@php.net The following patch has been added/updated: Patch Name: bug61697.phpt Revision: 1334207979 URL: https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.phpt&revision=1334207979 [2012-04-12 05:16:05] larue...@php.net The following patch has been added/updated: Patch Name: bug61697.patch Revision: 1334207765 URL: https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.patch&revision=1334207765 [2012-04-11 18:29:18] stadli at gmx dot de Description: spl_autoload_functions() doesn't return the names of lambda-functions registered with spl_autoload_register() correctly. Actually it always returns '__lambda_func' for every lambda function so you can't use the result with spl_autoload_unregister() for example. Test script: --- Expected result: All autoload functions are unregistered Actual result: -- lambda functions aren't unregistered -- Edit this bug report at https://bugs.php.net/bug.php?id=61697&edit=1
Bug #60925 [Opn->Asn]: fpm_atomic.h says unknown processor (m68k)
Edit report at https://bugs.php.net/bug.php?id=60925&edit=1 ID: 60925 Updated by: fel...@php.net Reported by:tg at debian dot org Summary:fpm_atomic.h says unknown processor (m68k) -Status: Open +Status: Assigned Type: Bug Package:FPM related Operating System: Linux PHP Version:5.4 -Assigned To: +Assigned To:fat Block user comment: N Private report: N Previous Comments: [2012-04-16 18:31:28] tg at debian dot org Make of this patch what you want. Iâve not gotten anything from the Linux/m68k porters other than âwhat do you do if the syscall does not exist?â with no solution. (On the other hand, it exists with every Linux kernel from 2.6.34 onwards or Debian 2.6.32; and older systems wonât support the last few eglibc major releases anyway, so chances are low someoneâs trying PHP on such systems. And the patch keeps the #error for non-Linux systems.) [2012-03-12 23:31:51] tg at debian dot org Iâve built 5.4.0 with a small patch. Weâre working on getting it usable for upstream inclusion. On Linux/m68k, one uses a syscall for compare-and-swap 32 bit, as some CPUs do not support the machine instruction and probing for it is too tricky in user space. The syscall was introduced along with TLS support, now we probably need to safeguard this from being compiled on âtoo oldâ Linux systems. The patch doesnât address nÅn-Linux m68k, as those are different beasts, and see above. (The ColdFire does not support the instruction, and Linux and MiNT may very well both run on one with MMU, soonish.) [2012-02-02 20:11:39] tg at debian dot org OK; in the meantime Iâll try building without FPM, to see whether there are any other lurking issues on m68k. Thanks for the help with this. [2012-01-31 00:50:00] ahar...@php.net Thanks again. It's been good to triage this down. :) I'll let Jérôme figure out what he wants to do here, since he's the FPM maintainer. I think your list of options pretty much covers it. [2012-01-31 00:39:53] tg at debian dot org Heh, your comment made me go and read the old changelogs of the Debian package on a guess, and I guessed right: php5 (5.3.5-1) unstable; urgency=low * Build the FPM SAPI (Closes: #603174) So this was simply never built before. Now there are two possibilities, disable FPM on m68k (unless gcc-4.7 or up is used) or ask the m68k porters for an implementation of the atomic things. I think. If youâve got a better idea, do tell. By the way, thereâs libatomic-ops-dev, which contains a number of atomic primitives and composed operations on a number of data types (but the catch is, youâve got to use the data types of libatomic-ops-dev, not e.g. like mesa have a function atomic_dec which is passed an int32_t* so itâs not a plug-in replacement. That might be more interesting than hacking in m68k support now, and support for $next_arch later⦠m68k atomic operations apparently have another twist: the compare-and-swap operation only exists on some processors, and not in the Coldfire line, so the Linux kernel got a syscall now to ensure atomicity. GCC 4.7 uses the syscall; most âinlinedâ application code doesnât⦠The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60925 -- Edit this bug report at https://bugs.php.net/bug.php?id=60925&edit=1
Bug #60909 [Com]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Comment by: ni...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: So, this is what I think is happening here: 1. The first non-fatal error (here warning) throws an Exception, i.e. sets EG(exception) 2. The second fatal error then causes a zend_bailout() moving us directly to php_request_shutdown() 3. During the shutdown sequence PHP will try to call the shutdown handler using call_user_function(). 4. As EG(exception) is still set, the call is not allows (see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#775). Previous Comments: [2012-04-19 23:06:26] ni...@php.net Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') [2012-02-09 14:33:57] jpa...@php.net Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
Bug #61769 [Com]: Random failure of php_cli_server*phpt tests
Edit report at https://bugs.php.net/bug.php?id=61769&edit=1 ID: 61769 Comment by: mattfic...@php.net Reported by:mattfic...@php.net Summary:Random failure of php_cli_server*phpt tests Status: Open Type: Bug Package:Built-in web server PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Setting SO_REUSEADDR socket option will not only make sure all the tests pass every time, but also if user restarts the web server, it will make sure the web server can listen on that port when it restarts. Most TCP servers set SO_REUSEADDR option. This is a real problem on Windows and Linux and probably *BSD. Fixing it for those platforms is worth causing a minor compile problem for some weird os that doesn't have SO_REUSEADDR. Alternatively, adding a sleep() call to the test after the web server exits should probably work, but it would make the test very slow (might have to wait 60 seconds for each of 17 tests => 17 minutes). Previous Comments: [2012-04-19 23:17:27] fel...@php.net The test has been fixed in Git. [2012-04-19 14:54:39] a...@php.net just came into my mind - may be it would have an effect if we just set a timeout at the top of the php_cli_server_start() too? so the previous server had a chance to exit ... [2012-04-19 14:34:18] a...@php.net Matt, unfortunately I can't reproduce the fails on my laptops, they're probably too slow. Nevertheless I'm not sure the patch does expected things. I've just debugged on win7 and ubuntu - SO_REUSEADDR is defined everywhere. MSDN even says it's available on all the versions. This means setsockopt should work as expected. Besides that, removing that wrapping #ifdef could have impacts in some rare cases, i think, as SO_REUSEADDR is marked as a BSD macro, so despite it's luckily present on GNU, it might be absent on some POSIX-complaint only systems. Could you please explain why this fix is correct? Also the php_cli_server_017.phpt was still failing for me, but that's just the unix/windows dir separator. [2012-04-19 14:15:26] a...@php.net The following patch has been added/updated: Patch Name: php_cli_server_017.diff Revision: 1334844926 URL: https://bugs.php.net/patch-display.php?bug=61769&patch=php_cli_server_017.diff&revision=1334844926 [2012-04-18 21:21:00] mattfic...@php.net Description: All the php_cli_server* tests randomly fail. Each test starts and stops the builtin web server. The web server when restarted quickly, can't listen on the given port because its locked by the OS. The SO_REUSEADDR option needs to be set on the web server's socket. Test script: --- 007+ string(82) "C:\php-sdk\php-test-pack-5.4-nts-windows-vc9-x86-re7a36ad\Sapi\cli\tests\index.php" 007- string(%d) "%s/tests/index.php" -- Edit this bug report at https://bugs.php.net/bug.php?id=61769&edit=1
Bug #61769 [Opn]: Random failure of php_cli_server*phpt tests
Edit report at https://bugs.php.net/bug.php?id=61769&edit=1 ID: 61769 Updated by: fel...@php.net Reported by:mattfic...@php.net Summary:Random failure of php_cli_server*phpt tests Status: Open Type: Bug Package:Built-in web server PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The test has been fixed in Git. Previous Comments: [2012-04-19 14:54:39] a...@php.net just came into my mind - may be it would have an effect if we just set a timeout at the top of the php_cli_server_start() too? so the previous server had a chance to exit ... [2012-04-19 14:34:18] a...@php.net Matt, unfortunately I can't reproduce the fails on my laptops, they're probably too slow. Nevertheless I'm not sure the patch does expected things. I've just debugged on win7 and ubuntu - SO_REUSEADDR is defined everywhere. MSDN even says it's available on all the versions. This means setsockopt should work as expected. Besides that, removing that wrapping #ifdef could have impacts in some rare cases, i think, as SO_REUSEADDR is marked as a BSD macro, so despite it's luckily present on GNU, it might be absent on some POSIX-complaint only systems. Could you please explain why this fix is correct? Also the php_cli_server_017.phpt was still failing for me, but that's just the unix/windows dir separator. [2012-04-19 14:15:26] a...@php.net The following patch has been added/updated: Patch Name: php_cli_server_017.diff Revision: 1334844926 URL: https://bugs.php.net/patch-display.php?bug=61769&patch=php_cli_server_017.diff&revision=1334844926 [2012-04-18 21:21:00] mattfic...@php.net Description: All the php_cli_server* tests randomly fail. Each test starts and stops the builtin web server. The web server when restarted quickly, can't listen on the given port because its locked by the OS. The SO_REUSEADDR option needs to be set on the web server's socket. Test script: --- 007+ string(82) "C:\php-sdk\php-test-pack-5.4-nts-windows-vc9-x86-re7a36ad\Sapi\cli\tests\index.php" 007- string(%d) "%s/tests/index.php" -- Edit this bug report at https://bugs.php.net/bug.php?id=61769&edit=1
Bug #60909 [Com]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1 ID: 60909 Comment by: ni...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') Previous Comments: [2012-02-09 14:33:57] jpa...@php.net Ok I can reproduce. Try replacing your require (which generates E_COMPILE_ERROR) by an unknown function call (which generates E_ERROR), and all's just fine So there is a trick in the error engine, any kind of fatal shouldn't be handled by user defined error handlers, here we got proof it's not the case Tip: Reproduced on 5.3.10 as well [2012-01-27 18:07:20] tyr...@php.net Description: first of all sorry for the weird Summary, I couldn't come up with a better one. it is weird. so it seems that if you have a shutdown function callback set and a custom error handler which would throw and exception and you happen to have a fatal error, the shutdown function won't be called. See the attached script, the error handler shouldn't really do anything here, because it won't be called for the fatals, but somehow it still screw things up. If I remove the error handler, I will see the "!!!shutdown!!!" printed. If I put a "return false;" before the throw I will see the "!!!shutdown!!!" printed. If I add E_NOTICE as the $error_type to the set_error_handler call I will see the "!!!shutdown!!!" printed. If I add E_WARNING as the $error_type to the set_error_handler call I will NOT see the "!!!shutdown!!!" printed. wtf? Test script: --- https://bugs.php.net/bug.php?id=60909&edit=1
Bug #61767 [Com]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Comment by: ni...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
This seems related: https://bugs.php.net/bug.php?id=60909
Previous Comments:
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #61774 [Opn->Fbk]: Public object variables with numbers as name are not public after unserialize
Edit report at https://bugs.php.net/bug.php?id=61774&edit=1 ID: 61774 Updated by: ni...@php.net Reported by:pandenitz at mail dot ru Summary:Public object variables with numbers as name are not public after unserialize -Status: Open +Status: Feedback Type: Bug Package:Class/Object related Operating System: Win 7 64x PHP Version:5.3.11RC2 Block user comment: N Private report: N New Comment: Actually, I just tried again with a more updated 5.3 build and it works fine there. The issue was fixed in http://svn.php.net/viewvc?view=revision&revision=317438 which shipped with PHP 5.3.9. Could you check a PHP 5.3 build >= 5.3.9 and see whether the issue persists? Previous Comments: [2012-04-19 22:38:40] ni...@php.net Can repro on PHP 5.3, but not on 5.4. Everything fine there. [2012-04-19 14:43:30] pandenitz at mail dot ru Description: Object variables with numbers as name are not public after unserialize. So i.e. get_object_vars() doesn't return this vars because they are not public Test script: --- $varname = 1; $a->test = 1; var_dump($a); print_r($a); echo ''; $s = serialize($a); $a2 = unserialize($s); var_dump($a2); print_r($a2); echo ''; var_dump(get_object_vars($a2)); print_r(get_object_vars($a2)); Expected result: Such vars should be public after unserialize. Actual result: -- Vars are not actually public. -- Edit this bug report at https://bugs.php.net/bug.php?id=61774&edit=1
Bug #61774 [Com]: Public object variables with numbers as name are not public after unserialize
Edit report at https://bugs.php.net/bug.php?id=61774&edit=1 ID: 61774 Comment by: ni...@php.net Reported by:pandenitz at mail dot ru Summary:Public object variables with numbers as name are not public after unserialize Status: Open Type: Bug Package:Class/Object related Operating System: Win 7 64x PHP Version:5.3.11RC2 Block user comment: N Private report: N New Comment: Can repro on PHP 5.3, but not on 5.4. Everything fine there. Previous Comments: [2012-04-19 14:43:30] pandenitz at mail dot ru Description: Object variables with numbers as name are not public after unserialize. So i.e. get_object_vars() doesn't return this vars because they are not public Test script: --- $varname = 1; $a->test = 1; var_dump($a); print_r($a); echo ''; $s = serialize($a); $a2 = unserialize($s); var_dump($a2); print_r($a2); echo ''; var_dump(get_object_vars($a2)); print_r(get_object_vars($a2)); Expected result: Such vars should be public after unserialize. Actual result: -- Vars are not actually public. -- Edit this bug report at https://bugs.php.net/bug.php?id=61774&edit=1
Bug #61776 [Opn->Nab]: $var = ''; var_dump(in_array($var, array(0,1)))// boolean true
Edit report at https://bugs.php.net/bug.php?id=61776&edit=1 ID: 61776 Updated by: fel...@php.net Reported by:aestur at me dot com Summary:$var = ''; var_dump(in_array($var, array(0,1)))// boolean true -Status: Open +Status: Not a bug Type: Bug Package:PHP options/info functions Operating System: windows PHP Version:5.3.10 Block user comment: N Private report: N 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 See the third argument of in_array() function. http://docs.php.net/in-array Previous Comments: [2012-04-19 18:00:23] aestur at me dot com the php version is 5.3.8 on windows seven [2012-04-19 17:59:20] aestur at me dot com Description: $var = ''; var_dump(in_array($var, array(0,1)))// boolean true Some weird cast is performed. Test script: --- $var = ''; var_dump(in_array($var, array(0,1))); Expected result: false Actual result: -- true -- Edit this bug report at https://bugs.php.net/bug.php?id=61776&edit=1
Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723&edit=1 ID: 60723 Comment by: tao dot li1 at renren-inc dot com Reported by:olemarkus at gentoo dot org Summary:error_log error time has changed to UTC ignoring default timezo Status: Assigned Type: Bug Package:Date/time related Operating System: Gentoo Linux PHP Version:5.3.9 Assigned To:derick Block user comment: N Private report: N New Comment: Is there any path? PHP 5.3.10 Previous Comments: [2012-04-12 14:16:18] reggie at busicast dot com Same: PHP 5.3.10 with Suhosin-Patch (cli) (built: Mar 14 2012 11:01:12) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator [2012-04-04 09:30:27] valinurovam at gmail dot com I have same problem php -v PHP 5.3.10 (cli) (built: Feb 4 2012 07:36:51) CentOS release 6.2 (Final) [2012-03-29 05:34:48] sevencat at gmail dot com Same. PHP 5.3.10 CentOS 5 [2012-03-23 13:02:03] ebert dot chris at gmail dot com Same problem for me on IIS 7, Windows 2008 Webserver, PHP 5.3.10 [2012-03-15 16:42:00] mitek17 at gmail dot com Same problem, php 5.3.9; FreeBSD 8.0 & 9.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 https://bugs.php.net/bug.php?id=60723 -- Edit this bug report at https://bugs.php.net/bug.php?id=60723&edit=1
Bug #61775 [Opn->Nab]: Preg_match does not support unicode.
Edit report at https://bugs.php.net/bug.php?id=61775&edit=1 ID: 61775 Updated by: cataphr...@php.net Reported by:asersz at gmail dot com Summary:Preg_match does not support unicode. -Status: Open +Status: Not a bug Type: Bug Package:PCRE related Operating System: MacOS Lion 10.7.2 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Your expression is wrong. Version 8.02 of PCRE, which you're using, gives that rather cryptic error, but more recent versions, including the one bundled with PHP say: Warning: preg_match(): Compilation failed: unrecognized character after (?P at offset 4 in - on line 3 Probably you want something like: \w+)\/(?P\d+)\/$/u'; var_dump(preg_match($r,'test/3423/',$m), $m); Previous Comments: [2012-04-19 17:07:44] asersz at gmail dot com Description: I am not good at english. A warning: preg_match(): Compilation failed: unknown option bit(s) set at offset 0 OS: MacOSX Lion 10.7.2 Web Server: apache 2 PHP : 5.4.0 PCRE (Perl Compatible Regular Expressions) Support: enabled PCRE Library Version: 8.02 2010-03-19 By the way: the php 5.4.0 released is stable or not ? thanks. Test script: --- https://bugs.php.net/bug.php?id=61775&edit=1
Bug #61773 [Opn->Nab]: each() are printing null characters for objects
Edit report at https://bugs.php.net/bug.php?id=61773&edit=1
ID: 61773
Updated by: johan...@php.net
Reported by:dread dot eklund at gmail dot com
Summary:each() are printing null characters for objects
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
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
using each() on objects is a legacy feature, the NULL-bytes are part of the
internal representation of private and protected elements.
Previous Comments:
[2012-04-19 13:05:41] dread dot eklund at gmail dot com
Description:
When using the each() function on objects, private and protected variables gets
a NUL character around them (see expected result).
Create the test script and view it in a browser (I used Firefox 11.0).
If you send an email with the output, the mail() function will just truncate
the message after the NUL character
Test script:
---
class Foo
{
public $a;
protected $b;
private $c;
function bar($value) {
echo $value;
}
}
$tmp = new Foo();
while(list($key, $value) = each($tmp)) {
var_dump($key);
}
Expected result:
string(1) "a"
string(4) "*b"
string(6) "Fooc"
Without the NUL character
Actual result:
--
string(1) "a"
string(4) "�*�b"
string(6) "�Foo�c"
� = NUL character, ASCII code (dec): 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=61773&edit=1
[PHP-BUG] Bug #61778 [NEW]: Crash when overloaded method called from class constructor
From:
Operating system: Windows 2003
PHP version: 5.4.0
Package: Reproducible crash
Bug Type: Bug
Bug description:Crash when overloaded method called from class constructor
Description:
If a class overrides a method but with a different signature and that
method is called in the constructor and if error_reporting is set to
display strict errors and if the classes are defined in reverse order, PHP
will crash. In my test script, if class one is defined before class two,
PHP won't crash. I realize that overridden methods need to have identical
signatures, but I would expect a warning and not a crash.
Test script:
---
error_reporting(-1);
class two extends one{
public function __construct(){
$this->error(7);
}
private function error($n){
echo 'two';
}
}
class one{
private function error(){
echo 'one';
}
}
new two;
Expected result:
two
Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.
Error Details:
The FastCGI process exited unexpectedly
Error Number: -2147467259 (0x80004005).
Error Description: Unspecified error
HTTP Error 500 - Server Error.
Internet Information Services (IIS)
--
Edit bug report at https://bugs.php.net/bug.php?id=61778&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61778&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61778&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61778&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61778&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61778&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61778&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61778&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61778&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61778&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61778&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61778&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61778&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61778&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61778&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61778&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61778&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61778&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61778&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61778&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61778&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61778&r=mysqlcfg
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: simon at stienen dot name
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
RAII is an elegant solution for tidying up scopes reliably.
It is also possible in PHP to do RAII without writing one class per resource
type:
callback = $callback;
}
function __destruct() {
if (is_callable($this->callback)) {
call_user_func($this->callback);
}
}
}
function do_something() {
mysql_query("LOCK TABLES mytable WRITE");
$guard = new ScopeGuard(function() {
mysql_query("UNLOCK TABLES");
});
try {
// ... do lots of queries here
}
}
?>
$guard will be destructed when leaving the do_something - either by throwing an
exception or by exiting the function normally.
HOWEVER: RAII in C++ (which neither employs nor needs a finally keyword) is
more subtle - or rather: Scopes are. In PHP you can define a variable within a
loop or a conditional block - and use it afterwards. In C++ you can't. A
variable defined inside a certain block will be destroyed once the block is
left. Consider the following example:
In C++, this would work as expected of a "finally" replacement and unlock the
tables at *1*, when the if scope closes. In PHP however, $guard will only be
destroyed when leaving the function at *2*. This can be fixed by manually
adding an unset($guard) at *1*, but this is inelegant and error prone.
So, while I have never needed finally, I think the way PHP works and is used
absolutely validates its introduction as a useful addition to the language. The
alternative would be to introduce C/++ style closed scopes, but those would
most likely not only break a lot of existing code, but the coders as well, as
they do not even remotely fit into the way PHP is written.
Previous Comments:
[2012-04-12 15:42:21] matthias at die-legendaeren dot de
"Just going to say 'Me too!'? Don't clutter the database with that please !"
But this is the right place for a "me too": to prove that a statement from 12
years ago was shortsighted and in a "works for me" way, developers (as
customers)
who disagree have to group behind their request.
[2012-04-11 21:21:33] gudjonj at gmail dot com
+1 for finally in PHP
[2012-04-11 08:34:13] ravilov at gmail dot com
My two cents...
Here's an example of emulating "finally" in PHP without needing to duplicate
code.
$_ex = null;
AllocateSomeResource();
try {
DoSomeProcessing();
} catch (Exception $ex) {
$_ex = $ex;
}
DeallocateSomeResource();
if ($_ex != null) {
throw $_ex;
}
That said, I completely agree any current workaround/emulation/"solution" is
nothing but cumbersome and bug-prone, and that we shouldn't have to come up
with such creative ways to overcome what seems like a language design flaw. PHP
is a tool, it is supposed to work *with* us, not *against* us.
[2012-04-03 13:08:00] andrew dot feller at gmail dot com
The demand for "finally" is a symptom of PHP not officially and explicitly
addressing supported solutions to managing resources. I cannot find anything
within PHP documentation to address this:
http://www.php.net/manual/en/language.oop5.decon.php
http://www.php.net/manual/en/faq.misc.php
So I recommend to move beyond inclusion of finalizers and start with educating
constituents because there is an opportunity to resolve this and hopefully
improve quality of work done by developers
[2012-01-02 12:02:49] frederic dot hardy at mageekbox dot net
I'm not sure that this place is the right place to discuss about that.
Since the last year, PHP has a process to discuss technical point, aka RFC
(https://wiki.php.net/rfc).
So, if "finally" must be included in PHP, just write the relative RFC and
discuss
it on internals.
Sure that time has changed, because PHP's users are more power now than in the
past !
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
[PHP-BUG] Bug #61777 [NEW]: Cannot bind parameters with pdo_odbc and SQL Server Native Client 11.0
From:
Operating system: Ubuntu 12.04
PHP version: 5.3.10
Package: PDO related
Bug Type: Bug
Bug description:Cannot bind parameters with pdo_odbc and SQL Server Native
Client 11.0
Description:
When trying to bind parameters to a prepared statement, bindValue() and
bindParam() both return false with the error code HY004, [SQL Server Native
Client
11.0]Invalid SQL data type (SQLBindParameter[0] at /build/buildd/php5-
5.3.10/ext/pdo_odbc/odbc_stmt.c:379)
It does not matter whether you pass in PDO::PARAM_STR or PARAM_INT or no
data type
specification, the error is the same every time.
Using parameters with odbc_connect() and odbc_prepare() work as expected,
so the
issue is directly related to PDO, not to ODBC or Microsoft's driver.
Test script:
---
$db = new PDO('odbc:sqltest', 'wwwuser', 'btsb');
$strSql = 'select top 10 * from oltmaster where titleno = :no';
$q = $db->prepare($strSql);
var_dump($q->bindValue(':no', '029803'));
var_dump($q->errorInfo());
Expected result:
boolean true
array
0 => string '' (length=0)
1 => int 0
2 => string ' ((null)[0] at (null):0)' (length=24)
3 => string '' (length=0)
Actual result:
--
boolean false
array
0 => string 'HY004' (length=5)
1 => int 0
2 => string '[Microsoft][SQL Server Native Client 11.0]Invalid SQL data
type
(SQLBindParameter[0] at
/build/buildd/php5-5.3.10/ext/pdo_odbc/odbc_stmt.c:379)'
(length=143)
3 => string 'HY004' (length=5)
--
Edit bug report at https://bugs.php.net/bug.php?id=61777&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61777&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61777&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61777&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61777&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61777&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61777&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61777&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61777&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61777&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61777&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61777&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61777&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61777&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61777&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61777&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61777&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61777&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61777&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61777&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61777&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61777&r=mysqlcfg
Bug #61776 [Com]: $var = ''; var_dump(in_array($var, array(0,1)))// boolean true
Edit report at https://bugs.php.net/bug.php?id=61776&edit=1 ID: 61776 Comment by: aestur at me dot com Reported by:aestur at me dot com Summary:$var = ''; var_dump(in_array($var, array(0,1)))// boolean true Status: Open Type: Bug Package:PHP options/info functions Operating System: windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: the php version is 5.3.8 on windows seven Previous Comments: [2012-04-19 17:59:20] aestur at me dot com Description: $var = ''; var_dump(in_array($var, array(0,1)))// boolean true Some weird cast is performed. Test script: --- $var = ''; var_dump(in_array($var, array(0,1))); Expected result: false Actual result: -- true -- Edit this bug report at https://bugs.php.net/bug.php?id=61776&edit=1
[PHP-BUG] Bug #61776 [NEW]: $var = ''; var_dump(in_array($var, array(0,1)))// boolean true
From: Operating system: windows PHP version: 5.3.10 Package: PHP options/info functions Bug Type: Bug Bug description:$var = ''; var_dump(in_array($var, array(0,1)))// boolean true Description: $var = ''; var_dump(in_array($var, array(0,1)))// boolean true Some weird cast is performed. Test script: --- $var = ''; var_dump(in_array($var, array(0,1))); Expected result: false Actual result: -- true -- Edit bug report at https://bugs.php.net/bug.php?id=61776&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61776&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61776&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61776&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61776&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61776&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61776&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61776&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61776&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61776&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61776&r=support Expected behavior: https://bugs.php.net/fix.php?id=61776&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61776&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61776&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61776&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61776&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61776&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61776&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61776&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61776&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61776&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61776&r=mysqlcfg
[PHP-BUG] Bug #61775 [NEW]: Preg_match does not support unicode.
From: Operating system: MacOS Lion 10.7.2 PHP version: 5.4.0 Package: PCRE related Bug Type: Bug Bug description:Preg_match does not support unicode. Description: I am not good at english. A warning: preg_match(): Compilation failed: unknown option bit(s) set at offset 0 OS: MacOSX Lion 10.7.2 Web Server: apache 2 PHP : 5.4.0 PCRE (Perl Compatible Regular Expressions) Support: enabled PCRE Library Version: 8.02 2010-03-19 By the way: the php 5.4.0 released is stable or not ? thanks. Test script: --- https://bugs.php.net/bug.php?id=61775&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61775&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61775&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61775&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61775&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61775&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61775&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61775&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61775&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61775&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61775&r=support Expected behavior: https://bugs.php.net/fix.php?id=61775&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61775&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61775&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61775&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61775&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61775&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61775&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61775&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61775&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61775&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61775&r=mysqlcfg
Bug #61463 [Com]: cant import schema when using https soapservice
Edit report at https://bugs.php.net/bug.php?id=61463&edit=1
ID: 61463
Comment by: benoit dot chenu at gmail dot com
Reported by:markus dot rietzler at rzf dot fin-nrw dot de
Summary:cant import schema when using https soapservice
Status: Open
Type: Bug
Package:SOAP related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I didn't test but the authentication problem seems to be solved in 5.4.0 :
"Fixed basic HTTP authentication for WSDL sub requests."
If it's the case, I hope it will also be done in the next 5.3.11 release.
In my case, I've "solved" the problem by commenting this lines in
ext/soap/php_schema.c (PHP 5.3.8) :
//sdl_set_uri_credentials(ctx, (char*)location TSRMLS_CC);
doc = soap_xmlParseFile((char*)location TSRMLS_CC);
//sdl_restore_uri_credentials(ctx TSRMLS_CC);
I suppose that the proxy and http auth problem are not linked.
Previous Comments:
[2012-04-19 15:41:39] benoit dot chenu at gmail dot com
Hi,
I solve the problem by disabling HTTP authentication. It seems that the soap
library doesn't use connexion options when requesting external ressources like
the xsd.
So it's simple to reproduce :
- Create an wsdl which call an xsd
- Call the wsdl in https with options (proxy or http authentication)
Ben
[2012-04-19 14:48:46] benoit dot chenu at gmail dot com
I have the same problem on PHP 5.3.8. The same code works on PHP 5.2.5 for me.
I don't use proxy but I use HTTP authentication, ex :
$client = new SoapClient(
'https://connect.example.com/portal/portal?wsdl',
array(
'login' => 'axis',
'password' => 'axis'
)
);
The wsdl import an xsd like this :
http://xxx/";
schemaLocation="https://connect.example.com:443/portal/portal?xsd=1"/>
This cause the same error :
Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing Schema: can't import
schema from 'https://connect.example.com:443/portal/portal?xsd=1'
[2012-03-29 08:24:05] markus dot rietzler at rzf dot fin-nrw dot de
nope, proxy_port makes no difference. i wonder whether it is ok to have a mix
of https and http in schema. maybe a misconfiguration of the service provider
for this soap service.
but: it has worked with php 5.3.3 and with 5.3.10 it don't work anymore
[2012-03-29 00:54:15] jingshangmingzi at gmail dot com
The proxy_port parameter has to be an integer.
I think you'll have to use 'proxy_port' => 8080
[2012-03-21 12:33:32] markus dot rietzler at rzf dot fin-nrw dot de
Description:
here is my problem: i want to access a soap-service via
https://connect.example.com/portal/portal?wsdl
with php 5.3.3 my script worked, with 5.3.10 it does not work anymore.
in the xml returned:
http://connect.example.com:80/portal/portal"/>
so there is a http and not a https location. is this wrong?
i am not sure, whether this should work in general (using https but with a
http-location). we use a soapservice from an extern service provider which
requires us to use https for the calls.
in my php script i used
$client = new SoapClient('https://connect.example.com/portal/portal?wsdl',
array( 'proxy_host' => 'myproxy',
'proxy_port' => '8080',
'trace' => 1,
'exceptions' => 1,
// actual use https-endpoint
'location' => 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
with php 5.3.3 i could create the soapclient and do my requests. the wsdl is
downloaded and cached in /tmp. with php 5.3.10 i get:
PHP Fatal error: SOAP-ERROR: Parsing Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9
so the schema could not be downloaded!
what's wrong here? was it a bug in 5.3.3 - and it should not have worked there
- or is it a bug in 5.3.10 (same for 5.3.8).
if i used php 5.3.3 to access the service, a wsdl is cached in /tmp and then i
can call the script with php 5.3.10.
Test script:
---
https://connect.example.com/portal/portal?wsdl',
array( 'proxy_host' => 'myproxy',
'proxy_port' => '8080',
'trace' => 1,
'exceptions' => 1,
// actual use https-endpoint
'location' => 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
Bug #61463 [Com]: cant import schema when using https soapservice
Edit report at https://bugs.php.net/bug.php?id=61463&edit=1
ID: 61463
Comment by: benoit dot chenu at gmail dot com
Reported by:markus dot rietzler at rzf dot fin-nrw dot de
Summary:cant import schema when using https soapservice
Status: Open
Type: Bug
Package:SOAP related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Hi,
I solve the problem by disabling HTTP authentication. It seems that the soap
library doesn't use connexion options when requesting external ressources like
the xsd.
So it's simple to reproduce :
- Create an wsdl which call an xsd
- Call the wsdl in https with options (proxy or http authentication)
Ben
Previous Comments:
[2012-04-19 14:48:46] benoit dot chenu at gmail dot com
I have the same problem on PHP 5.3.8. The same code works on PHP 5.2.5 for me.
I don't use proxy but I use HTTP authentication, ex :
$client = new SoapClient(
'https://connect.example.com/portal/portal?wsdl',
array(
'login' => 'axis',
'password' => 'axis'
)
);
The wsdl import an xsd like this :
http://xxx/";
schemaLocation="https://connect.example.com:443/portal/portal?xsd=1"/>
This cause the same error :
Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing Schema: can't import
schema from 'https://connect.example.com:443/portal/portal?xsd=1'
[2012-03-29 08:24:05] markus dot rietzler at rzf dot fin-nrw dot de
nope, proxy_port makes no difference. i wonder whether it is ok to have a mix
of https and http in schema. maybe a misconfiguration of the service provider
for this soap service.
but: it has worked with php 5.3.3 and with 5.3.10 it don't work anymore
[2012-03-29 00:54:15] jingshangmingzi at gmail dot com
The proxy_port parameter has to be an integer.
I think you'll have to use 'proxy_port' => 8080
[2012-03-21 12:33:32] markus dot rietzler at rzf dot fin-nrw dot de
Description:
here is my problem: i want to access a soap-service via
https://connect.example.com/portal/portal?wsdl
with php 5.3.3 my script worked, with 5.3.10 it does not work anymore.
in the xml returned:
http://connect.example.com:80/portal/portal"/>
so there is a http and not a https location. is this wrong?
i am not sure, whether this should work in general (using https but with a
http-location). we use a soapservice from an extern service provider which
requires us to use https for the calls.
in my php script i used
$client = new SoapClient('https://connect.example.com/portal/portal?wsdl',
array( 'proxy_host' => 'myproxy',
'proxy_port' => '8080',
'trace' => 1,
'exceptions' => 1,
// actual use https-endpoint
'location' => 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
with php 5.3.3 i could create the soapclient and do my requests. the wsdl is
downloaded and cached in /tmp. with php 5.3.10 i get:
PHP Fatal error: SOAP-ERROR: Parsing Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9
so the schema could not be downloaded!
what's wrong here? was it a bug in 5.3.3 - and it should not have worked there
- or is it a bug in 5.3.10 (same for 5.3.8).
if i used php 5.3.3 to access the service, a wsdl is cached in /tmp and then i
can call the script with php 5.3.10.
Test script:
---
https://connect.example.com/portal/portal?wsdl',
array( 'proxy_host' => 'myproxy',
'proxy_port' => '8080',
'trace' => 1,
'exceptions' => 1,
// actual use https-endpoint
'location' => 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
print_r($client);
?>
Expected result:
SoapClient Object
(
[_proxy_host] => myproxy
[_proxy_port] => 8080
[trace] => 1
[_soap_version] => 1
[sdl] => Resource id #9
)
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9
--
Edit this bug report at ht
Bug #61769 [Com]: Random failure of php_cli_server*phpt tests
Edit report at https://bugs.php.net/bug.php?id=61769&edit=1 ID: 61769 Comment by: a...@php.net Reported by:mattfic...@php.net Summary:Random failure of php_cli_server*phpt tests Status: Open Type: Bug Package:Built-in web server PHP Version:5.4.0 Block user comment: N Private report: N New Comment: just came into my mind - may be it would have an effect if we just set a timeout at the top of the php_cli_server_start() too? so the previous server had a chance to exit ... Previous Comments: [2012-04-19 14:34:18] a...@php.net Matt, unfortunately I can't reproduce the fails on my laptops, they're probably too slow. Nevertheless I'm not sure the patch does expected things. I've just debugged on win7 and ubuntu - SO_REUSEADDR is defined everywhere. MSDN even says it's available on all the versions. This means setsockopt should work as expected. Besides that, removing that wrapping #ifdef could have impacts in some rare cases, i think, as SO_REUSEADDR is marked as a BSD macro, so despite it's luckily present on GNU, it might be absent on some POSIX-complaint only systems. Could you please explain why this fix is correct? Also the php_cli_server_017.phpt was still failing for me, but that's just the unix/windows dir separator. [2012-04-19 14:15:26] a...@php.net The following patch has been added/updated: Patch Name: php_cli_server_017.diff Revision: 1334844926 URL: https://bugs.php.net/patch-display.php?bug=61769&patch=php_cli_server_017.diff&revision=1334844926 [2012-04-18 21:21:00] mattfic...@php.net Description: All the php_cli_server* tests randomly fail. Each test starts and stops the builtin web server. The web server when restarted quickly, can't listen on the given port because its locked by the OS. The SO_REUSEADDR option needs to be set on the web server's socket. Test script: --- 007+ string(82) "C:\php-sdk\php-test-pack-5.4-nts-windows-vc9-x86-re7a36ad\Sapi\cli\tests\index.php" 007- string(%d) "%s/tests/index.php" -- Edit this bug report at https://bugs.php.net/bug.php?id=61769&edit=1
Bug #61463 [Com]: cant import schema when using https soapservice
Edit report at https://bugs.php.net/bug.php?id=61463&edit=1
ID: 61463
Comment by: benoit dot chenu at gmail dot com
Reported by:markus dot rietzler at rzf dot fin-nrw dot de
Summary:cant import schema when using https soapservice
Status: Open
Type: Bug
Package:SOAP related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I have the same problem on PHP 5.3.8. The same code works on PHP 5.2.5 for me.
I don't use proxy but I use HTTP authentication, ex :
$client = new SoapClient(
'https://connect.example.com/portal/portal?wsdl',
array(
'login' => 'axis',
'password' => 'axis'
)
);
The wsdl import an xsd like this :
http://xxx/";
schemaLocation="https://connect.example.com:443/portal/portal?xsd=1"/>
This cause the same error :
Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing Schema: can't import
schema from 'https://connect.example.com:443/portal/portal?xsd=1'
Previous Comments:
[2012-03-29 08:24:05] markus dot rietzler at rzf dot fin-nrw dot de
nope, proxy_port makes no difference. i wonder whether it is ok to have a mix
of https and http in schema. maybe a misconfiguration of the service provider
for this soap service.
but: it has worked with php 5.3.3 and with 5.3.10 it don't work anymore
[2012-03-29 00:54:15] jingshangmingzi at gmail dot com
The proxy_port parameter has to be an integer.
I think you'll have to use 'proxy_port' => 8080
[2012-03-21 12:33:32] markus dot rietzler at rzf dot fin-nrw dot de
Description:
here is my problem: i want to access a soap-service via
https://connect.example.com/portal/portal?wsdl
with php 5.3.3 my script worked, with 5.3.10 it does not work anymore.
in the xml returned:
http://connect.example.com:80/portal/portal"/>
so there is a http and not a https location. is this wrong?
i am not sure, whether this should work in general (using https but with a
http-location). we use a soapservice from an extern service provider which
requires us to use https for the calls.
in my php script i used
$client = new SoapClient('https://connect.example.com/portal/portal?wsdl',
array( 'proxy_host' => 'myproxy',
'proxy_port' => '8080',
'trace' => 1,
'exceptions' => 1,
// actual use https-endpoint
'location' => 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
with php 5.3.3 i could create the soapclient and do my requests. the wsdl is
downloaded and cached in /tmp. with php 5.3.10 i get:
PHP Fatal error: SOAP-ERROR: Parsing Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9
so the schema could not be downloaded!
what's wrong here? was it a bug in 5.3.3 - and it should not have worked there
- or is it a bug in 5.3.10 (same for 5.3.8).
if i used php 5.3.3 to access the service, a wsdl is cached in /tmp and then i
can call the script with php 5.3.10.
Test script:
---
https://connect.example.com/portal/portal?wsdl',
array( 'proxy_host' => 'myproxy',
'proxy_port' => '8080',
'trace' => 1,
'exceptions' => 1,
// actual use https-endpoint
'location' => 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
print_r($client);
?>
Expected result:
SoapClient Object
(
[_proxy_host] => myproxy
[_proxy_port] => 8080
[trace] => 1
[_soap_version] => 1
[sdl] => Resource id #9
)
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: can't import schema from
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9
--
Edit this bug report at https://bugs.php.net/bug.php?id=61463&edit=1
[PHP-BUG] Bug #61774 [NEW]: Public object variables with numbers as name are not public after unserialize
From: Operating system: Win 7 64x PHP version: 5.3.11RC2 Package: Class/Object related Bug Type: Bug Bug description:Public object variables with numbers as name are not public after unserialize Description: Object variables with numbers as name are not public after unserialize. So i.e. get_object_vars() doesn't return this vars because they are not public Test script: --- $varname = 1; $a->test = 1; var_dump($a); print_r($a); echo ''; $s = serialize($a); $a2 = unserialize($s); var_dump($a2); print_r($a2); echo ''; var_dump(get_object_vars($a2)); print_r(get_object_vars($a2)); Expected result: Such vars should be public after unserialize. Actual result: -- Vars are not actually public. -- Edit bug report at https://bugs.php.net/bug.php?id=61774&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61774&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61774&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61774&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61774&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61774&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61774&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61774&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61774&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61774&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61774&r=support Expected behavior: https://bugs.php.net/fix.php?id=61774&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61774&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61774&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61774&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61774&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61774&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61774&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61774&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61774&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61774&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61774&r=mysqlcfg
Bug #61769 [Com]: Random failure of php_cli_server*phpt tests
Edit report at https://bugs.php.net/bug.php?id=61769&edit=1 ID: 61769 Comment by: a...@php.net Reported by:mattfic...@php.net Summary:Random failure of php_cli_server*phpt tests Status: Open Type: Bug Package:Built-in web server PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Matt, unfortunately I can't reproduce the fails on my laptops, they're probably too slow. Nevertheless I'm not sure the patch does expected things. I've just debugged on win7 and ubuntu - SO_REUSEADDR is defined everywhere. MSDN even says it's available on all the versions. This means setsockopt should work as expected. Besides that, removing that wrapping #ifdef could have impacts in some rare cases, i think, as SO_REUSEADDR is marked as a BSD macro, so despite it's luckily present on GNU, it might be absent on some POSIX-complaint only systems. Could you please explain why this fix is correct? Also the php_cli_server_017.phpt was still failing for me, but that's just the unix/windows dir separator. Previous Comments: [2012-04-19 14:15:26] a...@php.net The following patch has been added/updated: Patch Name: php_cli_server_017.diff Revision: 1334844926 URL: https://bugs.php.net/patch-display.php?bug=61769&patch=php_cli_server_017.diff&revision=1334844926 [2012-04-18 21:21:00] mattfic...@php.net Description: All the php_cli_server* tests randomly fail. Each test starts and stops the builtin web server. The web server when restarted quickly, can't listen on the given port because its locked by the OS. The SO_REUSEADDR option needs to be set on the web server's socket. Test script: --- 007+ string(82) "C:\php-sdk\php-test-pack-5.4-nts-windows-vc9-x86-re7a36ad\Sapi\cli\tests\index.php" 007- string(%d) "%s/tests/index.php" -- Edit this bug report at https://bugs.php.net/bug.php?id=61769&edit=1
Bug #61769 [PATCH]: Random failure of php_cli_server*phpt tests
Edit report at https://bugs.php.net/bug.php?id=61769&edit=1 ID: 61769 Patch added by: a...@php.net Reported by:mattfic...@php.net Summary:Random failure of php_cli_server*phpt tests Status: Open Type: Bug Package:Built-in web server PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php_cli_server_017.diff Revision: 1334844926 URL: https://bugs.php.net/patch-display.php?bug=61769&patch=php_cli_server_017.diff&revision=1334844926 Previous Comments: [2012-04-18 21:21:00] mattfic...@php.net Description: All the php_cli_server* tests randomly fail. Each test starts and stops the builtin web server. The web server when restarted quickly, can't listen on the given port because its locked by the OS. The SO_REUSEADDR option needs to be set on the web server's socket. Test script: --- 007+ string(82) "C:\php-sdk\php-test-pack-5.4-nts-windows-vc9-x86-re7a36ad\Sapi\cli\tests\index.php" 007- string(%d) "%s/tests/index.php" -- Edit this bug report at https://bugs.php.net/bug.php?id=61769&edit=1
[PHP-BUG] Bug #61773 [NEW]: each() are printing null characters for objects
From:
Operating system: Linux
PHP version: Irrelevant
Package: Arrays related
Bug Type: Bug
Bug description:each() are printing null characters for objects
Description:
When using the each() function on objects, private and protected variables
gets a NUL character around them (see expected result).
Create the test script and view it in a browser (I used Firefox 11.0).
If you send an email with the output, the mail() function will just
truncate the message after the NUL character
Test script:
---
class Foo
{
public $a;
protected $b;
private $c;
function bar($value) {
echo $value;
}
}
$tmp = new Foo();
while(list($key, $value) = each($tmp)) {
var_dump($key);
}
Expected result:
string(1) "a"
string(4) "*b"
string(6) "Fooc"
Without the NUL character
Actual result:
--
string(1) "a"
string(4) "�*�b"
string(6) "�Foo�c"
� = NUL character, ASCII code (dec): 0
--
Edit bug report at https://bugs.php.net/bug.php?id=61773&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61773&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61773&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61773&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61773&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61773&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61773&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61773&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61773&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61773&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61773&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61773&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61773&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61773&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61773&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61773&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61773&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61773&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61773&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61773&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61773&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61773&r=mysqlcfg
Sec Bug->Bug #61755 [Opn->Csd]: A parsing bug in the prepared statements can lead to access violations
Edit report at https://bugs.php.net/bug.php?id=61755&edit=1
ID: 61755
Updated by: johan...@php.net
Reported by:noamr at beyondsecurity dot com
Summary:A parsing bug in the prepared statements can lead to
access violations
-Status: Open
+Status: Closed
-Type: Security
+Type: Bug
Package:PDO related
Operating System: Windows and Linux
PHP Version:5.4.0
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: Y
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-04-19 09:22:29] johan...@php.net
The following patch has been added/updated:
Patch Name: bug61755.diff
Revision: 1334827349
URL:
https://bugs.php.net/patch-display.php?bug=61755&patch=bug61755.diff&revision=1334827349
[2012-04-17 13:39:31] noamr at beyondsecurity dot com
Description:
Inconsistent parsing of PHP PDO prepared statements. Erroneous design of
parsers
state machine. Under special circumstances parsing of prepared statements does
not stop leading in cycling the whole stack without terminating on \0. This
leads to access violations, accessing of stack data, DoS.
Bug Description
There are several design errors in the state-machine responsible for parsing
PHP
PDO based statement objects. These errors are based on the state-machines
inability to consistently check the supplied SQL-Query. Under special
circumstances an attacker is able to force the responsible PDO code to iterate
beyond the termination of the supplied query string resulting in a buffer out
of
bounds access. This access may lead to uncontrollable as well as attacker
controllable behavior and Access Violations caused by the code iterating the
whole stack and trying to access addresses beyond the stack end.
Preconditions
* PDO is used to access the DB
* For remote attacks: User must be able to directly control any part of the
query string prior its preparation (stm->prepare()). We are well aware that
this
is a general coding fault which leads to other security relevant implications
but sadly enough itâs also quite common in many frameworks, projects to use
prepared statements with user controlled data instead of binding them after
preparation.
* Mysql_real_escape() is no mitigation for this vulnerability. (As stated
above,
there are indeed many projects using user controlled data encoded by
mysql_real_escape() like this: $argName=mysql_real_escape($_GET[âNameâ]);
$db-
>prepare(âSELECT * from âuserâ where âusernameâ=â$argNameâ;
>â).execute();
Test script:
---
(We have several samples, these are some of them)
This poc directly prepares the statements query passed to the script via GET
Request argument âqueryâ.
Examples: poc_pdo_short_get.php?query=/* poc_pdo_short_get.php?query=--:
prepare("SELECT * from
'user'".mysql_real_escape_string($_GET['query']));
$stmt->execute();
//crash
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
print_r( $type);
}
catch (Exception $e)
{
echo "Failed: " . $e->getMessage();
}
?>
prepare($sql);
$stmt->execute(); // crashes php worker in pdo_parse_params()
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
print_r( $type);
} catch (Exception $e) {
echo "Failed: " . $e->getMessage();
}
?>
prepare($sql);
echo "prepared :)\n";
print_r($stmt);
$stmt->execute(); // crashes php worker in pdo_parse_params()
print_r($stmt);
echo "executed :(\n";
$stmt->bindColumn(2, $type, PDO::PARAM_STR, 256);
$stmt->fetch(PDO::FETCH_BOUND);
echo "--data-\n";
print_r( $type);
echo "--data--\n";
} catch (Exception $e) {
echo "EXCEPTION";
echo "Failed: " . $e->getMessage();
}
echo "hmmm end\n";
?>
Actual result:
--
root@bt:/opt/lampp# gdb ./bin/php
(gdb) run poc_pdo_linux_short_1.php
Starting program: /opt/lampp/bin/php /opt/lampp/poc_pdo_linux_short_1.php
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x08228a81 in ?? ()
(gdb) bt
#0 0x08228a81 in ?? ()
#1 0x082280eb in pdo_parse_params ()
#2 0x08223891 in ?? ()
#3 0x084b2aad in ?? ()
#4 0x084b1f87 in execute ()
#5 0x08490ed2 in zend_execute_scripts ()
#6 0x0843f13c in php_execute_script ()
#7 0x08506b46 in main ()
--
Edit this bug report at https://bugs.php.net/bug.p
Bug #61766 [Fbk->Opn]: call_user_func sends scrambled class name to autoload
Edit report at https://bugs.php.net/bug.php?id=61766&edit=1
ID: 61766
User updated by:admin dot windows at gmail dot com
Reported by:admin dot windows at gmail dot com
Summary:call_user_func sends scrambled class name to
autoload
-Status: Feedback
+Status: Open
Type: Bug
Package:*General Issues
Operating System: ALL
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Unfortunately I don't have rights to enable or disable modules on my cloud, I
would pass this issue to my hosting support.
Also I noticed that server is protected with the Suhosin Patch 0.9.10 can it
cause
this behavior?
Previous Comments:
[2012-04-19 09:21:26] johan...@php.net
Please disable ionCube Loader, Zend Guard Loader and XCache as all of these 3rd
party modules change the engine's behaviour.
[2012-04-19 09:06:56] admin dot windows at gmail dot com
Hi,
I have following extensions enabled on my hosting (Rackspace):
Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype,
hash, filter, ftp, gettext, gmp, SPL, iconv, Reflection, session, standard,
shmop, SimpleXML, sockets, exif, tokenizer, xml, apache2handler, bcmath, curl,
dba, dom, fileinfo, gd, imagick, imap, intl, json, ldap, pdf, mbstring, mcrypt,
memcache, mongo, mssql, mysql, mysqli, odbc, PDO, pdo_dblib, pdo_mysql,
PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, recode, redis,
snmp, soap, sysvmsg, sysvsem, sysvshm, tidy, uploadprogress, wddx, xmlreader,
xmlrpc, xmlwriter, xsl, yaz, zip, ionCube Loader, Zend Guard Loader, XCache
[2012-04-19 07:07:33] ahar...@php.net
I can't reproduce this.
What extensions do you have enabled?
[2012-04-18 15:19:23] admin dot windows at gmail dot com
Description:
I have discovered weird behaviour of call_user_func that breaks class
autoloader by providing scrambled class name for example instead of "myObject"
it provides "zw87zl18".
This event only occurs if you are using custom class autoloader and requesting
static method that is not declared as static.
Test script:
---
//FILE: myObject.php
class myObject {
public static function method1(){var_dump(__METHOD__);}
public function method2(){var_dump(__METHOD__);}
}
//FILE: index.php
ini_set('display_errors', TRUE);
function __autoload($className) {
include sprintf('%s/%s.php', getcwd(), $className);
}
call_user_func(array('myObject', 'method1'));//works fine
call_user_func(array('myObject', 'method2'));//produce an error
Expected result:
string(17) "myObject::method1"
string(17) "myObject::method2"
Actual result:
--
string(17) "myObject::method1"
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
string(17) "myObject::method2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61766&edit=1
Bug #61671 [Opn->Csd]: ext\spl\tests\fileobject_003.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61671&edit=1
ID: 61671
Updated by: a...@php.net
Reported by:a...@php.net
Summary:ext\spl\tests\fileobject_003.phpt fails
-Status: Open
+Status: Closed
Type: Bug
Package:SPL related
Operating System: Windows
PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-04-18 21:30:54] mattfic...@php.net
The patch fixes the bug for me on Windows and Linux on PHP-5.3-rf3d86b3.
[2012-04-18 14:07:55] a...@php.net
The solution was already introduced in 5.4 by Etienne Kneuss but wasn't merged
back into 5.3 . SplFileObject should not be used with directories. The patch is
just putting together all the necessary pieces from 5.4
[2012-04-18 14:05:06] a...@php.net
The following patch has been added/updated:
Patch Name: 61671.diff
Revision: 1334757906
URL:
https://bugs.php.net/patch-display.php?bug=61671&patch=61671.diff&revision=1334757906
[2012-04-17 10:06:34] a...@php.net
A simple reproduce case for this:
C:\php-sdk\php53\vc9\x86\php-src>Debug_TS\php -r "$o = new
SplFileObject('C:\\php-sdk\\');"
Fatal error: Uncaught exception 'RuntimeException' with message
'SplFileObject::__construct(C:\php-sdk\): failed to open stream: No such file or
directory' in Command line code:1
Stack trace:
#0 Command line code(1): SplFileObject->__construct('C:\php-sdk\')
#1 {main}
thrown in Command line code on line 1
[2012-04-08 11:49:30] a...@php.net
On windows SplFileObject doesn't work as expected with directories,
because the functionality of php_stream_open_wrapper_ex can't open
dir streams on windows. Fixing this may have long range consequences
but would be rather correct instead of just fixing the test behaviour.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61671
--
Edit this bug report at https://bugs.php.net/bug.php?id=61671&edit=1
Bug #61766 [Opn->Fbk]: call_user_func sends scrambled class name to autoload
Edit report at https://bugs.php.net/bug.php?id=61766&edit=1
ID: 61766
Updated by: johan...@php.net
Reported by:admin dot windows at gmail dot com
Summary:call_user_func sends scrambled class name to
autoload
-Status: Open
+Status: Feedback
Type: Bug
Package:*General Issues
Operating System: ALL
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Please disable ionCube Loader, Zend Guard Loader and XCache as all of these 3rd
party modules change the engine's behaviour.
Previous Comments:
[2012-04-19 09:06:56] admin dot windows at gmail dot com
Hi,
I have following extensions enabled on my hosting (Rackspace):
Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype,
hash, filter, ftp, gettext, gmp, SPL, iconv, Reflection, session, standard,
shmop, SimpleXML, sockets, exif, tokenizer, xml, apache2handler, bcmath, curl,
dba, dom, fileinfo, gd, imagick, imap, intl, json, ldap, pdf, mbstring, mcrypt,
memcache, mongo, mssql, mysql, mysqli, odbc, PDO, pdo_dblib, pdo_mysql,
PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, recode, redis,
snmp, soap, sysvmsg, sysvsem, sysvshm, tidy, uploadprogress, wddx, xmlreader,
xmlrpc, xmlwriter, xsl, yaz, zip, ionCube Loader, Zend Guard Loader, XCache
[2012-04-19 07:07:33] ahar...@php.net
I can't reproduce this.
What extensions do you have enabled?
[2012-04-18 15:19:23] admin dot windows at gmail dot com
Description:
I have discovered weird behaviour of call_user_func that breaks class
autoloader by providing scrambled class name for example instead of "myObject"
it provides "zw87zl18".
This event only occurs if you are using custom class autoloader and requesting
static method that is not declared as static.
Test script:
---
//FILE: myObject.php
class myObject {
public static function method1(){var_dump(__METHOD__);}
public function method2(){var_dump(__METHOD__);}
}
//FILE: index.php
ini_set('display_errors', TRUE);
function __autoload($className) {
include sprintf('%s/%s.php', getcwd(), $className);
}
call_user_func(array('myObject', 'method1'));//works fine
call_user_func(array('myObject', 'method2'));//produce an error
Expected result:
string(17) "myObject::method1"
string(17) "myObject::method2"
Actual result:
--
string(17) "myObject::method1"
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
string(17) "myObject::method2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61766&edit=1
Bug #61767 [Opn]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
User updated by:shiranai7 at hotmail dot com
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
Previous Comments:
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #61766 [Fbk->Opn]: call_user_func sends scrambled class name to autoload
Edit report at https://bugs.php.net/bug.php?id=61766&edit=1
ID: 61766
User updated by:admin dot windows at gmail dot com
Reported by:admin dot windows at gmail dot com
Summary:call_user_func sends scrambled class name to
autoload
-Status: Feedback
+Status: Open
Type: Bug
Package:*General Issues
Operating System: ALL
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Hi,
I have following extensions enabled on my hosting (Rackspace):
Core, date, ereg, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype,
hash, filter, ftp, gettext, gmp, SPL, iconv, Reflection, session, standard,
shmop, SimpleXML, sockets, exif, tokenizer, xml, apache2handler, bcmath, curl,
dba, dom, fileinfo, gd, imagick, imap, intl, json, ldap, pdf, mbstring, mcrypt,
memcache, mongo, mssql, mysql, mysqli, odbc, PDO, pdo_dblib, pdo_mysql,
PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, recode, redis,
snmp, soap, sysvmsg, sysvsem, sysvshm, tidy, uploadprogress, wddx, xmlreader,
xmlrpc, xmlwriter, xsl, yaz, zip, ionCube Loader, Zend Guard Loader, XCache
Previous Comments:
[2012-04-19 07:07:33] ahar...@php.net
I can't reproduce this.
What extensions do you have enabled?
[2012-04-18 15:19:23] admin dot windows at gmail dot com
Description:
I have discovered weird behaviour of call_user_func that breaks class
autoloader by providing scrambled class name for example instead of "myObject"
it provides "zw87zl18".
This event only occurs if you are using custom class autoloader and requesting
static method that is not declared as static.
Test script:
---
//FILE: myObject.php
class myObject {
public static function method1(){var_dump(__METHOD__);}
public function method2(){var_dump(__METHOD__);}
}
//FILE: index.php
ini_set('display_errors', TRUE);
function __autoload($className) {
include sprintf('%s/%s.php', getcwd(), $className);
}
call_user_func(array('myObject', 'method1'));//works fine
call_user_func(array('myObject', 'method2'));//produce an error
Expected result:
string(17) "myObject::method1"
string(17) "myObject::method2"
Actual result:
--
string(17) "myObject::method1"
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
string(17) "myObject::method2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61766&edit=1
Bug #61665 [Fbk->Opn]: include on stream wrapper results in wsod
Edit report at https://bugs.php.net/bug.php?id=61665&edit=1 ID: 61665 User updated by:btmash at gmail dot com Reported by:btmash at gmail dot com Summary:include on stream wrapper results in wsod -Status: Feedback +Status: Open Type: Bug Package:Streams related Operating System: Ubuntu 10.04 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I'm setting it back to open since I've provided feedback. Previous Comments: [2012-04-09 23:29:13] btmash at gmail dot com I've pasted a version of the class at http://paste.pocoo.org/show/578721/ since it is longer than 20 lines. Please note that a large chunk of this is the drupal stream wrapper interface and at the bottom is the stream class that I implemented 'MyLocalStreamWrapper' which returns back the directory it is currently in. I perform an include to a info.php file which consists of: " http://drupal.org/project/configuration) that provided its own contributed stream wrapper to find the local configuration directory (so it was in the format 'config://path/to/file' - the implementation can be seen at http://drupalcode.org/project/configuration.git/blob/refs/heads/7.x-1.x:/configuration_stream.inc). On my local environment of running the site with the module (which runs php 5.3.6), the configuration would be able to scan on files with the protocol without any issues. However, once I moved to my staging environment which runs php 5.3.10, I would end up with a wsod. The strange part was that the page returned a code 200 and nothing in the error log. I made sure that allow_url_fopen was enabled and the protocols actually registered so it should have worked correctly. Moreover, using file_exists and is_file work to ensure the file exists so that meant the file was being found the first time around. For now, my workaround has been to use drupal's functions to get the stream converted correctly (see http://drupal.org/files/config-stream.patch as my workaround for the module to work) but problem seems to stem from PHP which is why I am filing my issue here. Any help that can be provided would be greatly appreciated. Test script: --- Implement a simple stream wrapper to a file in local (lets call it local). Create a php file to include from somewhere (called test_include.inc). Have the line 'include local://path/to/test_include.inc'. Expected result: It should result in a code 200 but also a wsod. Actual result: -- The script should be correctly included. -- Edit this bug report at https://bugs.php.net/bug.php?id=61665&edit=1
Bug #61766 [Opn->Fbk]: call_user_func sends scrambled class name to autoload
Edit report at https://bugs.php.net/bug.php?id=61766&edit=1
ID: 61766
Updated by: ahar...@php.net
Reported by:admin dot windows at gmail dot com
Summary:call_user_func sends scrambled class name to
autoload
-Status: Open
+Status: Feedback
Type: Bug
Package:*General Issues
Operating System: ALL
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I can't reproduce this.
What extensions do you have enabled?
Previous Comments:
[2012-04-18 15:19:23] admin dot windows at gmail dot com
Description:
I have discovered weird behaviour of call_user_func that breaks class
autoloader by providing scrambled class name for example instead of "myObject"
it provides "zw87zl18".
This event only occurs if you are using custom class autoloader and requesting
static method that is not declared as static.
Test script:
---
//FILE: myObject.php
class myObject {
public static function method1(){var_dump(__METHOD__);}
public function method2(){var_dump(__METHOD__);}
}
//FILE: index.php
ini_set('display_errors', TRUE);
function __autoload($className) {
include sprintf('%s/%s.php', getcwd(), $className);
}
call_user_func(array('myObject', 'method1'));//works fine
call_user_func(array('myObject', 'method2'));//produce an error
Expected result:
string(17) "myObject::method1"
string(17) "myObject::method2"
Actual result:
--
string(17) "myObject::method1"
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
Warning: include(/www/zw87zl18.php) [function.include]: failed to open stream:
No such file or directory in /www/index.php on line 9
Warning: include() [function.include]: Failed opening '/www/zw87zl18.php' for
inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /www/index.php
on line 9
string(17) "myObject::method2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61766&edit=1
