Bug #54726 [Com]: partial open_basedir path no longer works
Edit report at http://bugs.php.net/bug.php?id=54726&edit=1
ID: 54726
Comment by: superaap at gmail dot com
Reported by:superaap at gmail dot com
Summary:partial open_basedir path no longer works
Status: Duplicate
Type: Bug
Package:Safe Mode/open_basedir
Operating System: CentOS release 5.4 (Final)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Seems related to bug #53352 too, which was fixed in r305698
I'll try to build the latest snap and verify whether my problem was
fixed as well.
The patch looks promising.
Previous Comments:
[2011-05-21 02:19:56] fel...@php.net
See bug #53577
[2011-05-13 09:41:19] superaap at gmail dot com
Description:
Our VirtualHost points to a symlink which links to the document_root of
the
current application version.
Example directory list;
l /var/www/html/application -> /var/www/html/application-v1.2.3
d /var/www/html/application-v1.2.2
d /var/www/html/application-v1.2.3
Before v5.3 (5.2.4 I think) using the entire symlink path as
open_basedir value
would sitll trigger
open_basedir error's. We worked around this problem by using the partial
suffix
'/var/www/html/app'.
This behaviour was fixed when we upgraded to v5.3.2 were the entire
symlink path
would work as well, but we
did not bother to update all our vhost's as both methods now worked.
But now we have upgraded to v5.3.6 the partial paths no longer work.
Warning: require_once() [function.require-once]: open_basedir
restriction in
effect.
File(/var/www/html/application-v1.2.3/bootstrap.php) is not within the
allowed
path(s): (.:/var/www/html/app)
This behaviour seems to be broken since r305698 where the open_basedir
is always
appended with a directory
separator;
--- php/php-src/trunk/main/fopen_wrappers.c 2010/11/23 21:49:18 305697
+++ php/php-src/trunk/main/fopen_wrappers.c 2010/11/23 22:14:54 305698
@@ -233,6 +233,9 @@
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
+ } else {
+ resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
+ resolved_basedir[resolved_basedir_len] = '\0';
}
resolved_name_len = strlen(resolved_name);
I don't think this change was intended because it is not listed in the
changelog, and breaks backward
compatibility in a minor release.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54726&edit=1
[PHP-BUG] Req #54897 [NEW]: Allow class methods to determine whether they're being called statically or not
From:
Operating system:
PHP version: Irrelevant
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:Allow class methods to determine whether they're being called
statically or not
Description:
At the moment there is no reliable way to determine whether a function is
being
called statically or on an object directly. Sometimes it's useful to know
the
difference between e.g.
foo::createUrl();
and
$foo->createUrl();
it would be nice to have a function, called something like is_static_call()
which
could supply this information to the current method. I'm not familiar with
the PHP
internals so I don't know how difficult this is to implement, but for me it
would
be a useful feature.
Test script:
---
class foo {
public function createUrl($url = null, $params = array()) {
if ($url === null && is_static_call()) {
$url = "list";
}
elseif ($url === null) {
$url = "view";
}
/* do something */
}
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54897&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54897&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54897&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54897&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54897&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54897&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54897&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54897&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54897&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54897&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54897&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54897&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54897&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54897&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54897&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54897&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54897&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54897&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54897&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54897&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54897&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54897&r=mysqlcfg
[PHP-BUG] Bug #54898 [NEW]: HTTP context option "ignore_errors" does not work as expected
From: Operating system: Linux/Ubuntu PHP version: 5.3.6 Package: Streams related Bug Type: Bug Bug description:HTTP context option "ignore_errors" does not work as expected Description: >From documentation I would assume that making a HTTP request with "ignore_errors" context option I should always get response body no matter the HTTP response code server sent back. This seems to work for just some of the response codes (like 404) and will fail with others - "400 Bad Request" for example. This affects fopen() and file_get_contents() as far as I have tested. An ideal solution would be to: - if fopen() is called with HTTP context and "ignore_errors" - return a valid resource (currently it will return false with a E_WARNING). Next calling stream_get_contents() on this resource should return response body. If "ignore_errors" is not set - behave the old way - keeping backwards- compatibility. - if file_get_contents() is called with HTTP context and "ignore_errors" - return response body no matter HTTP response code. Otherwise - keep old functionality for backwards compatibility. Because of this bug writing an API client with HTTP streams is somewhat of challenge (or not possible at all). -- Edit bug report at http://bugs.php.net/bug.php?id=54898&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54898&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54898&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54898&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54898&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54898&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54898&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54898&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54898&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54898&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54898&r=support Expected behavior: http://bugs.php.net/fix.php?id=54898&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54898&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54898&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54898&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54898&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54898&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54898&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54898&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54898&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54898&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54898&r=mysqlcfg
[PHP-BUG] Bug #54899 [NEW]: NO PHP CONTENT DISPLAY
From: Operating system: WINDOWS PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Bug Bug description:NO PHP CONTENT DISPLAY Description: Hi , I have simple html script that calls php script , when i run HTML, there is no output from php code, it simple paste the comeplte code. i verified, my php scripts all working properly. wel_input.html Name: Test script: --- welcome.php Welcome ! WHY is php not echoing the output sent from html? Expected result: expectation is the outpu name type in html form Actual result: -- the php code, is coming into browser, instead of outputting the value. -- Edit bug report at http://bugs.php.net/bug.php?id=54899&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54899&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54899&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54899&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54899&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54899&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54899&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54899&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54899&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54899&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54899&r=support Expected behavior: http://bugs.php.net/fix.php?id=54899&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54899&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54899&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54899&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54899&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54899&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54899&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54899&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54899&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54899&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54899&r=mysqlcfg
[PHP-BUG] Req #54900 [NEW]: Implement content compression for HTTP streams with "protocol_version" = 1.1
From: Operating system: Linux/Ubuntu PHP version: 5.3.6 Package: Streams related Bug Type: Feature/Change Request Bug description:Implement content compression for HTTP streams with "protocol_version" = 1.1 Description: A feature request to implement HTTP stream content compression in the following scenario: If a HTTP context is created with "protocol_version" = 1.1, send 'Accept-Encoding' header and if the server responds with "Content-Encoding" header - handle/decompress content. While this functionality can be implemented in PHP- userland - it would be great to have it built-in. I guess this feature could be totally transparent and, for example, should be silently disabled if zlib is not available. -- Edit bug report at http://bugs.php.net/bug.php?id=54900&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54900&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54900&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54900&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54900&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54900&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54900&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54900&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54900&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54900&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54900&r=support Expected behavior: http://bugs.php.net/fix.php?id=54900&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54900&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54900&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54900&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54900&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54900&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54900&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54900&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54900&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54900&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54900&r=mysqlcfg
Bug #54899 [Opn->Bgs]: NO PHP CONTENT DISPLAY
Edit report at http://bugs.php.net/bug.php?id=54899&edit=1 ID: 54899 Updated by: fel...@php.net Reported by:KAPRISHi1 at yahoo dot com Summary:NO PHP CONTENT DISPLAY -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: WINDOWS PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Seems your Apache doesn't loaded the PHP module... Not a PHP issue. Previous Comments: [2011-05-21 17:34:16] KAPRISHi1 at yahoo dot com Description: Hi , I have simple html script that calls php script , when i run HTML, there is no output from php code, it simple paste the comeplte code. i verified, my php scripts all working properly. wel_input.html Name: Test script: --- welcome.php Welcome ! WHY is php not echoing the output sent from html? Expected result: expectation is the outpu name type in html form Actual result: -- the php code, is coming into browser, instead of outputting the value. -- Edit this bug report at http://bugs.php.net/bug.php?id=54899&edit=1
Bug #54620 [Opn->Bgs]: ReflectionClass::setStaticPropertyValue does not work for protected/private
Edit report at http://bugs.php.net/bug.php?id=54620&edit=1
ID: 54620
Updated by: fel...@php.net
Reported by:jeroen at asystance dot nl
Summary:ReflectionClass::setStaticPropertyValue does not
work for protected/private
-Status: Open
+Status: Bogus
Type: Bug
Package:Reflection related
Operating System: linux
PHP Version:5.3.6
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
You need to use the setAccessible() approach.
Previous Comments:
[2011-04-28 17:20:47] felipecg00 at gmail dot com
My bad. I mean protecting the privates is probably the way Reflection
was designed for, so it's correct behavior (not a bug).
For myself, I really think that Reflection power should be left on
programmer's side to decide on what to do - still one should know where
to use it. But maybe getProperty() was designed just for that.
The Fatal Error comes from the uncaught exception, just as any left
"throw new Exception()" without a catch will cause it.
[2011-04-28 16:58:55] jeroen at asystance dot nl
Thanks for the workaround.
Access modifiers are for visibility between classes, so I don't see
circumventing them through Reflection as a problem. If you cast en
object to an array, you also get the private / protected variables (see
#44273).
Your workaround (using getProperty) also works just fine.
So I think the way to go is just enable access to private / protected
members.
Whatever the design decision though, a Fatal Error is certainly a bug :)
[2011-04-28 16:25:19] felipecg00 at gmail dot com
I can reproduce this, still I think that in this case, protecting the
private and protected resources is the correct behavior.
You might want to check this:
$rT = new ReflectionClass( 'Tehst' );
var_dump( $s = $rT->getProperty('prot') );
var_dump( $s->isStatic() );
$s->setAccessible(1);
$s->setValue("myProt");
var_dump( $s->getValue() );
[2011-04-28 12:45:27] jeroen at asystance dot nl
Description:
---
>From manual page:
http://www.php.net/reflectionclass.setstaticpropertyvalue#Description
---
ReflectionClass::getProperties() shows public, protected and private
members, but ReflectionClass::setStaticPropertyValue throws a fatal
error if a protected or private member is set.
The error message says that "Class Tehst does not have a property named
prot", which is plain wrong.
Test script:
---
getProperties() );
$rT->setStaticPropertyValue( 'pub', 'myPub' );
$rT->setStaticPropertyValue( 'prot', 'myProt' );
$rT->setStaticPropertyValue( 'priv', 'myPriv' );
?>
Expected result:
array (
0 =>
ReflectionProperty::__set_state(array(
'name' => 'pub',
'class' => 'Tehst',
)),
1 =>
ReflectionProperty::__set_state(array(
'name' => 'prot',
'class' => 'Tehst',
)),
2 =>
ReflectionProperty::__set_state(array(
'name' => 'priv',
'class' => 'Tehst',
)),
)pub: myPub
Actual result:
--
array (
0 =>
ReflectionProperty::__set_state(array(
'name' => 'pub',
'class' => 'Tehst',
)),
1 =>
ReflectionProperty::__set_state(array(
'name' => 'prot',
'class' => 'Tehst',
)),
2 =>
ReflectionProperty::__set_state(array(
'name' => 'priv',
'class' => 'Tehst',
)),
)pub: myPub
PHP Fatal error: Uncaught exception 'ReflectionException' with message
'Class Tehst does not have a property named prot' in
/home/jay/public_html/alis/newfile.php:14
Stack trace:
#0 /home/jay/public_html/alis/newfile.php(14):
ReflectionClass->setStaticPropertyValue('prot', 'myProt')
#1 {main}
thrown in /home/jay/public_html/alis/newfile.php on line 14
Fatal error: Uncaught exception 'ReflectionException' with message
'Class Tehst does not have a property named prot' in
/home/jay/public_html/alis/newfile.php:14
Stack trace:
#0 /home/jay/public_html/alis/newfile.php(14):
ReflectionClass->setStaticPropertyValue('prot', 'myProt')
#1 {main}
thrown in /home/jay/public_html/alis/newfile.php on line 14
--
Edit this bug report at http://bugs.php.net/bug.php?id=54620&edit=1
Bug #54860 [Opn->Fbk]: PHP crash when using closures + extract(EXTR_REFS)
Edit report at http://bugs.php.net/bug.php?id=54860&edit=1
ID: 54860
Updated by: fel...@php.net
Reported by:ninzya at inbox dot lv
Summary:PHP crash when using closures + extract(EXTR_REFS)
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can't reproduce it.
Previous Comments:
[2011-05-19 14:02:47] ninzya at inbox dot lv
Sorry, extract() has nothing to do with this issue.
I was able to come up with more compact test script with no use of
extract():
$x =new stdClass;
$y =&$x;
for( $i =0; $i < 2; ++$i) {
$closure =function() use( $y) {
$y->someProperty ='someValue';// crashes on second iteration
};
$closure();
}
This code does not crash PHP 5.3.5. It seems that references + closures
became
broken in 5.3.6.
[2011-05-19 12:03:20] ninzya at inbox dot lv
Description:
See test script.
PHP 5.3.5 is not affected.
Test script:
---
// Initially $Object is not a reference and contains a "pointer"
// to an stdClass object.
$Object =new stdClass; /**/ echo 'New: '; debug_zval_dump( $Object);
// $Object becomes a reference to the "pointer" to an stdClass.
$Object =&$Object; /**/ echo 'Self-reference: '; debug_zval_dump(
$Object);
// Now we import $Object into closure by value. In theory,
// $Object, that is inside closure, should not be a reference, but
rather
// should be a variable, that "points" to stdClass (i.e. an equivalent
of
// $ImportedObject in expression "$ImportedObject =$Object").
$closure =function() use( $Object) {
// Once you manipulate $Object, you get PHP crashed.
$Object->x =10;
//debug_zval_dump( $Object);
};
// By calling extract() we make $Object to reference a new stdClass
instance.
extract( array( 'Object' =>new stdClass), EXTR_REFS);
echo 'After extract: '; debug_zval_dump( $Object);
// now we execute closure and get PHP crashed
$closure();
Expected result:
PHP should not crash.
Actual result:
--
PHP crashes.
If you put die() right before $closure(), then you get following
output:
line 1: New: object(stdClass)#1 (0) refcount(2){
line 2: }
line 3: Self-reference: object(stdClass)#1 (0) refcount(1){
line 4: }
line 5: After extract: object(stdClass)#3 (0) refcount(2){
line 6: }
Some questions regarding that output:
1) why there is refcount(2) in the first line? Isn't the object
referenced only
once and by $Object variable? I would expect to see refcount(1) here. As
you can
see on line 3, refcount seems to become correct after self-referencing
is being
made.
2) why line 5 says object(stdClass)#3, while there were only two (and
not 3)
stdClass objects allocated? If you comment out closure's definition,
then you
get object(stdClass)#2 (an expected output). Does closure clone $Object
when you
say "use($Object)"? Shouldn't the stdClass object be simply "referenced"
by the
"use($Object)"?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54860&edit=1
Bug #54721 [Asn]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: tony2...@php.net Reported by:os at irj dot ru Summary:crypt function Status: Assigned Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: Pierre, could you test the proposed fix, please? Thanks in advance. Previous Comments: [2011-05-16 17:18:12] paj...@php.net Please note that as this code may or should produce similar results on all platforms or builds, it is not correct. MD5 salt is max. 12 characters as described in the manual and how the extra characters are treated are implementation specific. Use blowfish or other stronger algorithm if you like to use a bigger salt. [2011-05-16 16:46:03] paj...@php.net Confirmed. Seems to be only happening in the TS API. [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmp>php test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php C:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru >From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmp>php test.php $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmp>php test.php $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmp>php test.php $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmp>php test.php $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmp>php test.php $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp> [2011-05-12 18:58:23] os at irj dot ru Sorry, in cli mode bug too (in previos command I use a old CLI php) This is a correct log D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$.O4MUs7rYRmlSuPIA16Jt. D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$sVRmxDm7.B8xcTu1HZKf6/ D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php $1$dW0.is5.$zI8c4NaU.KzK2y5u.W4Ax. D:\Web\var\avers.localhost>D:\Web\php53\php.exe -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost>..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhost>D:\curl\curl.exe http://avers.localhost/test.php $1$dW0.is5.$.y5yjTLPgypzeHv0FU7zW0 D:\Web\var\avers.localhost>D:\Web\php53\php.exe D:\Web\var\avers.localhost\test .php $1$dW0.is5.$m.YjcIs.joLsQHQGZ0bxn/ D:\Web\var\avers.localhost> The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54721 -- Edit this bug report at http://bugs.php.net/bug.php?id=54721&edit=1
Bug #54727 [Opn->Asn]: ob_flush() before output_reset_rewrite_vars() results in data loss
Edit report at http://bugs.php.net/bug.php?id=54727&edit=1 ID: 54727 Updated by: fel...@php.net Reported by:mats dot lindh at gmail dot com Summary:ob_flush() before output_reset_rewrite_vars() results in data loss -Status: Open +Status: Assigned Type: Bug Package:Output Control Operating System: * PHP Version:trunk-SVN-2011-05-13 (SVN) -Assigned To: +Assigned To:mike Block user comment: N Private report: N Previous Comments: [2011-05-13 14:00:06] mats dot lindh at gmail dot com Description: The test for http://bugs.php.net/bug.php?id=26862 currently fails and results in the last echo statement (everything after ob_flush() and output_reset_rewrite_vars()) to get lost. A variant of the issue was reintroduced after the output buffering rewrite. This seems to happen because the output is never handled if there is no rewrite variables to process and there is no active buffer with contents. The output chars still needs to returned as handled. The patch also contains a small change in the test to better differentiate the two echo statements. Test script: --- Based on: ext/session/tests/bug26862.phpt link'; ob_flush(); output_reset_rewrite_vars(); echo 'link'; Expected result: linklink Actual result: -- link -- Edit this bug report at http://bugs.php.net/bug.php?id=54727&edit=1
Bug #54832 [Opn]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832&edit=1 ID: 54832 User updated by:giorgio dot liscio at email dot it Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate -PHP Version:trunk-SVN-2011-05-18 (snap) +PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: same error on latest 5.4 revision too May 21 2011 20:50:15 i'm using the binaries of windows.php.net http://windows.php.net/downloads/snaps/php-5.4/r311300/ Previous Comments: [2011-05-18 15:03:46] giorgio dot liscio at email dot it Description: hi, with same apache + os + mysql installation and php 5.3.6 works everything good with trunk of today (not tested on previous trunks) i get always Warning: mysqli_connect(): (HY000/2002): Impossibile stabilire la connessione. Risposta non corretta della parte connessa dopo l'intervallo di tempo oppure mancata risposta dall'host collegato. in E:\Lavoro\Software\Apache2\htdocs\index.php on line 20 ~translation from italian: unable to establish the connection. invalid answer in the time interval or no answer from the host -- Edit this bug report at http://bugs.php.net/bug.php?id=54832&edit=1
Bug #54614 [Opn]: Trivial RE failure: /([^b]*a*)*$/
Edit report at http://bugs.php.net/bug.php?id=54614&edit=1
ID: 54614
Updated by: fel...@php.net
Reported by:php at richardneill dot org
Summary:Trivial RE failure: /([^b]*a*)*$/
Status: Open
Type: Bug
-Package:*Regular Expressions
+Package:PCRE related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Not a PHP bug.
Previous Comments:
[2011-04-27 23:47:20] php at richardneill dot org
Sorry, my bad (sort of).
There is a genuine bug that affected longer regexps even with
backtrack.limit set
to 32M, which I saw on 5.3.2, but is now solved on 5.3.6.
Unfortunately, the test-case which I simplified for the bug-report
didn't
remember to set backtrack.limit (I thought I'd done it in php.ini, but
had
actually done it explicitly with ini.set in my original script). So the
test
case:
- works for backtrack.limit = 1M (on both 5.3.2 and 5.3.6)
- fails for the default 100k on both.
Either way, it's still something that, imho, should work on a default
install.
May I make a few suggestions:
* backtrack.limit should be raised by default, to at least 10M.
* backtrack.limit should default to 100M for the CLI version of PHP.
* validating bug reports is painful, partly because I had to spend some
extra
time tracking down the latest version of PHP and building it. This is
error-
prone. How about providing a sandboxed VM on bugs.php.net where we can
paste our
own code to check it? This would make it far easier to file correct bug
reports.
(it would take the reporter 3 minutes, rather than an hour).
[2011-04-27 21:54:07] ras...@php.net
With pcre.backtrack_limit = 100 this works fine for me on 5.3.6. Are
you sure
you increased the limit in the right place?
[2011-04-27 21:15:34] php at richardneill dot org
A slightly simpler test case is:
$contents = "b";
$search = '/(a*a*)*$/';
[2011-04-27 18:43:02] php at richardneill dot org
Description:
If I search in the string : 'b'
with the RE: '/([^b]*a*)*$/'
then preg_replace fails with a backtrack-limit error. (error 2)
I have backtrack.limit configured to 32MB, so something is very wrong.
The example fails on several different PHP versions, CPU architectures
and Linux
Distros. However, using Perl for the same RE works fine.
Test script:
---
$contents = "b";
$search = '/([^b]*a*)*$/';
$result = preg_replace($search,"x",$contents);
if ($result === NULL){
echo "preg failed, error is ".preg_last_error()."\n";
}else{
echo "success\n";
}
Expected result:
preg_replace shouldn't fail.
Actual result:
--
preg_replace returns NULL, and preg_last_error returns 2.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54614&edit=1
Bug #54614 [Opn->Csd]: Trivial RE failure: /([^b]*a*)*$/
Edit report at http://bugs.php.net/bug.php?id=54614&edit=1
ID: 54614
Updated by: ras...@php.net
Reported by:php at richardneill dot org
Summary:Trivial RE failure: /([^b]*a*)*$/
-Status: Open
+Status: Closed
Type: Bug
Package:PCRE related
Operating System: Linux
PHP Version:5.3.6
-Assigned To:
+Assigned To:rasmus
Block user comment: N
Private report: N
New Comment:
I have increased the backtrack limit to 100 in all branches.
Previous Comments:
[2011-05-21 21:35:16] fel...@php.net
Not a PHP bug.
[2011-04-27 23:47:20] php at richardneill dot org
Sorry, my bad (sort of).
There is a genuine bug that affected longer regexps even with
backtrack.limit set
to 32M, which I saw on 5.3.2, but is now solved on 5.3.6.
Unfortunately, the test-case which I simplified for the bug-report
didn't
remember to set backtrack.limit (I thought I'd done it in php.ini, but
had
actually done it explicitly with ini.set in my original script). So the
test
case:
- works for backtrack.limit = 1M (on both 5.3.2 and 5.3.6)
- fails for the default 100k on both.
Either way, it's still something that, imho, should work on a default
install.
May I make a few suggestions:
* backtrack.limit should be raised by default, to at least 10M.
* backtrack.limit should default to 100M for the CLI version of PHP.
* validating bug reports is painful, partly because I had to spend some
extra
time tracking down the latest version of PHP and building it. This is
error-
prone. How about providing a sandboxed VM on bugs.php.net where we can
paste our
own code to check it? This would make it far easier to file correct bug
reports.
(it would take the reporter 3 minutes, rather than an hour).
[2011-04-27 21:54:07] ras...@php.net
With pcre.backtrack_limit = 100 this works fine for me on 5.3.6. Are
you sure
you increased the limit in the right place?
[2011-04-27 21:15:34] php at richardneill dot org
A slightly simpler test case is:
$contents = "b";
$search = '/(a*a*)*$/';
[2011-04-27 18:43:02] php at richardneill dot org
Description:
If I search in the string : 'b'
with the RE: '/([^b]*a*)*$/'
then preg_replace fails with a backtrack-limit error. (error 2)
I have backtrack.limit configured to 32MB, so something is very wrong.
The example fails on several different PHP versions, CPU architectures
and Linux
Distros. However, using Perl for the same RE works fine.
Test script:
---
$contents = "b";
$search = '/([^b]*a*)*$/';
$result = preg_replace($search,"x",$contents);
if ($result === NULL){
echo "preg failed, error is ".preg_last_error()."\n";
}else{
echo "success\n";
}
Expected result:
preg_replace shouldn't fail.
Actual result:
--
preg_replace returns NULL, and preg_last_error returns 2.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54614&edit=1
[PHP-BUG] Req #54902 [NEW]: fseek inconsistencies with large (>2GB) files
From: Operating system: Windows 7 PHP version: 5.3.6 Package: Filesystem function related Bug Type: Feature/Change Request Bug description:fseek inconsistencies with large (>2GB) files Description: Firstly, I'm aware that fseek/ftell doesn't necessarily work correctly with >2GB files with 32-bit PHP due to integer range constraints, however, fseek operates rather inconsistently when passing 2GB, which would be nice if fixed (note that I've put this as a feature request, as it's a nice to have, and unsure if you'd classify this as a bug). I'm using the 32-bit Windows build from here: http://windows.php.net/download/ See example script [ http://pastebin.com/Zb0vRgWX ] with comments for more info. I haven't looked at PHP's source code, but from the behaviour of the script, I'm guessing that fseek does some checks, and because it's overflowing, it won't allow certain operations. I'm not sure about the weird 8192 byte limit though. As fread allows overflows, would it be possible to allow fseek to overflow too? (PS first time I've submitted a "bug" - I hope I've done it correctly >_>) -- Edit bug report at http://bugs.php.net/bug.php?id=54902&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54902&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54902&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54902&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54902&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54902&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54902&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54902&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54902&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54902&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54902&r=support Expected behavior: http://bugs.php.net/fix.php?id=54902&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54902&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54902&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54902&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54902&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54902&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54902&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54902&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54902&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54902&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54902&r=mysqlcfg
Req #54902 [Opn]: fseek inconsistencies with large (>2GB) files
Edit report at http://bugs.php.net/bug.php?id=54902&edit=1 ID: 54902 User updated by:zingaburga at hotmail dot com Reported by:zingaburga at hotmail dot com Summary:fseek inconsistencies with large (>2GB) files Status: Open Type: Feature/Change Request Package:Filesystem function related Operating System: Windows 7 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: If you're wondering, I'm using the following function to try to get around the fseek limitations. It works, but it's really slow for large seeks. If the 8KB limitation could be lifted, then this function could be serveral times faster. http://pastebin.com/xWiQxgSB Previous Comments: [2011-05-22 05:24:38] zingaburga at hotmail dot com Description: Firstly, I'm aware that fseek/ftell doesn't necessarily work correctly with >2GB files with 32-bit PHP due to integer range constraints, however, fseek operates rather inconsistently when passing 2GB, which would be nice if fixed (note that I've put this as a feature request, as it's a nice to have, and unsure if you'd classify this as a bug). I'm using the 32-bit Windows build from here: http://windows.php.net/download/ See example script [ http://pastebin.com/Zb0vRgWX ] with comments for more info. I haven't looked at PHP's source code, but from the behaviour of the script, I'm guessing that fseek does some checks, and because it's overflowing, it won't allow certain operations. I'm not sure about the weird 8192 byte limit though. As fread allows overflows, would it be possible to allow fseek to overflow too? (PS first time I've submitted a "bug" - I hope I've done it correctly >_>) -- Edit this bug report at http://bugs.php.net/bug.php?id=54902&edit=1
