[PHP-BUG] Bug #54859 [NEW]: GD: image* support for PHP streams
From:
Operating system: All
PHP version: 5.3.6
Package: GD related
Bug Type: Bug
Bug description:GD: image* support for PHP streams
Description:
imagepng/imapgejpg/imagegd.. do not accept PHP streams as string parameter
('php://memory').
Test script:
---
$fileName = 'php://memory';
imagepng($image, $fileName);
$imageData = file_get_contents( $fileName );
Actual result:
--
Warning: imagepng() [function.imagepng]: Unable to open 'php://memory' for
writing: Invalid argument...
--
Edit bug report at http://bugs.php.net/bug.php?id=54859edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54859r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54859r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54859r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54859r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54859r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54859r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54859r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54859r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54859r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54859r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54859r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54859r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54859r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54859r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54859r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54859r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54859r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54859r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54859r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54859r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54859r=mysqlcfg
Req #45002 [Com]: __get() and __set() don't work for static variable calls
Edit report at http://bugs.php.net/bug.php?id=45002edit=1 ID: 45002 Comment by: allesbesser at gmail dot com Reported by:jb2386 at hotmail dot com Summary:__get() and __set() don't work for static variable calls Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Any PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Please use the patch by thekid for the next release. We really need this. Previous Comments: [2011-03-30 19:26:04] marious dot alex at gmail dot com This would be a really useful feature that I have been wishing for, for at least two years. How come this has not been implemented when it is such a simple feature that has also been requested since 2008? [2010-06-25 12:22:21] temporary dot hole at googlemail dot com I have an idea to use this for a static registry class, would be really useful for keeping 'application-wide' data out of global variables. I have no idea how to apply this patch, is it possible to use the above mentioned .diff on PHP 5.3.1 ? [2010-05-14 09:13:41] vincentbab at gmail dot com I would really apreciate this feature too [2009-09-24 10:23:05] peter dot rother at gmail dot com 'Twould be seriously nice to have this featureâ¦please let us know if anything can be done soon. [2009-08-01 15:25:58] atrauzzi at gmail dot com I'd have to say I'm waiting on this feature as well. Is there a snapshot I could be using to test it out? 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=45002 -- Edit this bug report at http://bugs.php.net/bug.php?id=45002edit=1
[PHP-BUG] Bug #54860 [NEW]: PHP crash when using closures + extract(EXTR_REFS)
From:
Operating system: Windows 7
PHP version: 5.3.6
Package: Reproducible crash
Bug Type: Bug
Bug description:PHP crash when using closures + extract(EXTR_REFS)
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 bug report at http://bugs.php.net/bug.php?id=54860edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54860r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54860r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54860r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54860r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54860r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54860r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54860r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54860r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54860r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54860r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54860r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54860r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54860r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54860r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54860r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54860r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54860r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54860r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54860r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54860r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54860r=mysqlcfg
Bug #45546 [Com]: PCRE with utf8 kill apache childprocess
Edit report at http://bugs.php.net/bug.php?id=45546edit=1 ID: 45546 Comment by: chris at cretaforce dot gr Reported by:kaiser at macbureau dot de Summary:PCRE with utf8 kill apache childprocess Status: No Feedback Type: Bug Package:PCRE related Operating System: FreeBSD 7 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: I confirm that the problem still exist: FreeBSD 7.4 Pcre 8.12 PHP 5.3.6 Lighttpd 1.4.28 Previous Comments: [2011-03-10 01:01:11] toreador at gmail dot com Problem still exist. Freebsd 8.2 Pcre 8.12 PHP 5.3.5 Apache 2.2.17 [2010-10-15 21:44:50] sergio at gruposinternet dot com dot br It seems that setting pcre.recursion_limit to 1700 can be used as workaround, but be warned to check for error conditions as stated by the documentation at http://www.php.net/preg_match [2010-10-15 20:48:48] sergio at gruposinternet dot com dot br Still broken. FreeBSD: 7.2-RELEASE Apache: 2.2.15 PHP version: 5.2.14 (without Suhosin patch) PCRE Library Version = 7.9 2009-04-11 From dmesg: pid 61580 (httpd), uid 80: exited on signal 4 [2010-06-04 18:56:30] martin at veverka dot eu Hi. Still broken. from Apache error log: [notice] child pid 43125 exit signal Illegal instruction (4) FreeBSD 8.0 Apache/2.2.15 PHP 5.3.2 with Suhosin-Patch PCRE Library Version = 8.02 2010-03-19 [2009-09-18 19:57:50] chris at smartt dot com Still happening on FreeBSD 7.2 and PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: May 11 2009 22:23:18) #1860 0x28cdcad1 in match () from /usr/local/lib/libpcre.so.0 #1861 0x28cde851 in match () from /usr/local/lib/libpcre.so.0 #1862 0x28ce6ad7 in pcre_exec () from /usr/local/lib/libpcre.so.0 #1863 0x28cc931b in php_pcre_match_impl () from /usr/local/lib/php/20060613/pcre.so #1864 0x28cc9de0 in php_do_pcre_match () from /usr/local/lib/php/20060613/pcre.so #1865 0x0815c7bd in execute_internal () #1866 0x285d16e0 in suhosin_execute_internal () from /usr/local/lib/php/20060613/suhosin.so #1867 0x081695db in zend_do_fcall_common_helper_SPEC () #1868 0x0815d961 in execute () #1869 0x287810c2 in _su3jdmx () from /usr/local/lib/php/20060613/ioncube_loader_fre_5.2.so #1870 0x2912ef9c in ?? () #1871 0x in ?? () #1872 0x285dc780 in __JCR_LIST__ () from /usr/local/lib/php/20060613/suhosin.so #1873 0x285d1c55 in suhosin_execute_ex () from /usr/local/lib/php/20060613/suhosin.so 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=45546 -- Edit this bug report at http://bugs.php.net/bug.php?id=45546edit=1
Bug #54804 [PATCH]: __halt_compiler and imported namespaces
Edit report at http://bugs.php.net/bug.php?id=54804edit=1
ID: 54804
Patch added by: pierr...@php.net
Reported by:vrai at moechofe dot com
Summary:__halt_compiler and imported namespaces
Status: Open
Type: Bug
Package:Compile Failure
Operating System: Ubuntu 11.01 2.6.38-8-generic
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug_54804
Revision: 1305801994
URL:
http://bugs.php.net/patch-display.php?bug=54804patch=bug_54804revision=1305801994
Previous Comments:
[2011-05-18 09:58:15] vrai at moechofe dot com
Description:
When importing namespace in a script using the __halt_compiler()
function, the imported script must use the same type of declaration
(bracketed namespace or unbracketed namespace).
Test script:
---
a.php
?php
namespace a;
require_once 'b.php';
echo 'ok',PHP_EOL;
__halt_compiler(); // Remove this line and the script will works.
b.php
?php
namespace b\c {}
namespace b\d {}
Expected result:
ok
Actual result:
--
Fatal error: Cannot mix bracketed namespace declarations with
unbracketed namespace declarations in b.php on line 2
--
Edit this bug report at http://bugs.php.net/bug.php?id=54804edit=1
Bug #54804 [Asn]: __halt_compiler and imported namespaces
Edit report at http://bugs.php.net/bug.php?id=54804edit=1
ID: 54804
Updated by: paj...@php.net
Reported by:vrai at moechofe dot com
Summary:__halt_compiler and imported namespaces
Status: Assigned
Type: Bug
Package:Compile Failure
Operating System: Ubuntu 11.01 2.6.38-8-generic
PHP Version:5.3.6
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
Can you add a test case please?
Previous Comments:
[2011-05-19 12:46:34] pierr...@php.net
The following patch has been added/updated:
Patch Name: bug_54804
Revision: 1305801994
URL:
http://bugs.php.net/patch-display.php?bug=54804patch=bug_54804revision=1305801994
[2011-05-18 09:58:15] vrai at moechofe dot com
Description:
When importing namespace in a script using the __halt_compiler()
function, the imported script must use the same type of declaration
(bracketed namespace or unbracketed namespace).
Test script:
---
a.php
?php
namespace a;
require_once 'b.php';
echo 'ok',PHP_EOL;
__halt_compiler(); // Remove this line and the script will works.
b.php
?php
namespace b\c {}
namespace b\d {}
Expected result:
ok
Actual result:
--
Fatal error: Cannot mix bracketed namespace declarations with
unbracketed namespace declarations in b.php on line 2
--
Edit this bug report at http://bugs.php.net/bug.php?id=54804edit=1
Bug #54804 [PATCH]: __halt_compiler and imported namespaces
Edit report at http://bugs.php.net/bug.php?id=54804edit=1
ID: 54804
Patch added by: pierr...@php.net
Reported by:vrai at moechofe dot com
Summary:__halt_compiler and imported namespaces
Status: Assigned
Type: Bug
Package:Compile Failure
Operating System: Ubuntu 11.01 2.6.38-8-generic
PHP Version:5.3.6
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug_54804_with_test.diff
Revision: 1305803069
URL:
http://bugs.php.net/patch-display.php?bug=54804patch=bug_54804_with_test.diffrevision=1305803069
Previous Comments:
[2011-05-19 12:57:15] paj...@php.net
Can you add a test case please?
[2011-05-19 12:46:34] pierr...@php.net
The following patch has been added/updated:
Patch Name: bug_54804
Revision: 1305801994
URL:
http://bugs.php.net/patch-display.php?bug=54804patch=bug_54804revision=1305801994
[2011-05-18 09:58:15] vrai at moechofe dot com
Description:
When importing namespace in a script using the __halt_compiler()
function, the imported script must use the same type of declaration
(bracketed namespace or unbracketed namespace).
Test script:
---
a.php
?php
namespace a;
require_once 'b.php';
echo 'ok',PHP_EOL;
__halt_compiler(); // Remove this line and the script will works.
b.php
?php
namespace b\c {}
namespace b\d {}
Expected result:
ok
Actual result:
--
Fatal error: Cannot mix bracketed namespace declarations with
unbracketed namespace declarations in b.php on line 2
--
Edit this bug report at http://bugs.php.net/bug.php?id=54804edit=1
[PHP-BUG] Req #54861 [NEW]: query() optionaly prepared and PDO::PARAM_FIELDNAME(quoting)
From:
Operating system: linux
PHP version: 5.3.6
Package: PDO related
Bug Type: Feature/Change Request
Bug description:query() optionaly prepared and PDO::PARAM_FIELDNAME(quoting)
Description:
I like prepared statements and its templating. Since query returns a
statement, why not making it a prepared one, when the second parameter is
an array, and execute it directly... Example: See my exPDO-Class at the
bottom.
Since mysql quotes fieldnames(and tablenames) different then
standardconform sqlservers, it is not easy to write/generate sql that work
everywhere... Eg. postgre lowercases fieldnames when they are not quoted in
... Mysql wants `...
I help my self by deriving from PDO and overwrite quote...
public function quote($txt,$parameter_type = PDO::PARAM_STR ){
if($parameter_type == 12345){
if($this-getAttribute(PDO::ATTR_DRIVER_NAME) ==
'mysql'){
return '`' . $txt . '`';
}else{
return '' . $txt . '';
}
}else{
return parent::quote($txt,$parameter_type);
}
}
By the way: Here is my hole extention Now it is possible to see all the
executed querys, and the time it took to get the result
?php
class extPDO extends PDO{
public $query_count = 0;
public $exec_count = 0;
public $prepared_count = 0;
public $query_time = 0;
public $sqls = array();
public function __construct($dsn, $username, $passwd, $options=array()){
parent::__construct($dsn, $username, $passwd, $options);
self::setAttribute(PDO::ATTR_STATEMENT_CLASS,
array(extPDOStatement,array($this)));
}
public function query($statement,$args = array()){
$this-query_count++;
if(is_array($args)){
if(empty($args)){
$this-sqls[] = 'q: '.$statement;
$start = microtime(true);
$res = parent::query($statement);
$this-query_time += microtime(true) - $start;
return $res;
}else{
//keine zeitmessung da diese durchs statement
übernomen wird
$res = self::prepare($statement);
$res-execute($args);
$this-prepared_count--;
return $res;
}
}else{
$res = parent::prepare($statement);
$res-execute(array($args));
$this-prepared_count--;
return $res;
}
}
public function exec($statement,$args = array()){
$this-exec_count++;
if(is_array($args)){
if(empty($args)){
$this-sqls[] = 'e: '. $statement;
$start = microtime(true);
$res = parent::exec($statement);
$this-query_time += microtime(true) - $start;
return $res;
}else{
$res = self::prepare($statement);
$res-execute($args);
$this-prepared_count--;
return $res-rowCount();
}
}else{
$res = self::prepare($statement);
$res-execute( array($args) );
$this-prepared_count--;
return $res-rowCount();
}
}
public function quote($txt,$parameter_type = PDO::PARAM_STR ){
if($parameter_type == 12345){
if($this-getAttribute(PDO::ATTR_DRIVER_NAME) ==
'mysql'){
return '`' . $txt . '`';
}else{
return '' . $txt . '';
}
}else{
return parent::quote($txt,$parameter_type);
}
}
public function prepare($statement,array $options = array()){
return parent::prepare($statement,$options);
}
}
class extPDOStatement extends PDOStatement{
private $db;
protected function __construct($db){
$this-db = $db;
}
public function execute(array $input_parameters = array()){
$this-db-sqls[] = 'p:
Bug #54860 [Com]: PHP crash when using closures + extract(EXTR_REFS)
Edit report at http://bugs.php.net/bug.php?id=54860edit=1
ID: 54860
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:PHP crash when using closures + extract(EXTR_REFS)
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[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=54860edit=1
[PHP-BUG] Req #54862 [NEW]: Type hinting for documentation
From:
Operating system:
PHP version: 5.3.6
Package: Variables related
Bug Type: Feature/Change Request
Bug description:Type hinting for documentation
Description:
Since the dawn of time the PHP documentation has contained function
declarations like this:
string strstr ( string $haystack , mixed $needle [, bool $before_needle =
false ] )
But the PHP parser does not allow this syntax. Many people have been trying
to get proper type hinting into PHP for some time now, and I appreciate
some of the problems in doing so (although it really is needed ASAP).
However, as far as I'm concerned, a good 60% of the reason for wanting type
hinting is for documentation purposes, and readability. Until the type
hinting is implemented fully, please can we at least allow the PHP parser
to accept the type hinting keywords for documentation purposes.
At the moment I'm on the verge of writing an extended PHP language with
type hinting that compiles to PHP by removing the type keywords. That's
completely insane, but the current situation leaves no choice.
Thanks.
Test script:
---
function int foo(bool bar, string baz) { }
Expected result:
The PHP parser should at least accept this syntax, even if it's not used
yet.
Actual result:
--
Parse error.
--
Edit bug report at http://bugs.php.net/bug.php?id=54862edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54862r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54862r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54862r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54862r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54862r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54862r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54862r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54862r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54862r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54862r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54862r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54862r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54862r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54862r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54862r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54862r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54862r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54862r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54862r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54862r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54862r=mysqlcfg
Bug #54851 [Com]: DateTime::createFromFormat, $format=='D' or $format=='l' Always Returns Today.
Edit report at http://bugs.php.net/bug.php?id=54851edit=1
ID: 54851
Comment by: mats dot lindh at gmail dot com
Reported by:phpbugs at nicholassloan dot com
Summary:DateTime::createFromFormat, $format=='D' or
$format=='l' Always Returns Today.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:trunk-SVN-2011-05-18 (SVN)
Block user comment: N
Private report: N
New Comment:
The issue seems to be that there is currently no parsing done for the
D/l parameters. I've added a patch and a test that seems to fix the
issue.
Previous Comments:
[2011-05-19 00:51:31] phpbugs at nicholassloan dot com
Description:
If the format only includes a day string ('D' or 'l'), it is ignored,
and a
DateTime instance for the current date/time is returned. Maybe I'm a
stupid idiot,
but I would expect either an error, or for it to return a DateTime
object for the
next occurrence of the given day (similar to
\DateTime::__construct('Monday');)
Test script:
---
?php
$date = new \DateTime('tomorrow');
$date2 = \DateTime::createFromFormat('D', $date-format('D'));
var_dump($date);
var_dump($date-format('D'));
var_dump($date2);
var_dump($date2-format('D'));
Expected result:
I expect the same date/day to be selected in both cases.
Actual result:
--
object(DateTime)#1 (3) {
[date]=
string(19) 2011-05-19 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/New_York
}
string(3) Thu
object(DateTime)#2 (3) {
[date]=
string(19) 2011-05-18 18:49:33
[timezone_type]=
int(3)
[timezone]=
string(16) America/New_York
}
string(3) Wed
--
Edit this bug report at http://bugs.php.net/bug.php?id=54851edit=1
Bug #35895 [Com]: __sleep and private property
Edit report at http://bugs.php.net/bug.php?id=35895edit=1
ID: 35895
Comment by: info at strictcoding dot co dot uk
Reported by:f dot hardy at origami-systems dot com
Summary:__sleep and private property
Status: No Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Freebsd 6
PHP Version:5.1.2
Block user comment: N
Private report: N
New Comment:
Same problem, 5 years later. Could anyone re-open this bug?
PHP 5.3.5, Windows.
Previous Comments:
[2011-02-20 16:35:47] somiara at hotmail dot com
No comment. Same problem. 2011...
Apache/Windows: php-version 5.2.4
Apache/RH: php-version 5.3.1
Notice: serialize() [function.serialize]: module_instancename returned
as member variable from __sleep() but does not exist in...
[2006-09-01 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-08-24 10:11:37] tony2...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-08-24 09:47:27] f dot hardy at origami-systems dot com
Bug is always alive in php 5.1.5 under freebsd 6.0.
[2006-06-18 17:43:46] jona at oismail dot com
Reproduced on Windows 2000 when using __sleept() with aggregated objects
as private memembers.
The bug has been reproduced in both PHP 5.2-dev (from link below) and
PHP 5.1.4.
The following script can be used to reproduce the error:
?php
class TestParent
{
private $parentPrivateVar;
protected $parentProtectedVar;
public $parentPublicVar;
public function __construct($private, $protected, $public)
{
$this-parentPrivateVar = $private;
$this-parentProtectedVar = $protected;
$this-parentPublicVar = $public;
}
function __sleep()
{
return array(parentPrivateVar, parentProtectedVar,
parentPublicVar);
}
}
class TestChild extends TestParent
{
private $childPrivateVar;
protected $childProtectedVar;
public $childPublicVar;
public function __construct($private, $protected, $public)
{
$this-childPrivateVar = child_. $private;
$this-childProtectedVar = child_. $protected;
$this-childPublicVar = child_. $public;
parent::__construct(parent_. $private, parent_. $protected,
parent_. $public);
}
function __sleep()
{
return array_merge(array(childPrivateVar, childProtectedVar,
childPublicVar), parent::__sleep() );
}
}
class WebSession
{
private $privateVar;
private $privateAggregatedObject;
public function __construct($private, TestChild $o)
{
$this-privateVar = $private;
$this-privateAggregatedObject = $o;
}
public function __sleep() { return array(privateVar,
privateAggregatedObject); }
public function getPrivateVar() { return $this-privateVar; }
public function getObject() { return $this-privateAggregatedObject; }
}
// Report simple running errors
error_reporting(E_ERROR | E_PARSE | E_WARNING | E_NOTICE | E_STRICT |
E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE);
// Start user session
session_start();
if(isset($_SESSION['obj_Info']) === false)
{
$_SESSION['obj_Info'] = new WebSession(private variable, new
TestChild(private, protected, public) );
}
echo pre;
var_dump($_SESSION['obj_Info']);
echo /pre;
echo hr /;
echo TEST: . $_SESSION['obj_Info']-getPrivateVar() .br /;
echo OBJECT: . $_SESSION['obj_Info']-getObject() .br /;
echo OBJECT PUBLIC VAR: .
$_SESSION['obj_Info']-getObject()-childPublicVar .br /;
?
GIVES THE FOLLOWING OUTPUT IN PHP 5.1.4:
object(WebSession)#1 (2) {
[PHP-BUG] Bug #54863 [NEW]: pg_query_params not returning value from PostgreSQL rule
From:
Operating system: Linux 2.6
PHP version: 5.3.6
Package: PostgreSQL related
Bug Type: Bug
Bug description:pg_query_params not returning value from PostgreSQL rule
Description:
When using a PostgreSQL rule to return a value on an INSERT, pg_query's
return is a resource that contains the correct information, while
pg_query_params's return is empty/null.
Tested and confirmed on:
'Linux 2.6.18-194.17.1.el5 #1 SMP Mon Sep 20 07:12:06 EDT 2010 x86_64
x86_64 x86_64 GNU/Linux' running PHP 5.3.5-1 [Note: Production server -
can't upgrade myself for testing]
and on
'Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686
i686 i386 GNU/Linux' virtual machine running PHP 5.3.5-1 and then also
tested against 5.3.6 compiled from source.
Test script:
---
Database setup:
CREATE DATABASE test WITH OWNER = postgres ENCODING = 'UTF8' LC_COLLATE
= 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1;
CREATE SEQUENCE widget_id_seq INCREMENT 1 MINVALUE 1 MAXVALUE
9223372036854775807 START 1 CACHE 1;
ALTER TABLE widget_id_seq OWNER TO postgres;
CREATE TABLE widget ( id serial NOT NULL, widgetname character
varying(20) NOT NULL, inserttime timestamp without time zone NOT NULL,
CONSTRAINT widget_pkey PRIMARY KEY (id) ) WITH ( OIDS=FALSE );
ALTER TABLE widget OWNER TO postgres;
CREATE OR REPLACE RULE get_widget_id_on_insert AS ON INSERT TO widget
DO SELECT currval('widget_id_seq'::text::regclass) AS id;
PHP test script:
?php
$db_connection = pg_connect(host=localhost dbname=test
user=postgres);
$good_query = INSERT INTO widget (widgetname, inserttime) VALUES
('Good Test Widget', NOW());
$good_result_ref = pg_query($db_connection, $good_query);
$good_result_data = pg_fetch_array($good_result_ref);
echo 'Good result ID:' . $good_result_data['id'] . \n;
$bad_query = 'INSERT INTO widget (widgetname, inserttime) VALUES ($1,
NOW())';
$bad_params = array('Bad Test Widget');
$bad_result_ref = pg_query_params($db_connection, $bad_query,
$bad_params);
$bad_result_data = pg_fetch_array($bad_result_ref);
echo 'Bad result ID:' . $bad_result_data['id'] . \n;
pg_close($db_connection);
exit;
?
Expected result:
(Note: The difference between this and the actual result is that Bad
result ID: has an integer value (its id) accessible)
[justin@mybox ~]$ php rule_failure.php
Good result ID:1
Bad result ID:2
[justin@mybox ~]$ php rule_failure.php
Good result ID:3
Bad result ID:4
[justin@mybox ~]$ psql --dbname test --user postgres
psql (8.4.7)
Type help for help.
test=# SELECT * FROM widget;
id |widgetname| inserttime
+--+
1 | Good Test Widget | 2011-05-18 15:57:22.182711
2 | Bad Test Widget | 2011-05-18 15:57:22.187533
3 | Good Test Widget | 2011-05-18 15:57:26.16656
4 | Bad Test Widget | 2011-05-18 15:57:26.170966
(4 rows)
test=#
Actual result:
--
[justin@mybox ~]$ php rule_failure.php
Good result ID:1
Bad result ID:
[justin@mybox ~]$ php rule_failure.php
Good result ID:3
Bad result ID:
[justin@mybox ~]$ psql --dbname test --user postgres
psql (8.4.7)
Type help for help.
test=# SELECT * FROM widget;
id |widgetname| inserttime
+--+
1 | Good Test Widget | 2011-05-18 15:57:22.182711
2 | Bad Test Widget | 2011-05-18 15:57:22.187533
3 | Good Test Widget | 2011-05-18 15:57:26.16656
4 | Bad Test Widget | 2011-05-18 15:57:26.170966
(4 rows)
test=#
--
Edit bug report at http://bugs.php.net/bug.php?id=54863edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54863r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54863r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54863r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54863r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54863r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54863r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54863r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54863r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54863r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54863r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54863r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54863r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54863r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54863r=globals
PHP 4
Req #12712 [Com]: named function parameters
Edit report at http://bugs.php.net/bug.php?id=12712edit=1
ID: 12712
Comment by: briank at kappacs dot com
Reported by:martin at semester dot sk
Summary:named function parameters
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
I would like to suggest the following syntax:
function f ($un1, $un2, $un3 = 'default',
'hello' = 'goodbye', 'planet' = 'earth') {
# $_FUNCARGS is a magic local short-hand for func_get_args()
var_dump($_FUNCARGS);
}
When called as:
f('one', 'named' = 'param', 'two', 5 = 'works', 'hello' = 'world',
'too');
... the equivalent of this would happen behind the scenes:
# (The order and position of the *named* parameters here are just
# an example and not necessarily what PHP might implement)
$_FUNCARGS = array(0 = 'one', 1 = 'two', 2 = 'default', 5 =
'works',
6 = 'too', 'named' = 'param', 'hello' = 'world', 'planet' =
'earth');
$un1 = $_FUNCARGS[0];
$un2 = $_FUNCARGS[1];
$un3 = $_FUNCARGS[2];
The bottom line is that the parameters look like an array(), with
both numeric and string keys, in any order, just like an array.
For readability, developers should probably put the unnamed parameters
before the named parameters just as a matter of style (for both
function
calls and declarations), but the PHP engine should take them as they
come.
Previous Comments:
[2010-12-13 18:18:40] giecrilj at stegny dot 2a dot pl
There is no need to change the function declaration.
Consider this syntax:
printhello (bold = true, name = 'Martin');
and let the compiler translate it to
printhello ('Martin', true)
given the traditional declaration.
[2008-08-27 08:37:51] coder at muctr dot edu dot ru
Would like to add the reason.
In medium to big projects (when many developers are involved) this
feature could be of a great help. Because the code could be written in
self-documenting manner.
E.g. compare
$html = formatSomeData( $data, true, false, true, 10 );
to
$html = formatSomeData( entity_x: $data, italic: true, bold: false,
monospace: true, fontSize: 10 );
In the second case one doesn't have to search for formatSomeData()
definition to start using it.
[2001-08-13 04:05:59] martin at semester dot sk
Good day. It is not a really bug report but a little suggestion for new
PHP relase. I'll be good thing to add to PHP
language ability to create functions with named parameters like in
Visual Basic. For example:
//Classic function:
function printhello($name, $bold = false, $italic = false)
{
$ret = Hello $name!
if ($bold)
$ret = strong$ret/strong;
if ($italic)
$ret = em$ret/em;
echo $ret;
}
//Suggested function:
function printhello(name: $name, fat: $bold = false, emphased: $italic =
false)
{
// same body as above ...
}
This new function could be called like: printhello(Martin, true);
or like new: printhello(fat: true, name: Martin);
Thank you.
--
Edit this bug report at http://bugs.php.net/bug.php?id=12712edit=1
Req #54862 [Opn-Bgs]: Type hinting for documentation
Edit report at http://bugs.php.net/bug.php?id=54862edit=1
ID: 54862
Updated by: ras...@php.net
Reported by:simon at systemparadox dot co dot uk
Summary:Type hinting for documentation
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:Variables related
PHP Version:5.3.6
-Block user comment: No
+Block user comment: Yes
Private report: N
New Comment:
The issue is that scalar types are interchangeable in PHP out of
necessity. The
Web is not typed. Everything comes across the wire from the browser as a
string.
Once you start forcing string or integer in function calls you are
pushing the
type juggling to the caller instead of leaving it with the receiver
where it
belongs. Type hinting for non-scalar non-interchangeable types doesn't
break
thing which is why it is in.
Previous Comments:
[2011-05-19 14:17:14] simon at systemparadox dot co dot uk
Description:
Since the dawn of time the PHP documentation has contained function
declarations like this:
string strstr ( string $haystack , mixed $needle [, bool $before_needle
= false ] )
But the PHP parser does not allow this syntax. Many people have been
trying to get proper type hinting into PHP for some time now, and I
appreciate some of the problems in doing so (although it really is
needed ASAP).
However, as far as I'm concerned, a good 60% of the reason for wanting
type hinting is for documentation purposes, and readability. Until the
type hinting is implemented fully, please can we at least allow the PHP
parser to accept the type hinting keywords for documentation purposes.
At the moment I'm on the verge of writing an extended PHP language with
type hinting that compiles to PHP by removing the type keywords. That's
completely insane, but the current situation leaves no choice.
Thanks.
Test script:
---
function int foo(bool bar, string baz) { }
Expected result:
The PHP parser should at least accept this syntax, even if it's not used
yet.
Actual result:
--
Parse error.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54862edit=1
[PHP-BUG] Bug #54864 [NEW]: Memory leak associated with mysql connector
From:
Operating system: FreeBSD
PHP version: 5.3.6
Package: MySQLi related
Bug Type: Bug
Bug description:Memory leak associated with mysql connector
Description:
I have found a memory leak in connection with several production PHP
scripts.
While there are many bug reports relating to memory leaks, I did not find
anything similar to our situation, which is very easy to reproduce.
The scripts that have been affected by this memory leak have been in
continuous
production use since 2006. We did not notice a memory leak prior to when we
first upgraded to PHP 5.3.5. It is possible that there was a smaller leak
prior
to this time that merely escaped notice. However, before reporting the
problem,
we upgraded to 5.3.6 to make sure it had not been corrected. The results in
this
ticket are thus for 5.3.6.
Below I have given the main loop of a small reproducible code. As you can
see,
the only thing done in this test is to fetch the rows, and print out memory
usage every 3000 rows.
Regarding the mysql connector: originally the test was run with
mysqli_connect.
It was suggested via Experts-Exchange to try the mysql_connector. This was
done
but the results were identical. The full script can works with both
mysql_connect and mysqli_connect, controlled by a define.
The bug signs:
1. On 5.3.6, the after SQL memory usage jumps to 13MB, whereas on 5.2.4
it
stays at the initial low value (262144 on 5.2.4 but 786432 on 5.3.6).
2. On 5.3.6, the memory usage grows dramatically, whereas on 5.2.4 it does
not
(the id lines are displayed after each 3000 rows, where the id is the
primary
key for the row). In the production scripts, this leads to a crash when the
memory limit is exceeded.
Please note:
1. the SQL statement is composed of a UNION of 5 relatively simple SELECTs,
making the single statement relatively complex.
2. The expected and actual results shown below are achieved by connecting
to the
same database.
I you would like the URL of the actual script, which has the connection
routines
and the SQL (which is relatively complex), please let me know as I would
have to
remove the passwords, etc. I could also send a mysqldump of a sanitized
version
of the database. The bzip2 of the dump file is about 35MB.
Test script:
---
echo Test Autoemail Memory Leak\n;
echo 'start run mem=' . memory_get_usage(true) . \n;
$query = get_query();
$rs = SQL($link, $query);
if ($rs)
{
// main loop
$cnt = 0;
echo 'after SQL mem=' . memory_get_usage(true) . \n;
$func = (MYSQL_ENHANCED) ? 'mysqli_fetch_row' : 'mysql_fetch_row';
while($row = $func($rs))
{
if (++$cnt % 3000 == 0)
{
echo ' id=' . $row[1] . ' mem=' .
memory_get_usage(true) . \n;
}
}
echo EOJ\n;
}
else
{
echo $errmsg;
}
Full script is at http://www.rephunter.net/test-autoemail-memory.php. The
web server will execute the script if accessed in a browser.
Expected result:
Showing no leak on Windows VM PHP 5.2.4 connecting to same database
F:\Websites\RepHunter\currentphp -v
PHP 5.2.4 (cli) (built: Oct 1 2007 20:06:42)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Zend Core v2.5.0, Copyright (c) 1998-2006, by Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
Technol
ogies
with Zend Optimizer v3.3.1, Copyright (c) 1998-2007, by Zend
Technologies
with Zend Debugger v5.2.10, Copyright (c) 1999-2007, by Zend
Technologies
F:\Websites\RepHunter\currentphp test-autoemail-memory.php
Test Autoemail Memory Leak
Using mysqli_connect
start run mem=262144
after SQL mem=262144
id=43655 mem=262144
id=40250 mem=262144
id=37355 mem=262144
id=34419 mem=262144
id=31544 mem=262144
id=28915 mem=262144
id=26168 mem=262144
id=21461 mem=262144
id=16550 mem=262144
id=13074 mem=262144
id=9140 mem=262144
id=3892 mem=262144
EOJ
F:\Websites\RepHunter\current
Actual result:
--
Showing the leak on 5.3.6
[jas1@www /var/www/rephunter/www/webroot]$ php -v
PHP 5.3.6 with Suhosin-Patch (cli) (built: May 13 2011 21:58:30)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
[jas1@www /var/www/rephunter/www/webroot]$ php ./test-autoemail-memory.php
Test Autoemail Memory Leak
Using mysqli_connect
start run mem=786432
after SQL mem=13631488
id=43655 mem=23592960
id=40250 mem=33292288
id=37355 mem=43253760
id=34419 mem=52953088
id=31544 mem=62914560
id=28915 mem=72613888
id=26168 mem=82575360
id=21461 mem=92274688
id=16550 mem=102236160
id=13074 mem=112197632
id=9140 mem=121896960
[PHP-BUG] Req #54865 [NEW]: Child process inherits parent priority
From: Operating system: Windows Server 2008 R2 PHP version: 5.3.6 Package: Program Execution Bug Type: Feature/Change Request Bug description:Child process inherits parent priority Description: I'm running PHP in above-normal priority and would like to have child processes of it, spawned using proc_open, to inherit that priority level. In Windows I believe this should just be a matter of running: SetPriorityClass( GetCurrentProcess(), desired_priority ); I'm not sure if this is a bug report or a feature request though, I guess it depends on how you view it. Test script: --- $path = c:\\windows\\system32\\notepad.exe; $descriptorspec = array(); $cwd = c:\\windows\\temp; $env = NULL; $other_options = array( 'bypass_shell' = FALSE, ); $resource = proc_open( $path, $descriptorspec, $pipes, $cwd, $env, $other_options ); Expected result: I expect the notepad.exe to have the abovenormal priority level, which is what the parent php script was running at. Actual result: -- notepad.exe runs at the normal priority level. -- Edit bug report at http://bugs.php.net/bug.php?id=54865edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54865r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54865r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54865r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54865r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54865r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54865r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54865r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54865r=needscript Try newer version: http://bugs.php.net/fix.php?id=54865r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54865r=support Expected behavior: http://bugs.php.net/fix.php?id=54865r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54865r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54865r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54865r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54865r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54865r=dst IIS Stability: http://bugs.php.net/fix.php?id=54865r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54865r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54865r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54865r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54865r=mysqlcfg
Req #42060 [Fbk]: [PATCH] LDAP: Add pagedResults support and more
Edit report at http://bugs.php.net/bug.php?id=42060edit=1
ID: 42060
Updated by: scott...@php.net
Reported by:iarenuno at eteo dot mondragon dot edu
Summary:[PATCH] LDAP: Add pagedResults support and more
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:5CVS, 6CVS (2008-11-01)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I applied the rename patch and tidied up the code a little.
Anything else that needs done here?
Previous Comments:
[2011-05-19 19:41:24] scott...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=311264
Log: Tidy up ldap paging code and rename the API as discussed in #42060
[2011-05-18 14:33:32] jeanseb at au-fil-du dot net
Can we expect to see ext-ldap-review.patch and api-rename.patch applied
on trunk and PHP5.4 branch ?
Thanks.
[2011-04-29 01:20:55] bryant dot david at gmail dot com
Hey guys,
I was not able to get the patches on this page to work, and paged
results was a must-have for our installation. I took
jeanseb's patch (great work by the way - thank you!) and modified it. I
got it to work with the 5.3 build from 04/28/2011
(over at http://snaps.php.net), but I am NOT a C developer by trade, so
I'm very open to *constructive* criticism.
Here's a breakdown of how to get it installed (since I just had to go
through all this myself).
- Obviously, you're going to be compiling PHP, so download the
appropriate version for your platform. (again, this patch
is for 5.3)
- Once you've got it compiling OK, install the (attached) patch,
paged-ldap-5.3, by doing the following (I'm on a Mac -
you're on own if your in Windows, sorry): cd into ext/ldap in your PHP
source directory and run
patch /path/to/paged-ldap-5.3
- Recompile
Assuming all went well, here's a modified version of jeanseb's script to
test it:
?php
$ds = ldap_connect('ad.example.com');
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_bind($ds, 'CN=myaccount,OU=users,DC=ad,DC=example,DC=com',
'password');
$pageSize= 100;
$cookie = '';
do {
ldap_control_paged_results($ds, $pageSize, true, $cookie);
$result = ldap_search($ds, 'OU=users,DC=ad,DC=example,DC=com',
'cn=*', array('sAMAccountName'));
$entries = ldap_get_entries($ds, $result);
foreach($entries as $e)
print $e[dn] . \n;
ldap_control_paged_results_response($ds, $result, $cookie);
} while($cookie !== null $cookie != '');
?
Good luck! And please, can we get paged LDAP support in some form or
another committed?
[2011-03-21 21:43:08] liveoutloud2day at gmail dot com
Can this be committed? Please? Pretty Please?
[2007-07-21 13:52 UTC] is a long time ago. Can this get committed to
code that can become the next version of PHP?
This just adds optional arguments to a call that you won't use unless
you know what you are doing. It won't break anything else. Can it
please get committed?
Is there anything I can do to help get it committed to the trunk?
Thanks!
[2010-12-10 14:43:07] paj...@php.net
It will be done when it is done. There is no real hurry. I was busy with
other branches than trunk, in case you missed the recent releases.
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=42060
--
Edit this bug report at http://bugs.php.net/bug.php?id=42060edit=1
[PHP-BUG] Bug #54866 [NEW]: incorrect accounting for realpath_cache_size
From:
Operating system: Linux
PHP version: 5.3.6
Package: *Directory/Filesystem functions
Bug Type: Bug
Bug description:incorrect accounting for realpath_cache_size
Description:
When items are removed from the realpath_cache, if the path is the same as
the
realpath, then the incorrect size is subtracted from realpath_cache_size.
This is due to the realpath_cache_add function. If the realpath and the
path are
the same, then an optimization occurs where bucket-realpath is assigned to
the
same location as bucket-path (so there's no copy being done). The size
added to
realpath_cache_size takes this into account, but not when removing.
This can cause the size to be incorrect and also be negative.
I've submitted a patch and some test code.
Test script:
---
?php
// set the ini options to more easily reproduce
// realpath_cache_ttl = 1
// realpath_cache_siz = 16K
for($i = 0; $i 5000; $i++) {
file_put_contents(/tmp/foo-$i.txt, );
clearstatcache(true, /tmp/foo-$i.txt);
echo $i - stat cache is: .realpath_cache_size().\n;
if(realpath_cache_size() 0) {
print Hit realpath_cache_size bug\n;
break;
}
}
// clean up created files
for ($x = 0; $x $i; $x++) {
unlink(/tmp/foo-$x.txt);
}
Expected result:
If bug is present it should output 'Hit realpath_cache_size bug'
--
Edit bug report at http://bugs.php.net/bug.php?id=54866edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54866r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54866r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54866r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54866r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54866r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54866r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54866r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54866r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54866r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54866r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54866r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54866r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54866r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54866r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54866r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54866r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54866r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54866r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54866r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54866r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54866r=mysqlcfg
Req #49806 [Com]: proc_nice() for Windows
Edit report at http://bugs.php.net/bug.php?id=49806edit=1 ID: 49806 Comment by: matt at wootkit dot com Reported by:ka...@php.net Summary:proc_nice() for Windows Status: Assigned Type: Feature/Change Request Package:Program Execution Operating System: Windows PHP Version:6SVN-2009-10-07 (SVN) Assigned To:pajoye Block user comment: N Private report: N New Comment: I'd also like to see this function added. This would be very useful, especially in reference to request #54865 (http://bugs.php.net/bug.php?id=54865) Previous Comments: [2009-10-07 20:20:54] ka...@php.net Description: As discussed with Pierre and sent to the internals-win ML, then here is a patch for enabling proc_nice() under Windows. This patch is abit modified from the version sent to the ML and is added into TSRM like popen. Patch is made for trunk: http://pastie.org/645963 -- Edit this bug report at http://bugs.php.net/bug.php?id=49806edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1 ID: 50410 Comment by: brian at access9 dot net Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Closed Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl extension enabled. I can also confirm that tanguy's libeay32.dll fixes the issue. Previous Comments: [2011-04-11 11:28:41] threedigitnumber at gmail dot com My tests indicate that something is still going on with 5.3.6: tanguy's ssleay fixes the issue. [2011-04-11 11:08:35] paj...@php.net 5.3.6's does not use rand_screen anymore and any version of libcurl after this date either. [2011-04-11 07:42:14] tanguy at pruvot dot tk arf, link was truncated : http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl [2011-04-11 05:39:10] tanguy at pruvot dot tk You can download the patched libeay here (work for all PHP versions) : http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au- chargement-de-phpcurl [2011-04-11 05:29:56] threedigitnumber at gmail dot com Still not solved with 5.36. In CLI Mode with curl: php -v takes 1.15 seconds. without curl: php -v takes 0.125 seconds. 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=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410edit=1
Bug #50410 [Csd-Fbk]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1 ID: 50410 Updated by: paj...@php.net Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP -Status: Closed +Status: Feedback Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye 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/ Previous Comments: [2011-05-20 00:01:09] brian at access9 dot net Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl extension enabled. I can also confirm that tanguy's libeay32.dll fixes the issue. [2011-04-11 11:28:41] threedigitnumber at gmail dot com My tests indicate that something is still going on with 5.3.6: tanguy's ssleay fixes the issue. [2011-04-11 11:08:35] paj...@php.net 5.3.6's does not use rand_screen anymore and any version of libcurl after this date either. [2011-04-11 07:42:14] tanguy at pruvot dot tk arf, link was truncated : http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl [2011-04-11 05:39:10] tanguy at pruvot dot tk You can download the patched libeay here (work for all PHP versions) : http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au- chargement-de-phpcurl 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=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1
ID: 50410
Comment by: tanguy dot pruvot at gmail dot com
Reported by:procyonar at gmail dot com
Summary:curl extension slows down PHP
Status: Feedback
Type: Bug
Package:cURL related
Operating System: win32 only - Windows 7
PHP Version:*
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Thanks, will check
Here is my last way to fix it (if openssl is already enabled in php)
PHP 5.3.6 VC9 x86 module without SSL Library Init
-
tanguy.pru...@gmail.com - 06 May 2011
The curl module slow down PHP init on Windows since PHP 5.2
The docs might be a bit sparse in this ares, yes. But the SSL bit should
be set
unless you have initialized the OpenSSL library already in some other
way.
And in fact the openssl module already do library init, so if loaded,
this patch
should not impact security
PHP_MINIT_FUNCTION(openssl)
...
SSL_library_init();
It is possible to fix that in extension code, in interface.c :
by replacing CURL_GLOBAL_SSL by CURL_GLOBAL_WIN32...
if (curl_global_init(CURL_GLOBAL_WIN32) != CURLE_OK) {
return FAILURE;
}
Related discussion :
http://http://bugs.php.net/bug.php?id=53578
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl
(french)
http://osdir.com/ml/web.curl.general/2004-05/msg00068.html
http://curl.haxx.se/mail/lib-2004-06/0133.html
Previous Comments:
[2011-05-20 00:05:09] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2011-05-20 00:01:09] brian at access9 dot net
Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl
extension enabled. I can also confirm that tanguy's libeay32.dll fixes
the issue.
[2011-04-11 11:28:41] threedigitnumber at gmail dot com
My tests indicate that something is still going on with 5.3.6: tanguy's
ssleay fixes the issue.
[2011-04-11 11:08:35] paj...@php.net
5.3.6's does not use rand_screen anymore and any version of libcurl
after this
date either.
[2011-04-11 07:42:14] tanguy at pruvot dot tk
arf, link was truncated :
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl
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=50410
--
Edit this bug report at http://bugs.php.net/bug.php?id=50410edit=1
Bug #50410 [Fbk]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1
ID: 50410
Updated by: paj...@php.net
Reported by:procyonar at gmail dot com
Summary:curl extension slows down PHP
Status: Feedback
Type: Bug
Package:cURL related
Operating System: win32 only - Windows 7
PHP Version:*
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Simply try a snapshot, I double check and no call are done to
Rand_Screen co (so
it is in libcurl latest release).
Previous Comments:
[2011-05-20 00:33:45] tanguy dot pruvot at gmail dot com
Thanks, will check
Here is my last way to fix it (if openssl is already enabled in php)
PHP 5.3.6 VC9 x86 module without SSL Library Init
-
tanguy.pru...@gmail.com - 06 May 2011
The curl module slow down PHP init on Windows since PHP 5.2
The docs might be a bit sparse in this ares, yes. But the SSL bit should
be set
unless you have initialized the OpenSSL library already in some other
way.
And in fact the openssl module already do library init, so if loaded,
this patch
should not impact security
PHP_MINIT_FUNCTION(openssl)
...
SSL_library_init();
It is possible to fix that in extension code, in interface.c :
by replacing CURL_GLOBAL_SSL by CURL_GLOBAL_WIN32...
if (curl_global_init(CURL_GLOBAL_WIN32) != CURLE_OK) {
return FAILURE;
}
Related discussion :
http://http://bugs.php.net/bug.php?id=53578
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl
(french)
http://osdir.com/ml/web.curl.general/2004-05/msg00068.html
http://curl.haxx.se/mail/lib-2004-06/0133.html
[2011-05-20 00:05:09] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2011-05-20 00:01:09] brian at access9 dot net
Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl
extension enabled. I can also confirm that tanguy's libeay32.dll fixes
the issue.
[2011-04-11 11:28:41] threedigitnumber at gmail dot com
My tests indicate that something is still going on with 5.3.6: tanguy's
ssleay fixes the issue.
[2011-04-11 11:08:35] paj...@php.net
5.3.6's does not use rand_screen anymore and any version of libcurl
after this
date either.
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=50410
--
Edit this bug report at http://bugs.php.net/bug.php?id=50410edit=1
Bug #54866 [Opn-Csd]: incorrect accounting for realpath_cache_size
Edit report at http://bugs.php.net/bug.php?id=54866edit=1
ID: 54866
Updated by: ras...@php.net
Reported by:dustin dot ward1 at gmail dot com
Summary:incorrect accounting for realpath_cache_size
-Status: Open
+Status: Closed
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Linux
PHP Version:5.3.6
-Assigned To:
+Assigned To:rasmus
Block user comment: N
Private report: N
New Comment:
Thank you very much for the concise bug report and clean patch. It has
been
applied to all active branches. If you come across anything else, please
go to
http://php.net/svn-php.php to get an SVN account so you can commit the
fixes
yourself.
Previous Comments:
[2011-05-20 01:10:00] ras...@php.net
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=311274
Log: Fix bug 54866
[2011-05-19 22:04:33] dustin dot ward1 at gmail dot com
Description:
When items are removed from the realpath_cache, if the path is the same
as the
realpath, then the incorrect size is subtracted from
realpath_cache_size.
This is due to the realpath_cache_add function. If the realpath and
the path are
the same, then an optimization occurs where bucket-realpath is assigned
to the
same location as bucket-path (so there's no copy being done). The size
added to
realpath_cache_size takes this into account, but not when removing.
This can cause the size to be incorrect and also be negative.
I've submitted a patch and some test code.
Test script:
---
?php
// set the ini options to more easily reproduce
// realpath_cache_ttl = 1
// realpath_cache_siz = 16K
for($i = 0; $i 5000; $i++) {
file_put_contents(/tmp/foo-$i.txt, );
clearstatcache(true, /tmp/foo-$i.txt);
echo $i - stat cache is: .realpath_cache_size().\n;
if(realpath_cache_size() 0) {
print Hit realpath_cache_size bug\n;
break;
}
}
// clean up created files
for ($x = 0; $x $i; $x++) {
unlink(/tmp/foo-$x.txt);
}
Expected result:
If bug is present it should output 'Hit realpath_cache_size bug'
--
Edit this bug report at http://bugs.php.net/bug.php?id=54866edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1
ID: 50410
Comment by: tanguy dot pruvot at gmail dot com
Reported by:procyonar at gmail dot com
Summary:curl extension slows down PHP
Status: Feedback
Type: Bug
Package:cURL related
Operating System: win32 only - Windows 7
PHP Version:*
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Yes, PEAR is now usable with this version.
Thanks, finally.. almost 2 years since first bug report...
Previous Comments:
[2011-05-20 00:49:15] paj...@php.net
Simply try a snapshot, I double check and no call are done to
Rand_Screen co (so
it is in libcurl latest release).
[2011-05-20 00:33:45] tanguy dot pruvot at gmail dot com
Thanks, will check
Here is my last way to fix it (if openssl is already enabled in php)
PHP 5.3.6 VC9 x86 module without SSL Library Init
-
tanguy.pru...@gmail.com - 06 May 2011
The curl module slow down PHP init on Windows since PHP 5.2
The docs might be a bit sparse in this ares, yes. But the SSL bit should
be set
unless you have initialized the OpenSSL library already in some other
way.
And in fact the openssl module already do library init, so if loaded,
this patch
should not impact security
PHP_MINIT_FUNCTION(openssl)
...
SSL_library_init();
It is possible to fix that in extension code, in interface.c :
by replacing CURL_GLOBAL_SSL by CURL_GLOBAL_WIN32...
if (curl_global_init(CURL_GLOBAL_WIN32) != CURLE_OK) {
return FAILURE;
}
Related discussion :
http://http://bugs.php.net/bug.php?id=53578
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl
(french)
http://osdir.com/ml/web.curl.general/2004-05/msg00068.html
http://curl.haxx.se/mail/lib-2004-06/0133.html
[2011-05-20 00:05:09] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2011-05-20 00:01:09] brian at access9 dot net
Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl
extension enabled. I can also confirm that tanguy's libeay32.dll fixes
the issue.
[2011-04-11 11:28:41] threedigitnumber at gmail dot com
My tests indicate that something is still going on with 5.3.6: tanguy's
ssleay fixes the issue.
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=50410
--
Edit this bug report at http://bugs.php.net/bug.php?id=50410edit=1
Bug #54804 [Asn-Csd]: __halt_compiler and imported namespaces
Edit report at http://bugs.php.net/bug.php?id=54804edit=1
ID: 54804
Updated by: fel...@php.net
Reported by:vrai at moechofe dot com
Summary:__halt_compiler and imported namespaces
-Status: Assigned
+Status: Closed
Type: Bug
Package:Compile Failure
Operating System: Ubuntu 11.01 2.6.38-8-generic
PHP Version:5.3.6
Assigned To:pierrick
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-05-20 01:20:50] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=311276
Log: - Fixed bug #54804 (__halt_compiler and imported namespaces)
(Pierrick)
[2011-05-19 13:04:30] pierr...@php.net
The following patch has been added/updated:
Patch Name: bug_54804_with_test.diff
Revision: 1305803069
URL:
http://bugs.php.net/patch-display.php?bug=54804patch=bug_54804_with_test.diffrevision=1305803069
[2011-05-19 12:57:15] paj...@php.net
Can you add a test case please?
[2011-05-19 12:46:34] pierr...@php.net
The following patch has been added/updated:
Patch Name: bug_54804
Revision: 1305801994
URL:
http://bugs.php.net/patch-display.php?bug=54804patch=bug_54804revision=1305801994
[2011-05-18 09:58:15] vrai at moechofe dot com
Description:
When importing namespace in a script using the __halt_compiler()
function, the imported script must use the same type of declaration
(bracketed namespace or unbracketed namespace).
Test script:
---
a.php
?php
namespace a;
require_once 'b.php';
echo 'ok',PHP_EOL;
__halt_compiler(); // Remove this line and the script will works.
b.php
?php
namespace b\c {}
namespace b\d {}
Expected result:
ok
Actual result:
--
Fatal error: Cannot mix bracketed namespace declarations with
unbracketed namespace declarations in b.php on line 2
--
Edit this bug report at http://bugs.php.net/bug.php?id=54804edit=1
Bug #50410 [Fbk-Csd]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1
ID: 50410
Updated by: paj...@php.net
Reported by:procyonar at gmail dot com
Summary:curl extension slows down PHP
-Status: Feedback
+Status: Closed
Type: Bug
Package:cURL related
Operating System: win32 only - Windows 7
PHP Version:*
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
It was already fixed in some of the 5.3.5 releases and reintroduce in
5.3.6. Also
the bug was not in PHP but libcurl (fixed there too).
Previous Comments:
[2011-05-20 01:10:25] tanguy dot pruvot at gmail dot com
Yes, PEAR is now usable with this version.
Thanks, finally.. almost 2 years since first bug report...
[2011-05-20 00:49:15] paj...@php.net
Simply try a snapshot, I double check and no call are done to
Rand_Screen co (so
it is in libcurl latest release).
[2011-05-20 00:33:45] tanguy dot pruvot at gmail dot com
Thanks, will check
Here is my last way to fix it (if openssl is already enabled in php)
PHP 5.3.6 VC9 x86 module without SSL Library Init
-
tanguy.pru...@gmail.com - 06 May 2011
The curl module slow down PHP init on Windows since PHP 5.2
The docs might be a bit sparse in this ares, yes. But the SSL bit should
be set
unless you have initialized the OpenSSL library already in some other
way.
And in fact the openssl module already do library init, so if loaded,
this patch
should not impact security
PHP_MINIT_FUNCTION(openssl)
...
SSL_library_init();
It is possible to fix that in extension code, in interface.c :
by replacing CURL_GLOBAL_SSL by CURL_GLOBAL_WIN32...
if (curl_global_init(CURL_GLOBAL_WIN32) != CURLE_OK) {
return FAILURE;
}
Related discussion :
http://http://bugs.php.net/bug.php?id=53578
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl
(french)
http://osdir.com/ml/web.curl.general/2004-05/msg00068.html
http://curl.haxx.se/mail/lib-2004-06/0133.html
[2011-05-20 00:05:09] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2011-05-20 00:01:09] brian at access9 dot net
Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl
extension enabled. I can also confirm that tanguy's libeay32.dll fixes
the issue.
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=50410
--
Edit this bug report at http://bugs.php.net/bug.php?id=50410edit=1
Bug #46888 [Com]: copy() : safe_mode / allow_url_fopen does not allow opening urls
Edit report at http://bugs.php.net/bug.php?id=46888edit=1 ID: 46888 Comment by: macmiranda at gmail dot com Reported by:php at degoulet dot net Summary:copy() : safe_mode / allow_url_fopen does not allow opening urls Status: Verified Type: Bug Package:Safe Mode/open_basedir Operating System: * PHP Version:5.2.9 Block user comment: N Private report: N New Comment: same on centos 5.5 php 5.2.17 Previous Comments: [2009-09-01 16:21:41] sjo...@php.net Could reproduce. With safe mode, files which are handled by stream wrappers are checked against the filesystem. This is wrong. [2009-05-15 14:04:27] christian at elmerot dot se You apply the patch using the command patch when you build PHP from the sourcecode. If you've never done this before I cannot recommend that you do this for something like PHP. If you still go ahead, download the PHP sourcecode, extract it and read the files (README and INSTALL). Check documentation for using the patch command (man patch). in general you save the patch to a file (lets call it safemode.patch) then you simply run patch main/safe_mode.c safemode.patch in the folder where you unpacked the source [2009-04-28 13:32:43] neo at nord-style dot com Hello, I've the same problem but I don't understand how use this patch. Actually safe_mode off but it's not a solution. How and Where Am i use this : --- diff -Nur php-5.2.8/main/safe_mode.c php-5.2.8_1/main/safe_mode.c --- php-5.2.8/main/safe_mode.c 2008-07-24 18:01:59.0 +0200 +++ php-5.2.8_1/main/safe_mode.c2008-12-17 15:01:07.502862702 +0100 @@ -52,6 +52,7 @@ long uid=0L, gid=0L, duid=0L, dgid=0L; char path[MAXPATHLEN]; char *s, filenamecopy[MAXPATHLEN]; + php_stream_wrapper *wrapper = NULL; TSRMLS_FETCH(); path[0] = '\0'; @@ -72,6 +73,15 @@ mode = CHECKUID_CHECK_FILE_AND_DIR; } } + + /* +* If given filepath is a URL, allow - safe mode stuff +* related to URL's is checked in individual functions +* Possibly/likely allows for safe_mode bypass!!! +*/ + wrapper = php_stream_locate_url_wrapper(filename, NULL, STREAM_LOCATE_WRAPPERS_ONLY TSRMLS_CC); + if ((wrapper != NULL) (strstr(filename, ..\/) == NULL)) + return 1; /* First we see if the file is owned by the same user... * If that fails, passthrough and check directory... --- Thx [2009-03-12 13:44:07] fuxa_kos at unihost dot cz problem still in 5.2.9 [2008-12-17 15:22:50] php at degoulet dot net thanks : this workaround works fine ! 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=46888 -- Edit this bug report at http://bugs.php.net/bug.php?id=46888edit=1
Bug #53141 [Com]: autoload misbehaves if called from closing session
Edit report at http://bugs.php.net/bug.php?id=53141edit=1 ID: 53141 Comment by: bugs dot php dot net at elyobo dot net Reported by:ladislav at marek dot su Summary:autoload misbehaves if called from closing session Status: Closed Type: Bug Package:SPL related Operating System: GNU Linux PHP Version:5.3SVN-2010-10-23 (SVN) Assigned To:felipe Block user comment: N Private report: N New Comment: I have the same problem in PHP 5.2.10 (Ubuntu version: 5.2.10.dfsg.1-2ubuntu6.5), which doesn't have mysqlnd. I can work around it by doing my thing in __destruct() instead, which works, but I'm not sure that this bug is only related to mysqlnd. Previous Comments: [2010-11-02 21:51:04] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305038 Log: - Fixed config.m4 to complete the fix for bug #53141 (thanks Johannes) [2010-11-02 19:37:39] 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/. Thank you for the report, and for helping us make PHP better. Thanks for the patch, I committed a slighty modified version, I changed OPTIONAL to REQUIRED as SPL is not disableable. [2010-11-02 19:34:58] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305034 Log: - Fixed bug #53141 (autoload misbehaves if called from closing session) patch by: ladislav at marek dot su [2010-11-01 19:17:13] ladislav at marek dot su It looks like that --with-mysql=mysqlnd configuration causes different order of extensions, so SPL extension is destroyed before the session is. Adding session dependency to SPL fixes this bug (I'm not sure if is it correct way). [2010-10-24 13:51:55] ladislav at marek dot su I can reproduce it with '--with-mysql=mysqlnd' configuration. 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=53141 -- Edit this bug report at http://bugs.php.net/bug.php?id=53141edit=1
Bug #53141 [Com]: autoload misbehaves if called from closing session
Edit report at http://bugs.php.net/bug.php?id=53141edit=1 ID: 53141 Comment by: bugs dot php dot net at elyobo dot net Reported by:ladislav at marek dot su Summary:autoload misbehaves if called from closing session Status: Closed Type: Bug Package:SPL related Operating System: GNU Linux PHP Version:5.3SVN-2010-10-23 (SVN) Assigned To:felipe Block user comment: N Private report: N New Comment: Also possibly relevant, calling spl_autoload_functions() in __sleep() causes PHP to segfault in 5.3.3 (Debian version: 5.3.3-7+squeeze1) and the 5.2.10 version mentioned above. Previous Comments: [2011-05-20 03:54:27] bugs dot php dot net at elyobo dot net I have the same problem in PHP 5.2.10 (Ubuntu version: 5.2.10.dfsg.1-2ubuntu6.5), which doesn't have mysqlnd. I can work around it by doing my thing in __destruct() instead, which works, but I'm not sure that this bug is only related to mysqlnd. [2010-11-02 21:51:04] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305038 Log: - Fixed config.m4 to complete the fix for bug #53141 (thanks Johannes) [2010-11-02 19:37:39] 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/. Thank you for the report, and for helping us make PHP better. Thanks for the patch, I committed a slighty modified version, I changed OPTIONAL to REQUIRED as SPL is not disableable. [2010-11-02 19:34:58] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305034 Log: - Fixed bug #53141 (autoload misbehaves if called from closing session) patch by: ladislav at marek dot su [2010-11-01 19:17:13] ladislav at marek dot su It looks like that --with-mysql=mysqlnd configuration causes different order of extensions, so SPL extension is destroyed before the session is. Adding session dependency to SPL fixes this bug (I'm not sure if is it correct way). 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=53141 -- Edit this bug report at http://bugs.php.net/bug.php?id=53141edit=1
[PHP-BUG] Bug #54871 [NEW]: Don't work connect to interbase
From:
Operating system: FreeBSD 8.2
PHP version: 5.3.6
Package: FPM related
Bug Type: Bug
Bug description:Don't work connect to interbase
Description:
Execute script with nginx + php-fpm and page don't show result.
If execute script with PHPCli then show resource(4) of type
(Firebird/InterBase
link).
Test script:
---
?php
$link=ibase_connect('test.domen-test.ru:test','test','test','win1251',
0,1,'main');
var_dump($link);
?
--
Edit bug report at http://bugs.php.net/bug.php?id=54871edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54871r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54871r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54871r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54871r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54871r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54871r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54871r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54871r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54871r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54871r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54871r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54871r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54871r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54871r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54871r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54871r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54871r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54871r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54871r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54871r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54871r=mysqlcfg
Bug #54871 [Com]: Don't work connect to interbase
Edit report at http://bugs.php.net/bug.php?id=54871edit=1
ID: 54871
Comment by: mr dot efrem at gmail dot com
Reported by:mr dot efrem at gmail dot com
Summary:Don't work connect to interbase
Status: Open
Type: Bug
Package:FPM related
Operating System: FreeBSD 8.2
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Nginx + php-fpm are adjusted truly, pages not containing instructions
connect to
firebird are displayed normally.
Previous Comments:
[2011-05-20 07:47:58] mr dot efrem at gmail dot com
Description:
Execute script with nginx + php-fpm and page don't show result.
If execute script with PHPCli then show resource(4) of type
(Firebird/InterBase
link).
Test script:
---
?php
$link=ibase_connect('test.domen-test.ru:test','test','test','win1251',
0,1,'main');
var_dump($link);
?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54871edit=1
