[PHP-BUG] Bug #52062 [NEW]: large timestamps with DateTime::getTimestamp and DateTime::setTimestamp
From:
Operating system: Ubuntu i686 2.6.32-22-generic
PHP version: 5.3.2
Package: Date/time related
Bug Type: Bug
Bug description:large timestamps with DateTime::getTimestamp and
DateTime::setTimestamp
Description:
DateTime::getTimestamp(), DateTime::setTimestamp() and DateInterval does
not work
with large timestamps (using numbers over x86 integers)
Test script:
---
$d = new DateTime('@1000');
var_dump($d->format('Y-m-d H:i:s U'));
var_dump($d->getTimestamp());
$d->setTimestamp(1000);
var_dump($d->format('Y-m-d H:i:s U'));
var_dump($d->getTimestamp());
$i = new DateInterval('PT1000S');
var_dump($i->format('%s'));
Expected result:
string(32) "5138-11-16 09:46:40 1000"
float(1000)
string(32) "5138-11-16 09:46:40 1000"
float(1000)
string(12) "1000"
Actual result:
--
string(32) "5138-11-16 09:46:40 1000"
bool(false)
string(30) "2008-07-11 04:56:32 1215752192"
int(1215752192)
Exception with message 'DateInterval::__construct(): Unknown or bad format
(PT1000S)'
--
Edit bug report at http://bugs.php.net/bug.php?id=52062&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52062&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52062&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52062&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52062&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52062&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52062&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52062&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52062&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52062&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52062&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52062&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52062&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52062&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52062&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52062&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52062&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52062&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52062&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52062&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52062&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52062&r=mysqlcfg
[PHP-BUG] Bug #52061 [NEW]: memory_limit above 2G
From:
Operating system: Linux/Centos-5
PHP version: 5.2SVN-2010-06-12 (snap)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:memory_limit above 2G
Description:
PHP 5.2 doesn't coun't process memory_limit => 2048M in right way
in 32bit mode it works up to 4G, after that it would cause a fatal error,
this seems ok, because of the memory limitations of 32bit :)
in 64bit its a REAL BUG, because after 2047M the memory limit DOESN'T
MATCH, this means no memory limit is active !
as far as i have seen the memory limit for php51 isn't affectet this way
because it walks in an error as of 2GB
and it seems in php53 the problem is fixed, here i tried to set limits up
to 8GB and all worked fine.
The test script is from http://news.php.net/php.internals/48607 , but i
think is shows the problem very well :)
is it possible to fix this, so it will behave as php-5.3 ?
or have the same matching as in 32bit version, so there is a limit if
someone setting a too high value ?
i have found this problem as i wanted to get a customer from an old
php-5.2.13 32bit machine on a newer php-5.2.13 64bit machine :(
32bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
> 0 - 0.000s:0.1 / 0.2 MB
> 1 - 1.294s: 166.7 / 177.5 MB
> 2 - 2.453s: 333.2 / 355.1 MB
> 3 - 3.988s: 499.7 / 532.4 MB
> 4 - 5.700s: 666.3 / 709.5 MB
> 5 - 7.614s: 832.8 / 886.9 MB
> 6 - 9.838s: 999.3 / 1'064.0 MB
> 7 - 11.592s:1'165.9 / 1'241.3 MB
> 8 - 12.943s:1'332.4 / 1'418.6 MB
> 9 - 19.795s:1'498.9 / 1'595.7 MB
PHP Fatal error: Allowed memory size of -2147483648 bytes exhausted (tried
to allocate 40961 bytes) in /tmp/php-memtest.php on line 32
64bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
> 0 - 0.000s:0.1 / 0.2 MB
> 1 - 0.110s: 167.0 / 177.8 MB
> 2 - 0.221s: 333.8 / 355.1 MB
> 3 - 0.335s: 500.5 / 532.2 MB
> 4 - 0.449s: 667.3 / 709.7 MB
> 5 - 0.560s: 834.1 / 887.1 MB
> 6 - 0.672s:1'000.9 / 1'064.2 MB
> 7 - 0.782s:1'167.7 / 1'241.7 MB
> 8 - 0.891s:1'334.5 / 1'418.8 MB
> 9 - 1.000s:1'501.3 / 1'596.0 MB
> 10 - 1.109s:1'668.1 / 1'773.3 MB
> 11 - 1.219s:1'834.9 / 1'950.4 MB
> 12 - 1.328s:2'001.7 / 2'127.5 MB
> 13 - 1.436s:2'168.5 / 2'304.9 MB
> 14 - 1.543s:2'335.3 / 2'482.2 MB
> 15 - 1.651s:2'502.1 / 2'659.3 MB
> 16 - 1.758s:2'668.9 / 2'836.6 MB
> 17 - 1.864s:2'835.7 / 3'013.7 MB
> 18 - 1.969s:3'002.5 / 3'190.9 MB
> 19 - 2.079s:3'169.3 / 3'368.2 MB
> 20 - 2.189s:3'336.0 / 3'545.5 MB
> 21 - 2.300s:3'502.8 / 3'722.6 MB
> 22 - 2.411s:3'669.6 / 3'900.0 MB
> 23 - 2.519s:3'836.4 / 4'077.1 MB
> 24 - 2.628s:4'003.2 / 4'254.2 MB
> 25 - 2.737s:4'170.0 / 4'431.5 MB
> 26 - 2.845s:4'336.8 / 4'608.6 MB
> 27 - 2.953s:4'503.6 / 4'786.0 MB
> 28 - 3.061s:4'670.4 / 4'963.3 MB
> 29 - 3.169s:4'837.2 / 5'140.4 MB
> 30 - 3.277s:5'004.0 / 5'317.5 MB
> 31 - 3.384s:5'170.8 / 5'494.9 MB
> 32 - 3.490s:5'337.6 / 5'672.0 MB
> 33 - 3.596s:5'504.4 / 5'849.3 MB
> 34 - 3.703s:5'671.2 / 6'026.6 MB
> 35 - 3.809s:5'838.0 / 6'203.7 MB
> 36 - 3.914s:6'004.8 / 6'380.9 MB
> 37 - 4.019s:6'171.6 / 6'558.2 MB
> 38 - 4.124s:6'338.3 / 6'735.3 MB
> 39 - 4.231s:6'505.1 / 6'912.4 MB
> 40 - 4.342s:6'671.9 / 7'089.8 MB
Cleaning up 21 output handlers
Done, total time: 4.638s, peak mem: 6'671.9 / 7'089.8 MB
## Other Versions ##
32bit 5.1:
Running 40 times with a 16383 bytes long string (' ...')
> 0 - 0.000s:0.1 / 0.1 MB
> 1 - 0.721s: 166.6 / 166.6 MB
> 2 - 1.646s: 333.0 / 333.0 MB
> 3 - 2.839s: 499.5 / 499.5 MB
> 4 - 4.010s: 665.9 / 665.9 MB
> 5 - 6.007s: 832.4 / 832.4 MB
> 6 - 8.427s: 998.8 / 998.8 MB
> 7 - 9.531s:1'165.3 / 1'165.3 MB
> 8 - 12.218s:1'331.7 / 1'331.7 MB
> 9 - 15.126s:1'498.2 / 1'498.2 MB
> 10 - 17.942s:1'664.7 / 1'664.7 MB
Integer overflow in memory_limit check detected
64bit 5.1:
Running 40 times with a 16383 bytes long string (' ...')
> 0 - 0.000s:0.1 / 0.1 MB
> 1 - 0.116s: 166.7 / 166.7 MB
> 2 - 0.235s: 333.3 / 333.3 MB
> 3 - 0.356s: 499.9 / 499.9 MB
> 4 - 0.473s: 666.5 / 666.5 MB
> 5 - 0.586s:
Bug #52057 [Asn->Csd]: ReflectionClass fails on Closure class
Edit report at http://bugs.php.net/bug.php?id=52057&edit=1
ID: 52057
Updated by: fel...@php.net
Reported by: brandon at brandonsavage dot net
Summary: ReflectionClass fails on Closure class
-Status: Assigned
+Status: Closed
Type: Bug
Package: Reflection related
Operating System: All
PHP Version: 5.3.2
Assigned To: felipe
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:
[2010-06-11 23:15:00] brandon at brandonsavage dot net
I forgot to mention that method_exists() correctly identifies the
presence of __invoke() in the Closure class instance.
[2010-06-11 23:08:24] brandon at brandonsavage dot net
Description:
According to the documentation, the Closure class implements
__construct() and __invoke(). However, when ReflectionClass::hasMethod()
and ReflectionClass::getMethods() are run against a closure, they do not
report the existence of the __invoke() method. On user-defined classes,
the existence of __invoke() is reported if __invoke() is defined.
Test script:
---
$closure = function($a) { echo $a; };
$reflection = new ReflectionClass($closure);
var_dump($reflection->hasMethod('__invoke()');
Expected result:
boolean true
Actual result:
--
boolean false
--
Edit this bug report at http://bugs.php.net/bug.php?id=52057&edit=1
Bug #52060 [Asn->Csd]: Memory leak when passing a closure to method_exists()
Edit report at http://bugs.php.net/bug.php?id=52060&edit=1
ID: 52060
Updated by: fel...@php.net
Reported by: fel...@php.net
Summary: Memory leak when passing a closure to method_exists()
-Status: Assigned
+Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.2
Assigned To: felipe
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:
[2010-06-12 01:20:16] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300392
Log: - Fixed bug #52060 (Memory leak when passing a closure to
method_exists())
[2010-06-12 00:58:14] fel...@php.net
Description:
See below.
Test script:
---
var_dump(method_exists('closure', '__invoke'));
Actual result:
--
/home/felipe/dev/phptrunk/Zend/zend_closures.c(136) : Freeing
0x08C374D4 (9 bytes), script=-
[Fri Jun 11 19:57:03 2010] Script: '-'
/home/felipe/dev/phptrunk/Zend/zend_closures.c(128) : Freeing
0x08C37F68 (164 bytes), script=-
=== Total 2 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/bug.php?id=52060&edit=1
Bug #52060 [Opn->Asn]: Memory leak when passing a closure to method_exists()
Edit report at http://bugs.php.net/bug.php?id=52060&edit=1
ID: 52060
Updated by: fel...@php.net
Reported by: fel...@php.net
Summary: Memory leak when passing a closure to method_exists()
-Status: Open
+Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.2
-Assigned To:
+Assigned To: felipe
Previous Comments:
[2010-06-12 00:58:14] fel...@php.net
Description:
See below.
Test script:
---
var_dump(method_exists('closure', '__invoke'));
Actual result:
--
/home/felipe/dev/phptrunk/Zend/zend_closures.c(136) : Freeing
0x08C374D4 (9 bytes), script=-
[Fri Jun 11 19:57:03 2010] Script: '-'
/home/felipe/dev/phptrunk/Zend/zend_closures.c(128) : Freeing
0x08C37F68 (164 bytes), script=-
=== Total 2 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/bug.php?id=52060&edit=1
[PHP-BUG] Bug #52060 [NEW]: Memory leak when passing a closure to method_exists()
From: felipe
Operating system: Linux
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Memory leak when passing a closure to method_exists()
Description:
See below.
Test script:
---
var_dump(method_exists('closure', '__invoke'));
Actual result:
--
/home/felipe/dev/phptrunk/Zend/zend_closures.c(136) : Freeing 0x08C374D4
(9 bytes), script=-
[Fri Jun 11 19:57:03 2010] Script: '-'
/home/felipe/dev/phptrunk/Zend/zend_closures.c(128) : Freeing 0x08C37F68
(164 bytes), script=-
=== Total 2 memory leaks detected ===
--
Edit bug report at http://bugs.php.net/bug.php?id=52060&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52060&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52060&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52060&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52060&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52060&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52060&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52060&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52060&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52060&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52060&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52060&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52060&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52060&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52060&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52060&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52060&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52060&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52060&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52060&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52060&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52060&r=mysqlcfg
Bug #52057 [Opn->Asn]: ReflectionClass fails on Closure class
Edit report at http://bugs.php.net/bug.php?id=52057&edit=1
ID: 52057
Updated by: fel...@php.net
Reported by: brandon at brandonsavage dot net
Summary: ReflectionClass fails on Closure class
-Status: Open
+Status: Assigned
Type: Bug
Package: Reflection related
Operating System: All
PHP Version: 5.3.2
-Assigned To:
+Assigned To: felipe
Previous Comments:
[2010-06-11 23:15:00] brandon at brandonsavage dot net
I forgot to mention that method_exists() correctly identifies the
presence of __invoke() in the Closure class instance.
[2010-06-11 23:08:24] brandon at brandonsavage dot net
Description:
According to the documentation, the Closure class implements
__construct() and __invoke(). However, when ReflectionClass::hasMethod()
and ReflectionClass::getMethods() are run against a closure, they do not
report the existence of the __invoke() method. On user-defined classes,
the existence of __invoke() is reported if __invoke() is defined.
Test script:
---
$closure = function($a) { echo $a; };
$reflection = new ReflectionClass($closure);
var_dump($reflection->hasMethod('__invoke()');
Expected result:
boolean true
Actual result:
--
boolean false
--
Edit this bug report at http://bugs.php.net/bug.php?id=52057&edit=1
Bug #52058 [Opn]: SOAP_PERSISTENCE_SESSION doesnt work if server class is included from external
Edit report at http://bugs.php.net/bug.php?id=52058&edit=1
ID: 52058
User updated by: nn at tronix dot pl
Reported by: nn at tronix dot pl
Summary: SOAP_PERSISTENCE_SESSION doesnt work if server class
is included from external
Status: Open
Type: Bug
Package: SOAP related
Operating System: FreeBSD 6.2
PHP Version: 5.3.2
New Comment:
The line 14 in server.php should be changed to:
$server = new SoapServer(NULL, array('uri' => 'http://localhost/'));
^^
Previous Comments:
[2010-06-11 23:35:26] nn at tronix dot pl
Description:
If server class is included / required (or included/required once) from
external file the persistence doesn't work.
I think that the BUG is related to already reported bugs #51561 and
#44267.
Test script:
---
client.php
"http://localhost/server.php";,
"uri" => "urn:xmethodsTest",
'trace' => 1
));
# SOAP requests
try {
$session = $client->login();
//$client->__setCookie('PSESSION', $session);
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
} catch (SoapFault $sf) {
echo "";
echo $sf;
}
?>
server.php
--
'http://193.59.86.29/'));
$server->setClass('Bar');
$server->setPersistence(SOAP_PERSISTENCE_SESSION);
$server->handle();
?>
class.bar.php
--
var++;
return $this->var;
}
}
?>
Expected result:
1
2
3
4
5
Actual result:
--
1
1
1
1
1
--
Edit this bug report at http://bugs.php.net/bug.php?id=52058&edit=1
[PHP-BUG] Bug #52058 [NEW]: SOAP_PERSISTENCE_SESSION doesnt work if server class is included from external
From:
Operating system: FreeBSD 6.2
PHP version: 5.3.2
Package: SOAP related
Bug Type: Bug
Bug description:SOAP_PERSISTENCE_SESSION doesnt work if server class is
included from external
Description:
If server class is included / required (or included/required once) from
external file the persistence doesn't work.
I think that the BUG is related to already reported bugs #51561 and #44267.
Test script:
---
client.php
"http://localhost/server.php";,
"uri" => "urn:xmethodsTest",
'trace' => 1
));
# SOAP requests
try {
$session = $client->login();
//$client->__setCookie('PSESSION', $session);
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
} catch (SoapFault $sf) {
echo "";
echo $sf;
}
?>
server.php
--
'http://193.59.86.29/'));
$server->setClass('Bar');
$server->setPersistence(SOAP_PERSISTENCE_SESSION);
$server->handle();
?>
class.bar.php
--
var++;
return $this->var;
}
}
?>
Expected result:
1
2
3
4
5
Actual result:
--
1
1
1
1
1
--
Edit bug report at http://bugs.php.net/bug.php?id=52058&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52058&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52058&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52058&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52058&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52058&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52058&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52058&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52058&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52058&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52058&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52058&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52058&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52058&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52058&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52058&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52058&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52058&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52058&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52058&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52058&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52058&r=mysqlcfg
Bug #44267 [Com]: soap server not persistence
Edit report at http://bugs.php.net/bug.php?id=44267&edit=1 ID: 44267 Comment by: nn at tronix dot pl Reported by: falk dot herrmann at bike24 dot net Summary: soap server not persistence Status: No Feedback Type: Bug Package: SOAP related Operating System: Linux 2.6.23 PHP Version: 5.2.5 New Comment: I have exactly the same problem in PHP 5.3.2 Previous Comments: [2010-04-14 20:26:46] marcio at invox dot es I have exactly the same problem in PHP 5.2.11 and 5.2.6-1+lenny3, is it fixed? How to solve this!?? Thanks a lot! [2008-10-29 01:00:02] 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". [2008-10-21 11:32:10] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-07-10 18:48:33] davy dot defaud at free dot fr It still doesn't work for me even in 5.2.6. I tried everything I could, I'm really lazzy. [2008-05-18 20:06:07] falk dot herrmann at bike24 dot net It seems that the code work with PHP 5.2.6 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=44267 -- Edit this bug report at http://bugs.php.net/bug.php?id=44267&edit=1
Bug #52057 [Com]: ReflectionClass fails on Closure class
Edit report at http://bugs.php.net/bug.php?id=52057&edit=1
ID: 52057
Comment by: brandon at brandonsavage dot net
Reported by: brandon at brandonsavage dot net
Summary: ReflectionClass fails on Closure class
Status: Open
Type: Bug
Package: Reflection related
Operating System: All
PHP Version: 5.3.2
New Comment:
I forgot to mention that method_exists() correctly identifies the
presence of __invoke() in the Closure class instance.
Previous Comments:
[2010-06-11 23:08:24] brandon at brandonsavage dot net
Description:
According to the documentation, the Closure class implements
__construct() and __invoke(). However, when ReflectionClass::hasMethod()
and ReflectionClass::getMethods() are run against a closure, they do not
report the existence of the __invoke() method. On user-defined classes,
the existence of __invoke() is reported if __invoke() is defined.
Test script:
---
$closure = function($a) { echo $a; };
$reflection = new ReflectionClass($closure);
var_dump($reflection->hasMethod('__invoke()');
Expected result:
boolean true
Actual result:
--
boolean false
--
Edit this bug report at http://bugs.php.net/bug.php?id=52057&edit=1
Bug #52056 [Opn]: garbage collection interferes with oci_connect connection pooling
Edit report at http://bugs.php.net/bug.php?id=52056&edit=1
ID: 52056
User updated by: jonarobinson at rim dot com
Reported by: jonarobinson at rim dot com
-Summary: gargbage collection interferes with oci_connect
+Summary: garbage collection interferes with oci_connect
connection pooling
Status: Open
Type: Bug
Package: OCI8 related
Operating System: RHEL 4 R5
PHP Version: 5.2.13
New Comment:
I found a work around. By hanging on to a reference to the DB handle
(whether you use it or not) it will prevent the DB handle from being
garbage collected in your app. Thus subsequent calls to oci_connect
will use the cached resource as expected.
If you're only using one connection you can do something like this:
$dbh_keep_alive = connect(); // Hang on to a reference - if it gets
garbage collected then our connection pooling will stop working
If you're using multiple connections like me than you'll need to keep a
cache of connections used. This should do the trick:
connect($username, $password, $conn_info) {
$dbh = oci_connect($username, $password, $conn_info);
$key = hash('md5', "$username|$password|$conn_info");
$GLOBALS[$key] = $dbh;
return $dbh;
}
Previous Comments:
[2010-06-11 22:45:09] jonarobinson at rim dot com
Description:
Once your handle gets garbage collected by PHP (falls off the method
scope), subsequent calls to oci_connect will generate new connections.
This is true in PHP 5.2.13. I wasn't able to verify on PHP 5.3.
Test script:
---
connect();
connect();
$dbh1 = connect();
$dbh2 = connect();
function connect()
{
$conn_info = '(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST =
localhost) (PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = TEST)))';
$dbh = oci_connect('username', 'password', $conn_info);
echo "Our handle is: $dbh\n";
return $dbh;
}
function getConnection($sid)
Expected result:
Our handle is: Resource id #35
Our handle is: Resource id #35
Our handle is: Resource id #35
Our handle is: Resource id #35
Actual result:
--
Our handle is: Resource id #35
Our handle is: Resource id #36
Our handle is: Resource id #37
Our handle is: Resource id #37
--
Edit this bug report at http://bugs.php.net/bug.php?id=52056&edit=1
[PHP-BUG] Bug #52057 [NEW]: ReflectionClass fails on Closure class
From:
Operating system: All
PHP version: 5.3.2
Package: Reflection related
Bug Type: Bug
Bug description:ReflectionClass fails on Closure class
Description:
According to the documentation, the Closure class implements __construct()
and __invoke(). However, when ReflectionClass::hasMethod() and
ReflectionClass::getMethods() are run against a closure, they do not report
the existence of the __invoke() method. On user-defined classes, the
existence of __invoke() is reported if __invoke() is defined.
Test script:
---
$closure = function($a) { echo $a; };
$reflection = new ReflectionClass($closure);
var_dump($reflection->hasMethod('__invoke()');
Expected result:
boolean true
Actual result:
--
boolean false
--
Edit bug report at http://bugs.php.net/bug.php?id=52057&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52057&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52057&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52057&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52057&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52057&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52057&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52057&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52057&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52057&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52057&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52057&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52057&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52057&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52057&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52057&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52057&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52057&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52057&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52057&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52057&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52057&r=mysqlcfg
[PHP-BUG] Bug #52056 [NEW]: gargbage collection interferes with oci_connect
From:
Operating system: RHEL 4 R5
PHP version: 5.2.13
Package: OCI8 related
Bug Type: Bug
Bug description:gargbage collection interferes with oci_connect
Description:
Once your handle gets garbage collected by PHP (falls off the method
scope), subsequent calls to oci_connect will generate new connections.
This is true in PHP 5.2.13. I wasn't able to verify on PHP 5.3.
Test script:
---
connect();
connect();
$dbh1 = connect();
$dbh2 = connect();
function connect()
{
$conn_info = '(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST =
localhost) (PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = TEST)))';
$dbh = oci_connect('username', 'password', $conn_info);
echo "Our handle is: $dbh\n";
return $dbh;
}
function getConnection($sid)
Expected result:
Our handle is: Resource id #35
Our handle is: Resource id #35
Our handle is: Resource id #35
Our handle is: Resource id #35
Actual result:
--
Our handle is: Resource id #35
Our handle is: Resource id #36
Our handle is: Resource id #37
Our handle is: Resource id #37
--
Edit bug report at http://bugs.php.net/bug.php?id=52056&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52056&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52056&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52056&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52056&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52056&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52056&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52056&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52056&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52056&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52056&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52056&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52056&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52056&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52056&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52056&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52056&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52056&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52056&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52056&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52056&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52056&r=mysqlcfg
[PHP-BUG] Bug #52054 [NEW]: Class 'PDO' not found
From: Operating system: linux kernel 2.6.27-grsec4 PHP version: 5.2.13 Package: PDO related Bug Type: Bug Bug description:Class 'PDO' not found Description: When a specific database module is not installed and a PDO object of this type is called you receive an error reporting that PDO does not exist. Test script: --- getMessage()} \n"; exit; } ?> Expected result: Failed to get DB handle: could not find driver Failed to get DB handle: could not find module etc. Actual result: -- PHP Fatal error: Class 'PDO' not found in /home/../login.php on line 10 -- Edit bug report at http://bugs.php.net/bug.php?id=52054&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52054&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52054&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52054&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52054&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52054&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52054&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52054&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52054&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52054&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52054&r=support Expected behavior: http://bugs.php.net/fix.php?id=52054&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52054&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52054&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52054&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52054&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52054&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52054&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52054&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52054&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52054&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52054&r=mysqlcfg
[PHP-BUG] Bug #52053 [NEW]: PDO constructor returns null instead of throwing an exception
From:
Operating system: Ubuntu 9.10
PHP version: 5.3.2
Package: PDO related
Bug Type: Bug
Bug description:PDO constructor returns null instead of throwing an exception
Description:
Calling 'new PDO(...)' returns null instead of raising an exception.
This behaviour was found, while trying to create a PDO object using an
sqlite database.
The database was created using the command 'sqlite3' from the console.
Attempting to open it from PHP using an 'sqlite2' dsn did not raised any
exception, but returned null from the object constructor.
I do not know if this happens with other PDO drivers, but in any case
constructors SHOULD throw an Exception on error, and not NULL.
A similar bug has been reported (http://bugs.php.net/bug.php?id=49320) but
since there is at least another case (http://bugs.php.net/bug.php?id=52042)
in which a constructor returns NULL when it should be throwing an
Exception, I decided to report this anyway.
I'm not sure if this goes beyond PDO, and it's a PHP feature that I've
never experienced before, but this type of code makes no sense at all,
$o = new SomeObject();
if($o === null) {
// handle error ...
} else {
$o->doSomething();
}
This is what is expected from OOP:
try {
$o = new SomeObject();
$o->doSomething();
} catch(Exception $x) {
// handle error ...
}
Test script:
---
>From the console:
$ sqlite3 sqlite.db
sqlite> CREATE TABLE T(K VARCHAR(32));
sqlite> .q
>From a PHP script:
$pdo = new PDO('sqlite2:sqlite.db');
echo 'PDO is ', gettype($pdo), PHP_EOL;
Expected result:
PDO is object
Actual result:
--
PDO is NULL
--
Edit bug report at http://bugs.php.net/bug.php?id=52053&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52053&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52053&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52053&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52053&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52053&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52053&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52053&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52053&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52053&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52053&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52053&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52053&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52053&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52053&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52053&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52053&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52053&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52053&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52053&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52053&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52053&r=mysqlcfg
Req #49543 [Com]: closures cannot import/inherit $this
Edit report at http://bugs.php.net/bug.php?id=49543&edit=1
ID: 49543
Comment by: martin dot partel at gmail dot com
Reported by: mjs at beebo dot org
Summary: closures cannot import/inherit $this
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Ubuntu
PHP Version: 5.3.0
New Comment:
The '$tmp' workaround is not good enough, since private/protected
members cannot be accessed that way. This renders closures frustratingly
useless in OO code in quite a few situations.
All other OO languages with closures that I know of allow such access
one way or the other. Come on guys, find your consensus and get it done!
Previous Comments:
[2009-09-13 14:55:50] mjs at beebo dot org
Description:
Attempting to import/inherit $this produces the compile-time error
"Cannot use $this as lexical variable."
Note that the workaround of assigning $this to the temporary variable
$tmp, and inheriting $tmp instead does work, so there appears to be no
limitation in the engine:
class Foo {
public function bar() {
$tmp = $this;
return function() use ($tmp) {
echo "in closure\n";
}
}
}
See also http://wiki.php.net/rfc/closures/removal-of-this. (It
appears that $this was once automatically imported into the closure's
scope, but that this turned out to be a bad idea. This bug report
concerns what happens when $this is explicitly imported, however.)
Reproduce code:
---
http://bugs.php.net/bug.php?id=49543&edit=1
Bug #28929 [Com]: PHP has encountered an Access Violation at 015B73DD
Edit report at http://bugs.php.net/bug.php?id=28929&edit=1 ID: 28929 Comment by: in2ishun at yahoo dot com Reported by: remy at ourselves dot nl Summary: PHP has encountered an Access Violation at 015B73DD Status: Closed Type: Bug Package: IIS related Operating System: Win XP Pro PHP Version: 5CVS-2004-06-25 (dev) New Comment: * SOLUTION I realize this issue is AGES old, but it still manages to be the top hit on Google searches as of now (6/2010). I fixed my own instance of seeing this error. W2k3, IIS6, PHP 5.2.6, MySQL 5.1. The problem is in the pathing. When I used the MSI installer for MySQL without doing an "advanced" installation (where I could manage the install details), it added a path to the system environment that contained spaces. Even after changing the path environment to use the Windows short-name location of the mysql bin directory, it still didn't work. The solution was for me to reinstall mysql and set the default installation path to just off the root (e.g. C:\mysql). Once I did that the error went away and my app started working. There are a number of sites with a variety of potential solutions to this issue and several of them mentioned paths and the "libmysql.dll" file (in the "bin" directory of your mysql installation). If this helps you solve your problem, consider leaving a comment here so others can see that it works. Previous Comments: [2004-09-06 05:08:53] Ersan191 at evilxp dot com This bug only seems to occur when running php in isapi mode through IIS. I get this error 50% of the time with php4isapi.dll, but when I restart IIS it goes away for awhile. [2004-07-30 16:48:20] g dot collins8 at ntlworld dot com I am running win 2000 server IIS 5 with php 5.0.0 & MySql 4.0.20d http://www.nx99.net/info.php I do not seem to have an error on this page however when I try to install phpmyadmin or vBulletin I get the following erro. PHP has encountered an Access Violation at 019573CD What can i do to fix this as I can not get anything to work. [2004-07-30 07:24:23] sak_cu at hotmail dot com I you CVS version both php and pecl I has no error When I restart "IIS Admin" error dialog will appear. But it can restart without problem and webserver can run normally... This is php bug or IIS Admin bug?? [2004-07-22 01:04:51] ed...@php.net This bug has been fixed in CVS. 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. [2004-07-21 11:12:29] mattbta at gmail dot com Same error - different memory address...however - here's the kicker, only search engine spiders see it. I can't reproduce the error in any browser on windows, but going through search engine simulators, the error pops up in different spots on different pages. This only seems to be related to pages with MySQL connections/queries. Setup - w2k3, IIS6, PHP5.0.0 ISAPI, MySQL 4.0.18 Running the same pages on different port with Apache 2.50 eliminates the error. I've given the IUSR_COMPUTERNAME account full control to the php dir, mysql dir, web dir, and php/mysql dll's in %systemroot% and system32 and system. 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=28929 -- Edit this bug report at http://bugs.php.net/bug.php?id=28929&edit=1
[PHP-BUG] Req #52052 [NEW]: add syslog support to FPM
From: Operating system: Linux/*NIX PHP version: 5.3SVN-2010-06-11 (SVN) Package: FPM related Bug Type: Feature/Change Request Bug description:add syslog support to FPM Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit bug report at http://bugs.php.net/bug.php?id=52052&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52052&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52052&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52052&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52052&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52052&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52052&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52052&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52052&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52052&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52052&r=support Expected behavior: http://bugs.php.net/fix.php?id=52052&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52052&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52052&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52052&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52052&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52052&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52052&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52052&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52052&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52052&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52052&r=mysqlcfg
Req #51335 [Com]: Search first substring from list
Edit report at http://bugs.php.net/bug.php?id=51335&edit=1
ID: 51335
Comment by: vovan-ve at yandex dot ru
Reported by: vovan-ve at yandex dot ru
Summary: Search first substring from list
Status: Feedback
Type:Feature/Change Request
Package: Strings related
PHP Version: Irrelevant
Assigned To: kalle
New Comment:
Yes, such functionality can be done by strpos() foreach needle in the
array. But I see at least two ways to make such search more optimal:
1. Make limit for maximal possible position after which we should not
search a needles. The strpos() has no such limit, so we need to make
substr() after we find next nearest needle.
2. Check length of a next needle and remaining substring to search in.
Of course I can write the function, which do what I need, but I think,
that it won't more optimal in PHP code, then build-in PCRE or build-in
function I request.
Previous Comments:
[2010-06-11 14:21:18] ka...@php.net
I dont think we should add such functionality that already can be done
with a few lines of php code already, combining strpos/stripos with a
foreach and you should get your result:
Dont take that code for granted, as i wrote it on my cell so it might be
buggy, but should show what I mean
[2010-03-20 11:45:58] vovan-ve at yandex dot ru
Description:
If we want to search first substrings from list, we should make multiple
calls to strpos() for each substring. Using PCRE will slowdown
performance. So, we need some new function like:
int strpos_array(string $haystack, array $needles, string &$found [,
int $offset = 0 ])
which will accept array of substrings in $needle, search first position
of them. If nothing found then returns FALSE. If found any substring
then assign it to $found and return its position.
The function name is not important. Other functions for case-insensitive
search and/or for reverse search (stripos_array, strrpos_array,
strripos_array) also useful.
Extending function strpos() to accept array in $needle is not good due
to &$found parameter.
Good example of using such function is writing parser of some data like
SQL dump. Performance of the function should be higher then PCRE.
Test script:
---
$string = 'foo;bar::baz-qwe';
$search = array('-', ';', '::');
$pos = strpos_array($string, $search, $found, 5);
if ($pos === false) {
echo "Nothing found";
}
else {
echo "Found '$found' at $pos";
}
Expected result:
Found '::' at 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=51335&edit=1
[PHP-BUG] Bug #52051 [NEW]: handling of case sensitivity of old-style constructors changed in 5.3+
From: Operating system: Win32 PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:handling of case sensitivity of old-style constructors changed in 5.3+ Description: Since PHP 5.3+ (it worked in 5.2.6) handling of old-style constructors with case sensitive (i.e. camelcasing) changed. The 'generated' constructor is only available in lower case since 5.3 Test script: --- C() C:\php\test.php:20 -- Edit bug report at http://bugs.php.net/bug.php?id=52051&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52051&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52051&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52051&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52051&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52051&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52051&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52051&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52051&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52051&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52051&r=support Expected behavior: http://bugs.php.net/fix.php?id=52051&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52051&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52051&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52051&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52051&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52051&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52051&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52051&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52051&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52051&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52051&r=mysqlcfg
Bug #52050 [Fbk->Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 User updated by: marcus at adolfsson dot com Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Feedback +Status: Open Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) Previous Comments: [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all ad
Bug #52050 [Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 User updated by: marcus at adolfsson dot com Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload Status: Open Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 New Comment: This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ;specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. listen = 127.0.0.1:9000 ; Set listen(2) backlog. A value of '-1' means unlimited. ; Default Value: -1 listen.backlog = -1 ; List of ipv4 addresses of FastCGI clients which are allowed to connect. ; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original ; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address ; must be separated by a comma. If this value is left blank, connections will be ; accepted from any ip address. ; Default Value: any ;listen.allowed_clients = 127.0.0.1 ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 ;listen.owner = nobody ;listen.group = nobody ;listen.mode = 0666 ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = phpfm group = phpfm ; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixed number (pm.max_children) of child processes; ; dynamic - the number of child processes are set dynamically based on the ; following directives: ; pm.max_children - the maximum number of children that can ;be alive at the same time. ; pm.start_servers - the number of children created on startup. ; pm.min_spare_servers - the minimum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is less than this ;number then some children will be created. ; pm.max_spare_servers - the maximum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is greater than this ;number then some children will be killed. ; Note: This value is mandatory. pm = static ; The number of child processes to be created when pm is set to 'static' and the ; maximum number of child processes to be created when pm is set to 'dynamic'. ; This value sets the limit on the number of simultaneous req
Bug #52019 [Asn->Csd]: make lcov doesn't support TESTS variable anymore
Edit report at http://bugs.php.net/bug.php?id=52019&edit=1 ID: 52019 Updated by: patrickalla...@php.net Reported by: patrickalla...@php.net Summary: make lcov doesn't support TESTS variable anymore -Status: Assigned +Status: Closed Type: Bug Package: Unknown/Other Function Operating System: Linux PHP Version: 5.3.2 Assigned To: patrickallaert 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: [2010-06-11 16:04:59] patrickalla...@php.net Automatic comment from SVN on behalf of patrickallaert Revision: http://svn.php.net/viewvc/?view=revision&revision=300385 Log: - Fixed bug #52019 (make lcov doesn't support TESTS variable anymore) [2010-06-11 15:33:47] patrickalla...@php.net The following patch has been added/updated: Patch Name: bug52019.diff Revision: 1276263227 URL: http://bugs.php.net/patch-display.php?bug=52019&patch=bug52019.diff&revision=1276263227 [2010-06-08 10:17:03] patrickalla...@php.net Description: $ make lcov TESTS= previously generated code coverage of tests appearing in as with: $ make test TESTS= -- Edit this bug report at http://bugs.php.net/bug.php?id=52019&edit=1
Bug #52050 [Asn->Fbk]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 Updated by: tony2...@php.net Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Assigned +Status: Feedback Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: Please also show the output of `ldd /path/to/php-fpm`. Thanks. Previous Comments: [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ;specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. listen = 127.0.0.1:9000 ; Set listen(2) backlog. A value of '-1' means unlimited. ; Default Value: -1 listen.backlog = -1 ; List of ipv4 addresses of FastCGI clients which are allowed to connect. ; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original ; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address ; must be separated by a comma. If this value is left blank, connections will be ; accepted from any ip address. ; Default Value: any ;listen.allowed_clients = 127.0.0.1 ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 ;listen.owner = nobody ;listen.group = nobody ;listen.mode = 0666 ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = phpfm group = phpfm ; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixed number (pm.max_children) of child processes; ; dynamic - the number of child processes are set dynamically based on the ; following directives: ; pm.max_children - the maximum number of children that can ;be alive at the same time. ; pm.start_servers - the number of children created on startup. ; pm.min_spare_servers - the minimum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is less than this ;number then some children will be created. ; pm.max_spare_servers - the maximum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is greater than this ;number then some children will be killed. ; Note: This value i
Bug #51430 [Opn]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430&edit=1
ID: 51430
User updated by: will at flourishlib dot com
Reported by: will at flourishlib dot com
Summary: Numeric string array key is being implicitly cast to
32bit int and overflowing
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Fedora 12
PHP Version: 5.3.2
New Comment:
Here is the info from the original 32bit machine that also sees the bug
in
5.3.3-dev:
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 09:48:12)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
# uname -a
Linux vm-fedora 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19
19:10:04 UTC
2010 i686 i686 i386 GNU/Linux
# gcc -v
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --
enable-bootstrap --enable-shared --enable-threads=posix --enable-
checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-
exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-
c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi
--enable-plugin --
with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile
--enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --
disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
--with-
arch=i686 --build=i686-redhat-linux
Thread model: posix
gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC)
Previous Comments:
[2010-06-11 15:35:56] will at flourishlib dot com
Both 5.3.3-dev and trunk were built on the following machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100 i686 i686 i386 GNU/Linux
# gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib
--libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-
gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp
--with-bugurl=http://bugs.opensuse.org/ --
with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --
enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-
libs --program-suffix=-4.4 --enable-linux-futex
--without-system-libunwind --with-arch-32=i586 --with-
tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
[2010-06-11 15:27:41] col...@php.net
Apparently it's still reproducible in some environments with the latest
5.3
snapshot, Not on mine though.
[2010-06-11 15:24:50] will at flourishlib dot com
I just built php-trunk and got the same bug:
# wget http://snaps.php.net/php-trunk-201006111230.tar.bz2
# tar xvfj php-trunk-201006111230.tar.bz2
# cd php-trunk-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.99-dev (cli) (built: Jun 11 2010 09:19:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
This is on a 32bit OpenSUSE machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100
i686 i686 i386 GNU/Linux
[2010-06-11 15:05:45] will at flourishlib dot com
I just built 5.3.3-dev and I am still having the same bug:
# wget http://snaps.php.net/php5.3-201006111230.tar.bz2
# tar xvfj php5.3-201006111230.tar.bz2
# cd php5.3-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 08:57:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
[2010-06-09 23:10:00] will at flourishlib dot com
On my 32bit Fedora 12 box this does occur with 5.3.2. That seems to
suggest me a
32/64bit issue. Below is the output:
# php -v
PHP 5.3.2 (cli) (built: Apr 27 2010 17:55:0
Bug #52050 [Opn->Asn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 Updated by: f...@php.net Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Open +Status: Assigned Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 -Assigned To: +Assigned To: fat Previous Comments: [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ;specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. listen = 127.0.0.1:9000 ; Set listen(2) backlog. A value of '-1' means unlimited. ; Default Value: -1 listen.backlog = -1 ; List of ipv4 addresses of FastCGI clients which are allowed to connect. ; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original ; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address ; must be separated by a comma. If this value is left blank, connections will be ; accepted from any ip address. ; Default Value: any ;listen.allowed_clients = 127.0.0.1 ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 ;listen.owner = nobody ;listen.group = nobody ;listen.mode = 0666 ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = phpfm group = phpfm ; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixed number (pm.max_children) of child processes; ; dynamic - the number of child processes are set dynamically based on the ; following directives: ; pm.max_children - the maximum number of children that can ;be alive at the same time. ; pm.start_servers - the number of children created on startup. ; pm.min_spare_servers - the minimum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is less than this ;number then some children will be created. ; pm.max_spare_servers - the maximum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is greater than this ;number then some children will be killed. ; Note: This value is mandatory. pm = static ; The number of child processes to be
Bug #51430 [Opn]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430&edit=1
ID: 51430
User updated by: will at flourishlib dot com
Reported by: will at flourishlib dot com
Summary: Numeric string array key is being implicitly cast to
32bit int and overflowing
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Fedora 12
PHP Version: 5.3.2
New Comment:
Both 5.3.3-dev and trunk were built on the following machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100 i686 i686 i386 GNU/Linux
# gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib
--libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-
gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp
--with-bugurl=http://bugs.opensuse.org/ --
with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --
enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-
libs --program-suffix=-4.4 --enable-linux-futex
--without-system-libunwind --with-arch-32=i586 --with-
tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
Previous Comments:
[2010-06-11 15:27:41] col...@php.net
Apparently it's still reproducible in some environments with the latest
5.3
snapshot, Not on mine though.
[2010-06-11 15:24:50] will at flourishlib dot com
I just built php-trunk and got the same bug:
# wget http://snaps.php.net/php-trunk-201006111230.tar.bz2
# tar xvfj php-trunk-201006111230.tar.bz2
# cd php-trunk-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.99-dev (cli) (built: Jun 11 2010 09:19:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
This is on a 32bit OpenSUSE machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100
i686 i686 i386 GNU/Linux
[2010-06-11 15:05:45] will at flourishlib dot com
I just built 5.3.3-dev and I am still having the same bug:
# wget http://snaps.php.net/php5.3-201006111230.tar.bz2
# tar xvfj php5.3-201006111230.tar.bz2
# cd php5.3-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 08:57:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
[2010-06-09 23:10:00] will at flourishlib dot com
On my 32bit Fedora 12 box this does occur with 5.3.2. That seems to
suggest me a
32/64bit issue. Below is the output:
# php -v
PHP 5.3.2 (cli) (built: Apr 27 2010 17:55:02)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
# uname -a
Linux vm-fedora 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19
19:10:04 UTC
2010 i686 i686 i386 GNU/Linux
[2010-06-08 14:27:40] tony2...@php.net
Not reproducible with 5.3.2, 5.3.3-dev and trunk on 64bit Linux.
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=51430
--
Edit this bug report at http://bugs.php.net/bug.php?id=51430&edit=1
[PHP-BUG] Bug #52050 [NEW]: PHP-FPM Dies after self-initiating reload
From:
Operating system: fc7
PHP version: 5.3.2
Package: FPM related
Bug Type: Bug
Bug description: PHP-FPM Dies after self-initiating reload
Description:
Just upgraded one of our machines to PHP-FPM from
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/sapi/fpm
sapi/fpm with 5.3.2 stable, and everything was working fine until PHP-
FPM needed to initiate a reload.
Jun 11 00:44:54.935812 [WARNING] [pool www] child 26032 exited on
signal 7 SIGBUS after 0.000199 seconds from start
Jun 11 00:44:54.937079 [NOTICE] [pool www] child 26033 started
Jun 11 00:44:54.937113 [WARNING] [pool www] child 26033 exited on
signal 7 SIGBUS after 0.51 seconds from start
Jun 11 00:44:54.937139 [WARNING] failed processes threshold (10 in 60
sec) is reached, initiating reload
Jun 11 00:44:55.104446 [NOTICE] reloading: execvp("/usr/sbin/php-fpm",
{"/usr/sbin/php-fpm", "--fpm-config", "/etc/php-fpm.conf"})
php-fpm: event.c:268: event_base_free: Assertion `(((&base-
>eventqueue)->tqh_first) == ((void *)0))' failed.
--
Edit bug report at http://bugs.php.net/bug.php?id=52050&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52050&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52050&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52050&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52050&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52050&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52050&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52050&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52050&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52050&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52050&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52050&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52050&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52050&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52050&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52050&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52050&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52050&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52050&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52050&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52050&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52050&r=mysqlcfg
Bug #52019 [PATCH]: make lcov doesn't support TESTS variable anymore
Edit report at http://bugs.php.net/bug.php?id=52019&edit=1 ID: 52019 Patch added by: patrickalla...@php.net Reported by: patrickalla...@php.net Summary: make lcov doesn't support TESTS variable anymore Status: Assigned Type: Bug Package: Unknown/Other Function Operating System: Linux PHP Version: 5.3.2 Assigned To: patrickallaert New Comment: The following patch has been added/updated: Patch Name: bug52019.diff Revision: 1276263227 URL: http://bugs.php.net/patch-display.php?bug=52019&patch=bug52019.diff&revision=1276263227 Previous Comments: [2010-06-08 10:17:03] patrickalla...@php.net Description: $ make lcov TESTS= previously generated code coverage of tests appearing in as with: $ make test TESTS= -- Edit this bug report at http://bugs.php.net/bug.php?id=52019&edit=1
Bug #51430 [Bgs->Opn]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430&edit=1
ID: 51430
Updated by: col...@php.net
Reported by: will at flourishlib dot com
Summary: Numeric string array key is being implicitly cast to
32bit int and overflowing
-Status: Bogus
+Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Fedora 12
PHP Version: 5.3.2
New Comment:
Apparently it's still reproducible in some environments with the latest
5.3
snapshot, Not on mine though.
Previous Comments:
[2010-06-11 15:24:50] will at flourishlib dot com
I just built php-trunk and got the same bug:
# wget http://snaps.php.net/php-trunk-201006111230.tar.bz2
# tar xvfj php-trunk-201006111230.tar.bz2
# cd php-trunk-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.99-dev (cli) (built: Jun 11 2010 09:19:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
This is on a 32bit OpenSUSE machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100
i686 i686 i386 GNU/Linux
[2010-06-11 15:05:45] will at flourishlib dot com
I just built 5.3.3-dev and I am still having the same bug:
# wget http://snaps.php.net/php5.3-201006111230.tar.bz2
# tar xvfj php5.3-201006111230.tar.bz2
# cd php5.3-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 08:57:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
[2010-06-09 23:10:00] will at flourishlib dot com
On my 32bit Fedora 12 box this does occur with 5.3.2. That seems to
suggest me a
32/64bit issue. Below is the output:
# php -v
PHP 5.3.2 (cli) (built: Apr 27 2010 17:55:02)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
# uname -a
Linux vm-fedora 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19
19:10:04 UTC
2010 i686 i686 i386 GNU/Linux
[2010-06-08 14:27:40] tony2...@php.net
Not reproducible with 5.3.2, 5.3.3-dev and trunk on 64bit Linux.
[2010-03-29 20:18:41] will at flourishlib dot com
Description:
When trying to use a string array key that contains a number outside of
the 32bit integer range, the key is being cast to an integer implicitly
by PHP and is overflowing the 32bit integer limits.
This incorrect casting is present in both 5.3.1 and 5.3.2 (probably
5.3.0), however 5.1.6 through 5.2.13 do not perform this implicit
casting. The manual indicates that an integer-like key will be cast to
an integer, however that should not be the case when the integer will
not losslessly cast, since that can cause keys to be overwritten.
Test script:
---
print_r(array("-2147483649" => TRUE, "-2147483648" => FALSE));
print_r(array("-2147483649" => 1, "-2147483648" => 2, "2147483647" => 3,
"2147483648" => 4));
Expected result:
Array
(
[-2147483649] => 1
[-2147483648] =>
)
Array
(
[-2147483649] => 1
[-2147483648] => 2
[2147483647] => 3
[2147483648] => 4
)
Actual result:
--
Array
(
[2147483647] => 1
[-2147483648] =>
)
Array
(
[2147483647] => 3
[-2147483648] => 4
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51430&edit=1
Bug #51430 [Bgs]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430&edit=1
ID: 51430
User updated by: will at flourishlib dot com
Reported by: will at flourishlib dot com
Summary: Numeric string array key is being implicitly cast to
32bit int and overflowing
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Fedora 12
PHP Version: 5.3.2
New Comment:
I just built php-trunk and got the same bug:
# wget http://snaps.php.net/php-trunk-201006111230.tar.bz2
# tar xvfj php-trunk-201006111230.tar.bz2
# cd php-trunk-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.99-dev (cli) (built: Jun 11 2010 09:19:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
This is on a 32bit OpenSUSE machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100
i686 i686 i386 GNU/Linux
Previous Comments:
[2010-06-11 15:05:45] will at flourishlib dot com
I just built 5.3.3-dev and I am still having the same bug:
# wget http://snaps.php.net/php5.3-201006111230.tar.bz2
# tar xvfj php5.3-201006111230.tar.bz2
# cd php5.3-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 08:57:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
[2010-06-09 23:10:00] will at flourishlib dot com
On my 32bit Fedora 12 box this does occur with 5.3.2. That seems to
suggest me a
32/64bit issue. Below is the output:
# php -v
PHP 5.3.2 (cli) (built: Apr 27 2010 17:55:02)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
# uname -a
Linux vm-fedora 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19
19:10:04 UTC
2010 i686 i686 i386 GNU/Linux
[2010-06-08 14:27:40] tony2...@php.net
Not reproducible with 5.3.2, 5.3.3-dev and trunk on 64bit Linux.
[2010-03-29 20:18:41] will at flourishlib dot com
Description:
When trying to use a string array key that contains a number outside of
the 32bit integer range, the key is being cast to an integer implicitly
by PHP and is overflowing the 32bit integer limits.
This incorrect casting is present in both 5.3.1 and 5.3.2 (probably
5.3.0), however 5.1.6 through 5.2.13 do not perform this implicit
casting. The manual indicates that an integer-like key will be cast to
an integer, however that should not be the case when the integer will
not losslessly cast, since that can cause keys to be overwritten.
Test script:
---
print_r(array("-2147483649" => TRUE, "-2147483648" => FALSE));
print_r(array("-2147483649" => 1, "-2147483648" => 2, "2147483647" => 3,
"2147483648" => 4));
Expected result:
Array
(
[-2147483649] => 1
[-2147483648] =>
)
Array
(
[-2147483649] => 1
[-2147483648] => 2
[2147483647] => 3
[2147483648] => 4
)
Actual result:
--
Array
(
[2147483647] => 1
[-2147483648] =>
)
Array
(
[2147483647] => 3
[-2147483648] => 4
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51430&edit=1
Bug #51430 [Bgs]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430&edit=1
ID: 51430
User updated by: will at flourishlib dot com
Reported by: will at flourishlib dot com
Summary: Numeric string array key is being implicitly cast to
32bit int and overflowing
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Fedora 12
PHP Version: 5.3.2
New Comment:
I just built 5.3.3-dev and I am still having the same bug:
# wget http://snaps.php.net/php5.3-201006111230.tar.bz2
# tar xvfj php5.3-201006111230.tar.bz2
# cd php5.3-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 08:57:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
Previous Comments:
[2010-06-09 23:10:00] will at flourishlib dot com
On my 32bit Fedora 12 box this does occur with 5.3.2. That seems to
suggest me a
32/64bit issue. Below is the output:
# php -v
PHP 5.3.2 (cli) (built: Apr 27 2010 17:55:02)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
# uname -a
Linux vm-fedora 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19
19:10:04 UTC
2010 i686 i686 i386 GNU/Linux
[2010-06-08 14:27:40] tony2...@php.net
Not reproducible with 5.3.2, 5.3.3-dev and trunk on 64bit Linux.
[2010-03-29 20:18:41] will at flourishlib dot com
Description:
When trying to use a string array key that contains a number outside of
the 32bit integer range, the key is being cast to an integer implicitly
by PHP and is overflowing the 32bit integer limits.
This incorrect casting is present in both 5.3.1 and 5.3.2 (probably
5.3.0), however 5.1.6 through 5.2.13 do not perform this implicit
casting. The manual indicates that an integer-like key will be cast to
an integer, however that should not be the case when the integer will
not losslessly cast, since that can cause keys to be overwritten.
Test script:
---
print_r(array("-2147483649" => TRUE, "-2147483648" => FALSE));
print_r(array("-2147483649" => 1, "-2147483648" => 2, "2147483647" => 3,
"2147483648" => 4));
Expected result:
Array
(
[-2147483649] => 1
[-2147483648] =>
)
Array
(
[-2147483649] => 1
[-2147483648] => 2
[2147483647] => 3
[2147483648] => 4
)
Actual result:
--
Array
(
[2147483647] => 1
[-2147483648] =>
)
Array
(
[2147483647] => 3
[-2147483648] => 4
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51430&edit=1
Req #51335 [Opn->Fbk]: Search first substring from list
Edit report at http://bugs.php.net/bug.php?id=51335&edit=1
ID: 51335
Updated by: ka...@php.net
Reported by: vovan-ve at yandex dot ru
Summary: Search first substring from list
-Status: Open
+Status: Feedback
Type:Feature/Change Request
Package: Strings related
PHP Version: Irrelevant
-Assigned To:
+Assigned To: kalle
New Comment:
I dont think we should add such functionality that already can be done
with a few lines of php code already, combining strpos/stripos with a
foreach and you should get your result:
Dont take that code for granted, as i wrote it on my cell so it might be
buggy, but should show what I mean
Previous Comments:
[2010-03-20 11:45:58] vovan-ve at yandex dot ru
Description:
If we want to search first substrings from list, we should make multiple
calls to strpos() for each substring. Using PCRE will slowdown
performance. So, we need some new function like:
int strpos_array(string $haystack, array $needles, string &$found [,
int $offset = 0 ])
which will accept array of substrings in $needle, search first position
of them. If nothing found then returns FALSE. If found any substring
then assign it to $found and return its position.
The function name is not important. Other functions for case-insensitive
search and/or for reverse search (stripos_array, strrpos_array,
strripos_array) also useful.
Extending function strpos() to accept array in $needle is not good due
to &$found parameter.
Good example of using such function is writing parser of some data like
SQL dump. Performance of the function should be higher then PCRE.
Test script:
---
$string = 'foo;bar::baz-qwe';
$search = array('-', ';', '::');
$pos = strpos_array($string, $search, $found, 5);
if ($pos === false) {
echo "Nothing found";
}
else {
echo "Found '$found' at $pos";
}
Expected result:
Found '::' at 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=51335&edit=1
[PHP-BUG] Bug #52049 [NEW]: crash when verifying gnupg signature
From:
Operating system: ubuntu linux
PHP version: 5.3.2
Package: Unknown/Other Function
Bug Type: Bug
Bug description:crash when verifying gnupg signature
Description:
Ubuntu 10.04 amd64. 100% reproducable on version 5.3.2-1ubuntu4.2 and
5.2.10.dfsg.1-2ubuntu6.4.
On version 5.2.6.dfsg.1-3ubuntu4.5 works fine!
GnuPG extension installed with "pecl install gnupg".
Key import works fine, but signature verification on valid pgp file crashes
php.
Any ideas how to further debug and find out whats the reason for crash?
Thank you!
# cat cc.php
verify(file_get_contents('valid.gpg'), false, $plaintext);
?>
# gdb php5
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Bug #52045 [Com]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Comment by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 Assigned To: fat New Comment: Can you please try the attached patch on trunk ? It must be also working on branche/PHP_5_3. ++ jerome Previous Comments: [2010-06-11 14:10:14] f...@php.net The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1276258214 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1276258214 [2010-06-11 11:02:04] FractalizeR at yandex dot ru Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Bug #52045 [PATCH]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Patch added by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: php_main_php_ini.c-fpm-cgi.patch Revision: 1276258214 URL: http://bugs.php.net/patch-display.php?bug=52045&patch=php_main_php_ini.c-fpm-cgi.patch&revision=1276258214 Previous Comments: [2010-06-11 11:02:04] FractalizeR at yandex dot ru Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Bug #52035 [Fbk]: Header Redirect Fails
Edit report at http://bugs.php.net/bug.php?id=52035&edit=1 ID: 52035 Updated by: srina...@php.net Reported by: mchotai at fulcrum dot ca Summary: Header Redirect Fails Status: Feedback Type: Bug Package: HTTP related Operating System: Microsoft-IIS/7.0 PHP Version: 5.2.13 New Comment: I am able to redirect successfully with latest php source snapshot. can u pl. attach the output of live http headers to this ? u could do some thing like below from the command line window (start->run->cmd) telnet localhost 80 GET /http://bugs.php.net/bug.php?id=52035&edit=1
Bug #52035 [Opn->Fbk]: Header Redirect Fails
Edit report at http://bugs.php.net/bug.php?id=52035&edit=1
ID: 52035
Updated by: srina...@php.net
Reported by: mchotai at fulcrum dot ca
Summary: Header Redirect Fails
-Status: Open
+Status: Feedback
Type: Bug
Package: HTTP related
Operating System: Microsoft-IIS/7.0
PHP Version: 5.2.13
Previous Comments:
[2010-06-11 14:00:54] srina...@php.net
most likely not a valid bug. pl. check the log file to see if you have
reached the maximum number of redirects.
[2010-06-09 19:45:08] mchotai at fulcrum dot ca
Description:
Hi,
I've encountered a bug in PHP 5.2.13 that doesn't happen in PHP 5.2.10.
My header redirect statement doesn't produce a redirect. No error is
reported.
The line that causes the bug is simply:
header("location:store.php");
In the raw HTTP stream, I can see the redirect information missing
(using ExamDiff on the output shown using LiveHTTPHeaders with Firefox).
I am using two servers which are exactly the same (as they are virtual
machines), both running same IIS, ASP.NET version, etc. The only
difference was the PHP version. When I changed the version back to
5.2.10, both servers worked exactly the same. When I set one to 5.2.13,
it wouldn't do the redirect to the page above.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52035&edit=1
Bug #52035 [Opn]: Header Redirect Fails
Edit report at http://bugs.php.net/bug.php?id=52035&edit=1
ID: 52035
Updated by: srina...@php.net
Reported by: mchotai at fulcrum dot ca
Summary: Header Redirect Fails
Status: Open
Type: Bug
Package: HTTP related
Operating System: Microsoft-IIS/7.0
PHP Version: 5.2.13
New Comment:
most likely not a valid bug. pl. check the log file to see if you have
reached the maximum number of redirects.
Previous Comments:
[2010-06-09 19:45:08] mchotai at fulcrum dot ca
Description:
Hi,
I've encountered a bug in PHP 5.2.13 that doesn't happen in PHP 5.2.10.
My header redirect statement doesn't produce a redirect. No error is
reported.
The line that causes the bug is simply:
header("location:store.php");
In the raw HTTP stream, I can see the redirect information missing
(using ExamDiff on the output shown using LiveHTTPHeaders with Firefox).
I am using two servers which are exactly the same (as they are virtual
machines), both running same IIS, ASP.NET version, etc. The only
difference was the PHP version. When I changed the version back to
5.2.10, both servers worked exactly the same. When I set one to 5.2.13,
it wouldn't do the redirect to the page above.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52035&edit=1
Bug #52044 [Bgs]: Access protected method violation
Edit report at http://bugs.php.net/bug.php?id=52044&edit=1 ID: 52044 User updated by: public at proside dot fr Reported by: public at proside dot fr Summary: Access protected method violation Status: Bogus Type: Bug Package: Class/Object related Operating System: WIN XP SP3+ PHP Version: 5.3.2 New Comment: Ok, many thanks mister :-) Fast, brilliant and useful Previous Comments: [2010-06-11 11:52:23] degeb...@php.net Hi, Please see my answer here: http://news.php.net/php.doc.cvs/6808 $a is "standalone", but it is MyParent instance used within another MyParent instance. It's not leaking any information to other classes, so it isn't violating any contracts. [2010-06-11 11:12:22] public at proside dot fr I almost do agree about your comment, but in my example, $a is a standalone instance of the parent class. Where $a can be used doesn't really matter, it's still a standalone instance of class like any general instance of class. And in the general case the PHP engine logically prevent the access to the protected methods. Here, it seems that the context of execution of a standalone object impacts the contract defined by the OOP rules ! [2010-06-11 10:28:44] degeb...@php.net Yes, you are wrong. One MyParent object knows the private/protected interface of all other MyParent objects, so it is allowed to access it. Other classes don't, so they're not allowed. Thanks for your interest though. [2010-06-11 10:20:25] public at proside dot fr Description: In one case, the PHP engine allows access to the protected methods of an instanciated class As the documentation says : protected methods are only available inside the class that declares it and inside the tree of derivated classes. If you look at the code, we are in none of these case : $a is a standalone instance of MyParent so the protected methods of class MyParent should be hidden. Am i wrong ? Test script: --- new standalone instance of MyParent $a = new MyParent(); # --> here it's possible to access to the protected method of $a ! return $a->getProtectedParent(); } } $cls = new MyChild(); $test = $cls->getPublicChild(); Expected result: Fatal error : access level violation Actual result: -- $test = 'Parent_Protected' -- Edit this bug report at http://bugs.php.net/bug.php?id=52044&edit=1
Bug #52044 [Bgs]: Access protected method violation
Edit report at http://bugs.php.net/bug.php?id=52044&edit=1 ID: 52044 Updated by: degeb...@php.net Reported by: public at proside dot fr Summary: Access protected method violation Status: Bogus Type: Bug Package: Class/Object related Operating System: WIN XP SP3+ PHP Version: 5.3.2 New Comment: Hi, Please see my answer here: http://news.php.net/php.doc.cvs/6808 $a is "standalone", but it is MyParent instance used within another MyParent instance. It's not leaking any information to other classes, so it isn't violating any contracts. Previous Comments: [2010-06-11 11:12:22] public at proside dot fr I almost do agree about your comment, but in my example, $a is a standalone instance of the parent class. Where $a can be used doesn't really matter, it's still a standalone instance of class like any general instance of class. And in the general case the PHP engine logically prevent the access to the protected methods. Here, it seems that the context of execution of a standalone object impacts the contract defined by the OOP rules ! [2010-06-11 10:28:44] degeb...@php.net Yes, you are wrong. One MyParent object knows the private/protected interface of all other MyParent objects, so it is allowed to access it. Other classes don't, so they're not allowed. Thanks for your interest though. [2010-06-11 10:20:25] public at proside dot fr Description: In one case, the PHP engine allows access to the protected methods of an instanciated class As the documentation says : protected methods are only available inside the class that declares it and inside the tree of derivated classes. If you look at the code, we are in none of these case : $a is a standalone instance of MyParent so the protected methods of class MyParent should be hidden. Am i wrong ? Test script: --- new standalone instance of MyParent $a = new MyParent(); # --> here it's possible to access to the protected method of $a ! return $a->getProtectedParent(); } } $cls = new MyChild(); $test = $cls->getPublicChild(); Expected result: Fatal error : access level violation Actual result: -- $test = 'Parent_Protected' -- Edit this bug report at http://bugs.php.net/bug.php?id=52044&edit=1
Bug #52045 [Opn->Asn]: Incorrect php.ini file detection
Edit report at http://bugs.php.net/bug.php?id=52045&edit=1 ID: 52045 Updated by: f...@php.net Reported by: FractalizeR at yandex dot ru Summary: Incorrect php.ini file detection -Status: Open +Status: Assigned Type: Bug Package: FPM related Operating System: CentOS 5.5 PHP Version: 5.3.2 -Assigned To: +Assigned To: fat Previous Comments: [2010-06-11 11:02:04] FractalizeR at yandex dot ru Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit this bug report at http://bugs.php.net/bug.php?id=52045&edit=1
Bug #52044 [Bgs]: Access protected method violation
Edit report at http://bugs.php.net/bug.php?id=52044&edit=1 ID: 52044 User updated by: public at proside dot fr Reported by: public at proside dot fr Summary: Access protected method violation Status: Bogus Type: Bug Package: Class/Object related Operating System: WIN XP SP3+ PHP Version: 5.3.2 New Comment: I almost do agree about your comment, but in my example, $a is a standalone instance of the parent class. Where $a can be used doesn't really matter, it's still a standalone instance of class like any general instance of class. And in the general case the PHP engine logically prevent the access to the protected methods. Here, it seems that the context of execution of a standalone object impacts the contract defined by the OOP rules ! Previous Comments: [2010-06-11 10:28:44] degeb...@php.net Yes, you are wrong. One MyParent object knows the private/protected interface of all other MyParent objects, so it is allowed to access it. Other classes don't, so they're not allowed. Thanks for your interest though. [2010-06-11 10:20:25] public at proside dot fr Description: In one case, the PHP engine allows access to the protected methods of an instanciated class As the documentation says : protected methods are only available inside the class that declares it and inside the tree of derivated classes. If you look at the code, we are in none of these case : $a is a standalone instance of MyParent so the protected methods of class MyParent should be hidden. Am i wrong ? Test script: --- new standalone instance of MyParent $a = new MyParent(); # --> here it's possible to access to the protected method of $a ! return $a->getProtectedParent(); } } $cls = new MyChild(); $test = $cls->getPublicChild(); Expected result: Fatal error : access level violation Actual result: -- $test = 'Parent_Protected' -- Edit this bug report at http://bugs.php.net/bug.php?id=52044&edit=1
Bug #51552 [Asn->Csd]: debug_backtrace() causes segmentation fault and/or memory issues
Edit report at http://bugs.php.net/bug.php?id=51552&edit=1
ID: 51552
Updated by: dmi...@php.net
Reported by: kkotowicz at gmail dot com
Summary: debug_backtrace() causes segmentation fault and/or
memory issues
-Status: Assigned
+Status: Closed
Type: Bug
Package: Reproducible crash
Operating System: win/linux
PHP Version: 5.3.2
Assigned To: dmitry
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:
[2010-06-11 10:53:35] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=300371
Log: Fixed bug #51552 (debug_backtrace() causes segmentation fault
and/or memory issues)
[2010-04-29 18:44:47] kkotowicz at gmail dot com
I dug depper into the issue, it looks as debug_backtrace() and functions
accepting references are causing the problem.
Here's the script that describes it:
this results in:
array(3) {
[0]=>
int(1)
[1]=>
int(0)
[2]=>
string(8) "testthis"
}
array(3) {
[0]=>
int(2)
[1]=>
int(1)
[2]=>
string(8) "! 1 "
}
array(3) {
[0]=>
int(3)
[1]=>
int(2)
[2]=>
int(2)
}
array(3) {
[0]=>
int(4)
[1]=>
int(3)
[2]=>
string(4) "! "
}
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate
134217728 bytes) in E:\tmp\php_bug\bug.php on line 4
for the first iteration, everything is ok. But each next time walk() is
called, the $p argument gets some random value, thus pointing to the
memory issues with debug_backtrace(). The backtrace itself will show
some garbage each next time.
[2010-04-28 19:40:08] kkotowicz at gmail dot com
The same problem occurs when running php 5.3.2/Win32
Backtrace generated from MS Debug Diagnostic Tool below:
Entry point php!mainCRTStartup
Create time 2010-04-28 19:34:00
Time spent in user mode 0 Days 0:0:0.15
Time spent in kernel mode 0 Days 0:0:0.0
Function Arg 1 Arg 2 Arg 3 Source
php5!zend_hash_num_elements+4 1007dbc0
php5!_zval_copy_ctor_func+61 01170378 011a0080 01170a50
php5!zend_startup_builtin_functions+2b54 01171648
011a0278
php5!zend_fetch_debug_backtrace+21a 01170830 00c0ea4c
0001
php5!zend_fetch_debug_backtrace+374 01170830
php5!execute+cdf 011a0278 01172d68 011a0278
php5!execute+4c25 10549738 10544688
php5!execute+1f0 0129cb18 0116f5f0 00c0eb30
php5!zend_call_function+6c1 10544688 105446ac 00c0eb70
php5!zif_max+3d3 0116f5f0 00c0eb30
php5!zif_array_walk+cf 0003 01170260
php5!execute+cdf 011a0080 0116f668 011a0080
php5!execute+4c25 00c0ec28 00c0fed4 00c0fcbc
php5!execute+1f0 0116f668 00c0fed4
php5!zend_execute_scripts+be 0008 0003
php5!php_execute_script+1e2 00c0fed4 0040642c 0001
php!main+a9a 0004 003d31d0 003d3450
php!memcpy+160 000e 7ffdf000
kernel32!BaseProcessStart+23 00402dda
PHP5!ZEND_HASH_NUM_ELEMENTS+4In
php__PID__2516__Date__04_28_2010__Time_07_34_10PM__865__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_num_elements+4 in
E:\tmp\php_bug\bin\php5.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x0008 on thread 0
[2010-04-28 18:30:03] kkotowicz at gmail dot com
gdb backtrace for the failing script below:
#0 zend_hash_num_elements (ht=0x868f630) at
/home/xxx/debugPHP/php-5.3.2/Zend/zend_hash.c:1014
#1 0x082b6665 in debug_backtrace_get_args (curpos=)
at /home/xxx/debugPHP/php-5.3.2/Zend/zend_variables.h:45
#2 0x082b68a2 in zend_fetch_debug_backtrace (return_value=0x868f854,
skip_last=1, provide_object=1)
at /home/xxx/debugPHP/php-5.3.2/Zend/zend_builtin_functions.c:2195
#3 0x082b6b44 in zif_debug_backtrace (ht=0, return_value=0x868f854,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/home/xxx/debugPHP/php-5.3.2/Zend/zend_builtin_functions.c:2269
#4 0x082ec629 in zend_do_fcall_common_helper_SPEC
(exec
Bug #52040 [Opn->Csd]: Fatal error (undefined function) not reported when php within html tag's attr
Edit report at http://bugs.php.net/bug.php?id=52040&edit=1 ID: 52040 User updated by: michal_musial at o2 dot pl Reported by: michal_musial at o2 dot pl Summary: Fatal error (undefined function) not reported when php within html tag's attr -Status: Open +Status: Closed Type: Bug Package: Scripting Engine problem Operating System: Windows 7 Ultimate (any?) PHP Version: 5.3.2 New Comment: I've found the problem source. Turned out it was the browser itself stripping out the invalid line altogether for some reason - Chrome 6.0-dev Testing reavealed that: - IE8 displays the error normally in the browser (which is wrong really as it should be only visible in the source) - Firefox 3.6 shows the error in the source - Opera 10.53 shows the error in the source I'm closing the bug. Thanks for your help fa. Previous Comments: [2010-06-11 10:39:08] michal_musial at o2 dot pl I can confirm that the problem does not exist when parsing the code in CLI mode on my current setup (PHP 5.3.2 VC6 - for apache). This points the problem to php5- module for apache. I am not able to check whether VC9 version is affected as from what windows.php.net says VC9 should not be used with apache binaries and I don't have IIS. [2010-06-10 17:19:41] f...@php.net Please try http://windows.php.net/downloads/releases/php-5.3.2-nts-Win32-VC9-x86.zip with the php.ini-production and try to reproduce [2010-06-10 17:13:33] michal_musial at o2 dot pl I'm no expert in php config, so it's entirely possible. Have a look at my config: http://mmusial.nazwa.pl/php.ini [2010-06-10 17:07:10] f...@php.net Can't reproduce with the VC9 build of 5.3.2 from windows.php.net in CLI mode. Are you sure you have no special php.ini settings (like auto_prepend) or anything related to output buffering? This really looks like a configuration issue at first glance. [2010-06-10 16:48:23] michal_musial at o2 dot pl Also tested it on FreeBSD 7.2-RELEASE with PHP 5.2.11 and Apache 2.2.13. Same problem. 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=52040 -- Edit this bug report at http://bugs.php.net/bug.php?id=52040&edit=1
[PHP-BUG] Bug #52045 [NEW]: Incorrect php.ini file detection
From: Operating system: CentOS 5.5 PHP version: 5.3.2 Package: FPM related Bug Type: Bug Bug description:Incorrect php.ini file detection Description: If there is a file or directory named php.ini in the current directory and you start php-fpm from within this directory, phpinfo() output shows, that php-fpm is trying to use this file/directory as main configuration file for all it's children. The case with such php.ini being a file seems to be undocumented and unwanted behavior because by default [prefix]/lib/php.ini should be used. The case with php.ini being a directory leads to all php settings to be silently reverted to their defaults. No error message is shown about that php.ini is not a file or does not exist or whatever. Test script: --- cd ~ mkdir php.ini php-fpm After that open a page, containing phpinfo(); line and check php.ini settings section. -- Edit bug report at http://bugs.php.net/bug.php?id=52045&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52045&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52045&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52045&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52045&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52045&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52045&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52045&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52045&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52045&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52045&r=support Expected behavior: http://bugs.php.net/fix.php?id=52045&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52045&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52045&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52045&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52045&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52045&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52045&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52045&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52045&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52045&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52045&r=mysqlcfg
Bug #52040 [Fbk->Opn]: Fatal error (undefined function) not reported when php within html tag's attr
Edit report at http://bugs.php.net/bug.php?id=52040&edit=1 ID: 52040 User updated by: michal_musial at o2 dot pl Reported by: michal_musial at o2 dot pl Summary: Fatal error (undefined function) not reported when php within html tag's attr -Status: Feedback +Status: Open Type: Bug Package: Scripting Engine problem Operating System: Windows 7 Ultimate (any?) PHP Version: 5.3.2 New Comment: I can confirm that the problem does not exist when parsing the code in CLI mode on my current setup (PHP 5.3.2 VC6 - for apache). This points the problem to php5- module for apache. I am not able to check whether VC9 version is affected as from what windows.php.net says VC9 should not be used with apache binaries and I don't have IIS. Previous Comments: [2010-06-10 17:19:41] f...@php.net Please try http://windows.php.net/downloads/releases/php-5.3.2-nts-Win32-VC9-x86.zip with the php.ini-production and try to reproduce [2010-06-10 17:13:33] michal_musial at o2 dot pl I'm no expert in php config, so it's entirely possible. Have a look at my config: http://mmusial.nazwa.pl/php.ini [2010-06-10 17:07:10] f...@php.net Can't reproduce with the VC9 build of 5.3.2 from windows.php.net in CLI mode. Are you sure you have no special php.ini settings (like auto_prepend) or anything related to output buffering? This really looks like a configuration issue at first glance. [2010-06-10 16:48:23] michal_musial at o2 dot pl Also tested it on FreeBSD 7.2-RELEASE with PHP 5.2.11 and Apache 2.2.13. Same problem. [2010-06-10 16:41:49] michal_musial at o2 dot pl Description: PHP does not print Fatal error when an undefined function is called from within a html tag's attribute. Error is saved to php error log if one is specified in php.ini, but there's nothing being printed. Execution ends at the line preceding the line containing the undefined function. Test script: --- p1 p2 p3 Expected result: p1 http://bugs.php.net/bug.php?id=52040&edit=1
Bug #52044 [Opn->Bgs]: Access protected method violation
Edit report at http://bugs.php.net/bug.php?id=52044&edit=1 ID: 52044 Updated by: degeb...@php.net Reported by: public at proside dot fr Summary: Access protected method violation -Status: Open +Status: Bogus Type: Bug Package: Class/Object related Operating System: WIN XP SP3+ PHP Version: 5.3.2 New Comment: Yes, you are wrong. One MyParent object knows the private/protected interface of all other MyParent objects, so it is allowed to access it. Other classes don't, so they're not allowed. Thanks for your interest though. Previous Comments: [2010-06-11 10:20:25] public at proside dot fr Description: In one case, the PHP engine allows access to the protected methods of an instanciated class As the documentation says : protected methods are only available inside the class that declares it and inside the tree of derivated classes. If you look at the code, we are in none of these case : $a is a standalone instance of MyParent so the protected methods of class MyParent should be hidden. Am i wrong ? Test script: --- new standalone instance of MyParent $a = new MyParent(); # --> here it's possible to access to the protected method of $a ! return $a->getProtectedParent(); } } $cls = new MyChild(); $test = $cls->getPublicChild(); Expected result: Fatal error : access level violation Actual result: -- $test = 'Parent_Protected' -- Edit this bug report at http://bugs.php.net/bug.php?id=52044&edit=1
[PHP-BUG] Bug #52044 [NEW]: Access protected method violation
From: Operating system: WIN XP SP3+ PHP version: 5.3.2 Package: Class/Object related Bug Type: Bug Bug description:Access protected method violation Description: In one case, the PHP engine allows access to the protected methods of an instanciated class As the documentation says : protected methods are only available inside the class that declares it and inside the tree of derivated classes. If you look at the code, we are in none of these case : $a is a standalone instance of MyParent so the protected methods of class MyParent should be hidden. Am i wrong ? Test script: --- new standalone instance of MyParent $a = new MyParent(); # --> here it's possible to access to the protected method of $a ! return $a->getProtectedParent(); } } $cls = new MyChild(); $test = $cls->getPublicChild(); Expected result: Fatal error : access level violation Actual result: -- $test = 'Parent_Protected' -- Edit bug report at http://bugs.php.net/bug.php?id=52044&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52044&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52044&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52044&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52044&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52044&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52044&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52044&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52044&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52044&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52044&r=support Expected behavior: http://bugs.php.net/fix.php?id=52044&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52044&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52044&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52044&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52044&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52044&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52044&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52044&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52044&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52044&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52044&r=mysqlcfg
Bug #42778 [Com]: realpath() adds trailing slash
Edit report at http://bugs.php.net/bug.php?id=42778&edit=1
ID: 42778
Comment by: php dot net at digilog dot de
Reported by: k dot bizuns at inbox dot lv
Summary: realpath() adds trailing slash
Status: Bogus
Type: Bug
Package: *Directory/Filesystem functions
Operating System: Windows
PHP Version: 5.2.4
New Comment:
Does it really make sense that this function behaves so inconsistently
about its
trailing slashes between Linux and Win?:
LINUX (tested with PHP 5.2.11):
---
realpath('.')
: string = "/myhttpdfolder"
realpath('./')
: string = "/myhttpdfolder"
realpath('fileadmin')
: string = "/myhttpdfolder/fileadmin"
realpath('fileadmin/')
: string = "/myhttpdfolder/fileadmin"
WINDOWS (tested with PHP 5.2.5):
---
realpath('.')
: string = "C:\\myhttpdfolder"
realpath('./')
: string = "C:\\myhttpdfolder\\"
realpath('fileadmin')
: string = "C:\\myhttpdfolder\\fileadmin"
realpath('fileadmin/')
: string = "C:\\myhttpdfolder\\fileadmin\\"
Previous Comments:
[2007-10-02 09:33:23] tony2...@php.net
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
[2007-09-27 13:49:50] k dot bizuns at inbox dot lv
Description:
This code in PHP 5.2.4 gives an output with trailing slash (example:
C:\www\)
PHP 5.2.3 not (example: C:\www).
Who is right? Tested on WinXP.
--
Edit this bug report at http://bugs.php.net/bug.php?id=42778&edit=1
