Bug #62457 [Opn]: Excuse me, is this a bug?
Edit report at https://bugs.php.net/bug.php?id=62457&edit=1
ID: 62457
User updated by:mybugs at 163 dot com
Reported by:mybugs at 163 dot com
Summary:Excuse me, is this a bug?
Status: Open
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Microsoft Windows Server 2003 R2
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
php.ini
disable_functions =system
[PATH= "D:/Web/test.com/public"]
open_basedir
Previous Comments:
[2012-07-01 06:42:05] mybugs at 163 dot com
Description:
php.ini
[PATH= "D:/Web/test.com/public"]
open_basedir="D:/Web/test.com/public/"
Test script:
---
'; //D:\WEB\TEST_COM\
$cmd = 'ping qq.com';
echo execute('system',$cmd);
echo execute('passthru',$cmd);
echo execute('shell_exec',$cmd);
echo execute('exec',$cmd);
echo execute('popen',$cmd);
function execute($type,$cfe) {
$data = '';
if ($cfe) {
if($type=='system') {
@ob_start();
@system($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='passthru') {
@ob_start();
@passthru($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='shell_exec') {
$data = @shell_exec($cfe);
} elseif($type=='exec') {
@exec($cfe,$data);
$data = join("\n",$data);
} elseif($type=='popen') {
$f = @popen($cfe,"r");
while(!@feof($f)) {
$data .= @fread($f,1024);
}
@pclose($f);
}
}
return $type.'--'.$data.''.$type.'--';
}
?>
Expected result:
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
Pinging qq.com [119.147.15.13] with 32 bytes of data: Reply from 119.147.15.13:
bytes=32 time=11ms TTL=56 Reply from 119.147.15.13: bytes=32 time=11ms TTL=56
Reply from 119.147.15.13: bytes=32 time=11ms TTL=56 Reply from 119.147.15.13:
bytes=32 time=11ms TTL=56 Ping statistics for 119.147.15.13: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 11ms, Maximum = 11ms, Average = 11ms
passthru--
shell_exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
shell_exec--
exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
exec--
popen--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
popen--
Actual result:
--
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
passthru--
shell_exec--
shell_exec--
exec--
exec--
popen--
popen--
--
Edit this bug report at https://bugs.php.net/bug.php?id=62457&edit=1
[PHP-BUG] Bug #62457 [NEW]: Excuse me, is this a bug?
From: mybugs at 163 dot com
Operating system: Microsoft Windows Server 2003 R2
PHP version: 5.4.4
Package: Safe Mode/open_basedir
Bug Type: Bug
Bug description:Excuse me, is this a bug?
Description:
php.ini
[PATH= "D:/Web/test.com/public"]
open_basedir="D:/Web/test.com/public/"
Test script:
---
'; //D:\WEB\TEST_COM\
$cmd = 'ping qq.com';
echo execute('system',$cmd);
echo execute('passthru',$cmd);
echo execute('shell_exec',$cmd);
echo execute('exec',$cmd);
echo execute('popen',$cmd);
function execute($type,$cfe) {
$data = '';
if ($cfe) {
if($type=='system') {
@ob_start();
@system($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='passthru') {
@ob_start();
@passthru($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='shell_exec') {
$data = @shell_exec($cfe);
} elseif($type=='exec') {
@exec($cfe,$data);
$data = join("\n",$data);
} elseif($type=='popen') {
$f = @popen($cfe,"r");
while(!@feof($f)) {
$data .= @fread($f,1024);
}
@pclose($f);
}
}
return $type.'--'.$data.''.$type.'--';
}
?>
Expected result:
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
Pinging qq.com [119.147.15.13] with 32 bytes of data: Reply from
119.147.15.13: bytes=32 time=11ms TTL=56 Reply from 119.147.15.13: bytes=32
time=11ms TTL=56 Reply from 119.147.15.13: bytes=32 time=11ms TTL=56 Reply
from 119.147.15.13: bytes=32 time=11ms TTL=56 Ping statistics for
119.147.15.13: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 11ms, Maximum =
11ms, Average = 11ms
passthru--
shell_exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from
119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32
time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply
from 119.147.15.17: bytes=32 time=9ms TTL=56 Ping statistics for
119.147.15.17: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum =
9ms, Average = 9ms
shell_exec--
exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from
119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32
time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply
from 119.147.15.17: bytes=32 time=9ms TTL=56 Ping statistics for
119.147.15.17: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum =
9ms, Average = 9ms
exec--
popen--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from
119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32
time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply
from 119.147.15.17: bytes=32 time=9ms TTL=56 Ping statistics for
119.147.15.17: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum =
9ms, Average = 9ms
popen--
Actual result:
--
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
passthru--
shell_exec--
shell_exec--
exec--
exec--
popen--
popen--
--
Edit bug report at https://bugs.php.net/bug.php?id=62457&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62457&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62457&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62457&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62457&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62457&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62457&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62457&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62457&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62457&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62457&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62457&r=notwrong
Not enough info:
[PHP-BUG] Bug #62456 [NEW]: Incorrect description of notice
From: iblacksmoke at gmail dot com
Operating system: debian linux
PHP version: 5.4.4
Package: I18N and L10N related
Bug Type: Bug
Bug description:Incorrect description of notice
Description:
Description of notice when calling missing property of standard php object
contains incorrect characters (possibly from different encoding). They
cause error in class of standard class ErrorException, and script returns
fatal error(with no information) rather than exception. It turns out there
as much as two bugs: incorrect encoding of strings and lack of data
filtering in ErrorException constructor.
Test script:
---
one:
$test = new StdClass();
echo $test->qwerty;
two:
set_error_handler(function($errno, $errstr, $errfile, $errline){
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
});
$test = new StdClass();
echo $test->qwerty;
Expected result:
one:
Notice: Undefined property: stdClass::$qwerty in script
two:
correct php exception
Actual result:
--
one:
Notice: Undefined property: stdClass�K� ::$qwerty in script
two:
Fatal error: in script
--
Edit bug report at https://bugs.php.net/bug.php?id=62456&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62456&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62456&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62456&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62456&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62456&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62456&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62456&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62456&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62456&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62456&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62456&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62456&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62456&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62456&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62456&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62456&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62456&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62456&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62456&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62456&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62456&r=mysqlcfg
Bug #62451 [Opn->Dup]: no sqlite3 replacement session handlers
Edit report at https://bugs.php.net/bug.php?id=62451&edit=1 ID: 62451 Updated by: fel...@php.net Reported by:colin at viebrock dot ca Summary:no sqlite3 replacement session handlers -Status: Open +Status: Duplicate Type: Bug Package:Session related Operating System: Debian PHP Version:5.4.4 Block user comment: N Private report: N New Comment: Please, use the bug #53713 to comment. Previous Comments: [2012-06-30 00:51:12] fel...@php.net I've assigned the old feature request to the SQLite3 maintainer. [2012-06-29 14:55:34] colin at viebrock dot ca Description: Since sqlite was dropped from 5.4, we've lost the sqlite session handlers. I was hoping there'd be a sqlite3 replacement, but that doesn't seem to be the case. There was a bug report about this previously (https://bugs.php.net/bug.php? id=53713) with a patch ... but it never seems to have been applied to a release build. Can I ask that this be added to the 5.4.x branch? I'm sure it was an oversight, but removing sqlite session handler support seems to be a pretty important backwards compatability issue that wasn't explicitly mentioned. -- Edit this bug report at https://bugs.php.net/bug.php?id=62451&edit=1
Bug #62415 [Opn->Csd]: Undefined variable: diff in run-tests.php on line 2093 for successful XFAIL
Edit report at https://bugs.php.net/bug.php?id=62415&edit=1 ID: 62415 Updated by: fel...@php.net Reported by:s...@php.net Summary:Undefined variable: diff in run-tests.php on line 2093 for successful XFAIL -Status: Open +Status: Closed Type: Bug Package:Testing related PHP Version:5.4Git-2012-06-25 (Git) -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-06-30 19:43:58] fel...@php.net Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=75d8af715cd624dda243d31f826c7da927ccd22f Log: - Fixed bug #62415 (Undefined variable: diff in run-tests.php on line 2093 for successful XFAIL) [2012-06-30 19:43:57] fel...@php.net Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=eb012cf88440423ff02c46421f29a1c6e850702c Log: - Fixed bug #62415 (Undefined variable: diff in run-tests.php on line 2093 for successful XFAIL) [2012-06-30 19:42:45] fel...@php.net Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=75d8af715cd624dda243d31f826c7da927ccd22f Log: - Fixed bug #62415 (Undefined variable: diff in run-tests.php on line 2093 for successful XFAIL) [2012-06-26 00:38:37] s...@php.net Description: Tests that pass but have XFAIL sections seem to be causing: WARN Whatever phpt description [whatever.phpt] (warn: XFAIL section but test passes) PHP Notice: Undefined variable: diff in /home/cjones/php-5.4/run-tests.php on line 2093 -- Edit this bug report at https://bugs.php.net/bug.php?id=62415&edit=1
php-bugs@lists.php.net
From: scout4u at ya dot ru
Operating system:
PHP version: 5.4.4
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:last chance to work with __call by reference died after
removing call-time-&
Description:
As of PHP 5.4 our content management system became not working without
possibility to get it to life. Beacause of a bug of removing call-time
passing
by reference.
Explanation:
We have magical loading of «methods» in class as __call() - processed
launches:
__call:
1. seeking existing of function If it exists â then function launches
and everything is ok.
2. If there is no such function â it's been loaded from _functions/
directory:
So we have auto-loading of functions.
BUT:
Because of __call don't support (why???) references we could call our
methods like this:
$sm->test( &data );
and in test-function we were be able to work BY REFERENCE. In php53 there
was
deprecations â ok, we were turning them off. BUT as of php54 we
completely can't
load virtual function with passing reference nohow... at all.
Ok, we can to preload function if it doesn't exist. But we already can't
work by
reference. So... in case of dealing with realy big array we will have to
push
that into the function and COPY back to the original. This is a huge
CPU/memory
consuming way.
Sooo... If there is no way to pass to the __call Maybe dear authors will
revert
support (even with peprecation-errors) for future times exactly untill
__call
could deal with reference (if that will never start working with reference
â
maybe there should be way to work with __call at least by passing reference
in
call-time maner?)
I belive that __call and its ability of working by reference is a criticaly
important (maybe not so usual happen) but important thing to leave in PHP
still
working
Test script:
---
1);
function test( &$d ){
$d['prop'] = 2;
}
$sm->test( &$data ); // PHP 5.2, 5.3(deprecated) $data['prop'] === 2
//! as of PHP54 this techinique will stop working and working by
reference to __call will not be working in all PHP-version as of 54.
$sm->test( &$data ); // PHP 5.4(removed) fail
?>
--
Edit bug report at https://bugs.php.net/bug.php?id=62455&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62455&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62455&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62455&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62455&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62455&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62455&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62455&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62455&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62455&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62455&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62455&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62455&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62455&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62455&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62455&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62455&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62455&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62455&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62455&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62455&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62455&r=mysqlcfg
Bug #62419 [Com]: RuntimeException throws fatal error if passing a previous exception to the ctor
Edit report at https://bugs.php.net/bug.php?id=62419&edit=1 ID: 62419 Comment by: Sjon at hortensius dot net Reported by:bugs dot php at mohiva dot com Summary:RuntimeException throws fatal error if passing a previous exception to the ctor Status: Open Type: Bug Package:SPL related Operating System: Gentoo Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: I cannot reproduce this, it seems to work fine? http://3v4l.org/IAF3d#v530 Previous Comments: [2012-06-26 11:26:52] bugs dot php at mohiva dot com Description: If you pass a previous exception to the constructor of the RuntimeException class, then PHP throws a fatal error without an error message. I have tested those exceptions which are derived from RuntimeException, and they all work fine. The same counts for the base Exception class. Test script: --- https://bugs.php.net/bug.php?id=62419&edit=1
Bug #62437 [Com]: Strange behavior with global variables (objects) in ob_start() output callback
Edit report at https://bugs.php.net/bug.php?id=62437&edit=1
ID: 62437
Comment by: Sjon at hortensius dot net
Reported by:tero dot tasanen at gmail dot com
Summary:Strange behavior with global variables (objects) in
ob_start() output callback
Status: Open
Type: Bug
Package:Output Control
Operating System: Linux 64bit
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
Contrary to what tony2001 says in #40604, this was actually working fine until
it
was broken in 5.2
http://3v4l.org/SUUkK
The reason that http://3v4l.org/pZ2PP works might be explained to the second
reference to the same object which could prevent destruction, but that would
then
actually be a bug too (since it indicates a memory-leak).
Previous Comments:
[2012-06-28 11:56:12] tero dot tasanen at gmail dot com
Description:
Global variables in output buffering seem to work in very strange way. don't
know
actually if this has anything to do with output buffering callback but see the
test case attached to reproduce this.
And the strangest thing is that if you uncomment the last line the script works
as expected!
After some searching I found two similar bug reports (#40604, #44840) and the
comments indicate that this is expected behavior?! Not just that it seem really
strange that all objects get destroyed before the output callback is called,
but
why does the use of the $test variable in the end of the script change this
behavior? This really does not make any sense!
Test script:
---
bar;
}
ob_start('output');
$object = new stdClass();
$object->bar = "bar";
echo "foo ";
// $test = $object;
Expected result:
foo bar
Actual result:
--
PHP Notice: Trying to get property of non-object in /home/ttasanen/test.php on
line 5
PHP Stack trace:
PHP 1. output() /home/ttasanen/test.php:0
foo
--
Edit this bug report at https://bugs.php.net/bug.php?id=62437&edit=1
Bug #49657 [Com]: array_search returns null instead of false
Edit report at https://bugs.php.net/bug.php?id=49657&edit=1 ID: 49657 Comment by: phillip dot berndt at googlemail dot com Reported by:pvenakis at efrontlearning dot net Summary:array_search returns null instead of false Status: Not a bug Type: Bug Package:Unknown/Other Function Operating System: windows PHP Version:5.3.0 Block user comment: N Private report: N New Comment: I disagree. This function returning NULL is nothing I'd expect. Especically since this behavior still (it's 2012!) is not documented. This IS a bug. If not because of the "feature", at least one regarding missing documentation. In PHP 4.2, you changed this function such that it returns FALSE in case of an error, which, as was pointed out above by the other commenter, is good, because it makes existence checking easy. Since FALSE !== NULL, things get pretty complicated now. Previous Comments: [2011-11-26 16:11:57] rodrigovb at gmail dot com I'd like to advise you about the impact of this change in the company I work. Based on the last return value (FALSE) we had 40 php files with some lines checking the result of array_search (=== false). This is a small company with 30 employees (and 40 php files to be changed). The concern of the owner is if PHP is sustainable enough to keep investing in develop instead of maintenance due to this changes. Please write the change log (or point the link with the log) cointaining the real needs of this ghange. In my point of view the impact of return value changes of any function could be severe, specially in bigger companies. [2009-09-25 07:14:46] pvenakis at efrontlearning dot net Thanks for the quick response. It's fine that it returns null, but since this changed from 5.2 to 5.3 it would be nice if it were mentioned in the changelog or in the documents. Best Regards, Periklis [2009-09-24 12:17:22] paj...@php.net That's expected. Returning NULL on invalid argument(s) is correct. [2009-09-24 12:03:47] pvenakis at efrontlearning dot net Description: array_search returns false in 5.2.x, null in 5.3.0, when $haystack is not an array Reproduce code: --- $haystack = false; //Anything not an array $result = array_search(1, $haystack); var_dump($result); Expected result: bool(false) Actual result: -- null -- Edit this bug report at https://bugs.php.net/bug.php?id=49657&edit=1
