Bug #55673 [Asn]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1 ID: 55673 Updated by: larue...@php.net Reported by:der...@php.net Summary:Compiler creates (unused) compiled variables for self::$foo Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.3SVN-2011-09-12 (SVN) Assigned To:dmitry Block user comment: N Private report: N New Comment: this cv is created in fetch_simple_variable_ex, and fetch_simple_variable_ex is used by a lot of logic, so I think we should alter the parse.y to make the class::$static_member not to denpend on a reference_variable. I have tried, but bring in new reduce conflict. Previous Comments: [2011-09-14 15:29:34] larue...@php.net I'd better to report another one about the NOP opline, sorry agian. [2011-09-14 15:24:23] larue...@php.net OOPS!, I must lost my mind, what I was doing is erease NOP opline(god know How can I read this bug as "REMOVE UNUSED NOP" opline) sorry, but maybe this patch is also a litte useful... [2011-09-14 15:10:14] larue...@php.net I have made a patch for this, and make whole test after patched. made sure that there is no new test failed after patched. TEST RESULT: trunk: http://pastebin.com/gMYc2Fp5 5.4branch: http://pastebin.com/7EePEE43 5.3branch: http://pastebin.com/m4wirXjr [2011-09-14 15:07:01] larue...@php.net The following patch has been added/updated: Patch Name: bug55673.diff Revision: 1316012821 URL: https://bugs.php.net/patch-display.php?bug=55673&patch=bug55673.diff&revision=1316012821 [2011-09-14 14:37:02] larue...@php.net after a quick digging, I found this is caused by zend_do_early_binding, which make the declare_class to NOP after use it. I will try to make a patch for this. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55673 -- Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)
Edit report at https://bugs.php.net/bug.php?id=52569&edit=1 ID: 52569 Comment by: shadow+dphp at la3 dot org Reported by:mplomer at gmx dot de Summary:Implement "ondemand" process-manager (to allow zero children) Status: Analyzed Type: Feature/Change Request Package:FPM related PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: Since there has been no activity on this issue for a while, and I think it would be *very* good to have this ondemand process manager on stable releases as soon as possible, I have decided to try the patch by myself and report the results. Also, I am a die-hard Debian user, so I tried the patch (v11-5.3) with the latest available Debian packages in sid (php 5.3.8 + a number of other patches). I found a minor issue at compile time, due to the fact that the "sapi/fpm/fpm/events" folder is not created by the Makefile within the build directory structure (if you specify a build directory separated from the sources). I solved this issue easily by inserting a new line in the "sapi/fpm/Makefile.frag" file: $(builddir)/fpm: @mkdir -p $(builddir)/fpm + @mkdir -p $(builddir)/fpm/events After this minor correction everything compiled well. Thus, I proceeded to run some tests, using apache (Apache/2.2.20) + mod_fastcgi (2.4.7~0910052141-1) as the php5-fpm frontend. In this setup, I created a separate virtual host in front of each pool, and used the following apache config in there: ScriptAlias /fcgi-bin/ "/var/www/virtual/pool.test.com/fcgi-bin/" FastCGIExternalServer /var/www/virtual/pool.test.com/fcgi-bin/php-cgi \ -socket /var/lib/php5/pools/pool.test.com AddHandler php-fastcgi .php Action php-fastcgi /fcgi-bin/php-cgi The sockets themselves are owned by the apache's user (www-data), whereas the php interpreters run under a different user for each pool. Results: General - Pool has to start with 0 children - OK - The "ondemand" pm can be enabled - OK - All three pm's can be enabled at the same time (for different pools, obviously) - OK Concurrent requests - Children has to be forked immediately on new requests without delay - OK - Idle children has to be killed after pm.process_idle_timeout + 0-1s - OK - When there are more than one idle children, kill only one per second PER POOL - Almost OK (only does it if pm.process_idle_timeout > 1) Reaching pm.max_children limit - No more processes has to be created - OK - Requests have to wait until one child becomes idle and then get handled immediately without further delay - OK - When limit is reached, issue a warning and increase status counter (and do this only once) - OK: [14-Sep-2011 23:16:07] WARNING: [pool site1.test.com] server reached max_children setting (4), consider raising it - Warning is re-issued after children count decreases and hit the limit again - OK CPU burns - When reaching max_children limit, pause libevent callback and reenable it in the maintenance routine, to avoid CPU burns - OK/DUNNO CPU usage does not spike under these conditions, but I do not know anything about libevent. - When children takes too long to accept() the request, avoid CPU burn - OK/DUNNO Tried with "ab -c300", no CPU burns observed. Observations - "ondemand" spawns new children *way* faster than "dynamic" does - each "dynamic" process consumes about 0.1% cpu time while idle, whereas idle "ondemand" and "static" pools do not impose any load at all. Problems - pm.min_spare_servers default value if unspecified in the pool config is 0, whereas the default pm is "dynamic". - pm.max_spare_servers default value if unspecified in the pool config is 0. Final note: Jerome, the ondemand process manager is *amazing*. If it combines well with the global maximum number of processes from #55166 , this is effectively the holy grail of php for virtual hosting companies. Big big congratulations and do not hesitate to ask me for any further info/tests that you need to make this a reality! Previous Comments: [2011-07-15 08:47:47] dbetz at df dot eu Hi jerome, the test ist successful for me. Everything works fine with PHP5.3.7rc4-dev and ondemand patch v11 Greets, Daniel [2011-07-14 18:47:05] f...@php.net Here is a complete new release of the ondemand patch: the version 11. I've rewritten entierly the event part in order to have access to the following mechanism: select (posix) poll (posix) <- was the mechanism in used before epoll (linux) kqueue (*bsd) /dev/poll (solaris) port (solaris) all this mechanism supports classic Level-Triggered events which is not
[PHP-BUG] Bug #55696 [NEW]: __CLASS__ includes the namespace definition
From: Operating system: PHP version: 5.3.8 Package: Unknown/Other Function Bug Type: Bug Bug description:__CLASS__ includes the namespace definition Description: With the introduction of namespaces, the __CLASS__ magic constant has changed (without being documented) to include the current namespace as part of the class name. I submit that since there is a __NAMESPACE__ magic constant that the __CLASS__ constant should be reverted to its previous behavior. It seems more natural to concatenate __NAMESPACE__ and __CLASS__ to get a qualified name, rather than using basename() to get just the class name. At the very least, the documentation for namespaces (http://php.net/namespace), Magic Constants (http://us.php.net/manual/en/language.constants.predefined.php), and Backwards Incompatible Changes (http://us.php.net/manual/en/migration53.incompatible.php) should be updated to reflect this change. Test script: --- Expected result: I expect the above test script to return just the class name (i.e., Bar). Actual result: -- The test script above returns the qualified class name (i.e., Foo\Bar). -- Edit bug report at https://bugs.php.net/bug.php?id=55696&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55696&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55696&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55696&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55696&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55696&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55696&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55696&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55696&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55696&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55696&r=support Expected behavior: https://bugs.php.net/fix.php?id=55696&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55696&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55696&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55696&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55696&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55696&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55696&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55696&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55696&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55696&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55696&r=mysqlcfg
Bug #48908 [Com]: Cannot query smalldatetime type columns
Edit report at https://bugs.php.net/bug.php?id=48908&edit=1 ID: 48908 Comment by: me at abiusx dot com Reported by:aaron at aarondm dot com Summary:Cannot query smalldatetime type columns Status: Open Type: Bug Package:MSSQL related Operating System: ArchLinux PHP Version:5.2.10 Block user comment: N Private report: N New Comment: As described in http://php.net/manual/es/function.mssql-query.php comments, Adding mssql.datetimeconvert = Off in php.ini fixes the issue! Previous Comments: [2011-06-30 04:55:10] Fr33z3m4n at gmx dot net Same Problem and is reproducable. Debian 2.6.26-26lenny1 PHP Version 5.3.6-12 Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH [2010-07-20 11:51:29] tom dot lawton at kondor dot co dot uk PHP 5.2.4 / ubuntu 8.10LTS has this bug and is reproducable. Suhosin patch reports canary mismatch if a query returns smalldatetime. Apache does not trigger 500, nor does PHP report any error to the page - it dies silently. [2010-01-07 12:36:21] undicizeri at gmail dot com Same bug here. I'm using Ubuntu with php 5.2.6 and debian with php 5.2.12. [2009-12-21 11:22:41] php at mike2k dot com Sample query/workaround: old: SELECT acct_itm.cre_dtm AS cre_dtm new: SELECT CONVERT(varchar(10),acct_itm.cre_dtm,120) AS cre_dtm Not the most ideal. Might be a bug in the FreeTDS driver and not something PHP can handle but has to pass upstream. [2009-12-21 10:13:22] php at mike2k dot com Always repeatable. This is an issue for us as well. The previous comment is from a Windows user so they're probably able to leverage more native Windows MSSQL libraries... PHP 5.2.11, on Linux, using FreeTDS on CentOS 5.3 (or 5.4, not sure) x86_64 The workaround is having to cast the column inside of the query. I will try to post an example workaround query when I grab one from the dev team. Related Packages/versions of the driver, just in case: freetds-devel-0.64-11.el5.centos freetds-devel-0.64-6.el5 freetds-0.64-11.el5.centos freetds-0.64-6.el5 unixODBC-2.2.11-7.1 (32 bit) unixODBC-2.2.11-7.1 (64 bit) unixODBC-devel-2.2.11-7.1 (32 bit) unixODBC-devel-2.2.11-7.1 (64 bit) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48908 -- Edit this bug report at https://bugs.php.net/bug.php?id=48908&edit=1
Bug #55300 [Asn]: \DirectoryIterator, parent::__construct() and \LogicException
Edit report at https://bugs.php.net/bug.php?id=55300&edit=1 ID: 55300 User updated by:frederic dot hardy at mageekbox dot net Reported by:frederic dot hardy at mageekbox dot net Summary:\DirectoryIterator, parent::__construct() and \LogicException Status: Assigned Type: Bug Package:SPL related Operating System: Linux PHP Version:5.4.0alpha2 Assigned To:cataphract Block user comment: N Private report: N New Comment: \Phar has the same problem, because this class extends \recursiveDirectoryIterator. And stream wrapper can not be used with it because "Phar objects can only be created from local files". Previous Comments: [2011-09-02 20:03:27] krossekrabbe at gmail dot com No, it's not only a BC break. It's exactly the same, it is not possible to extend the class. Not when calling parent::__construct(), nor when not overriding __construct() at all. [2011-08-09 08:52:19] cataphr...@php.net I wouldn't consider these duplicates. #55175 is an actual problem, this is simply an intended BC break that turned out to have a larger impact than I expected. I'll take care of both not after the beginning of next week. [2011-08-09 08:46:37] s...@php.net Actually according to my test case in https://bugs.php.net/bug.php?id=55175 - it's even happening if you don't redefine the constructor at all. It prevents extending the class altogether, which makes no sense to me. [2011-08-09 08:44:46] s...@php.net The main issue is not that it's a BC break I'd say, it's that apparently adding the call to parent::__construct does not fix the issue, the exception is always thrown if you try to have your own constructor in the extending class. BTW: This is a duplicate of https://bugs.php.net/bug.php?id=55175 IMO. [2011-08-04 06:56:27] frederic dot hardy at mageekbox dot net This BC break is a problem with the symfony 2 framework. All command throw this exception : [LogicException] In the constructor of Symfony\Component\Finder\SplFileInfo, parent::__construct() must be called and its exceptions cannot be cleared The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55300 -- Edit this bug report at https://bugs.php.net/bug.php?id=55300&edit=1
Bug #55695 [Opn]: Compiler create unused opline(NOP)
Edit report at https://bugs.php.net/bug.php?id=55695&edit=1
ID: 55695
Updated by: larue...@php.net
Reported by:larue...@php.net
Summary:Compiler create unused opline(NOP)
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:trunk-SVN-2011-09-14 (SVN)
-Assigned To:
+Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Dmitry, as I said in #55673, sorry for that mis-fix, heh, anyway, I report this
to you, you can mark simply it as won't fix :)
Previous Comments:
[2011-09-14 15:32:52] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55695.diff
Revision: 1316014372
URL:
https://bugs.php.net/patch-display.php?bug=55695&patch=bug55695.diff&revision=1316014372
[2011-09-14 15:32:17] larue...@php.net
Description:
When having the following code:
The compiler generates compiled a totally unused NOP opline:
$ php -dvld.active=1 -r 'class foo { function bar() { self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
Test script:
---
no
--
Edit this bug report at https://bugs.php.net/bug.php?id=55695&edit=1
Bug #55695 [PATCH]: Compiler create unused opline(NOP)
Edit report at https://bugs.php.net/bug.php?id=55695&edit=1
ID: 55695
Patch added by: larue...@php.net
Reported by:larue...@php.net
Summary:Compiler create unused opline(NOP)
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:trunk-SVN-2011-09-14 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug55695.diff
Revision: 1316014372
URL:
https://bugs.php.net/patch-display.php?bug=55695&patch=bug55695.diff&revision=1316014372
Previous Comments:
[2011-09-14 15:32:17] larue...@php.net
Description:
When having the following code:
The compiler generates compiled a totally unused NOP opline:
$ php -dvld.active=1 -r 'class foo { function bar() { self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
Test script:
---
no
--
Edit this bug report at https://bugs.php.net/bug.php?id=55695&edit=1
[PHP-BUG] Bug #55695 [NEW]: Compiler create unused opline(NOP)
From: laruence
Operating system:
PHP version: trunk-SVN-2011-09-14 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Compiler create unused opline(NOP)
Description:
When having the following code:
The compiler generates compiled a totally unused NOP opline:
$ php -dvld.active=1 -r 'class foo { function bar() { self::$bar = 42; }
}'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return
operands
-
1 0 > NOP
1> RETURN
null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return
operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1
'bar'
2 ASSIGN
$1, 42
3> RETURN
null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
Test script:
---
no
--
Edit bug report at https://bugs.php.net/bug.php?id=55695&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55695&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55695&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55695&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55695&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55695&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55695&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55695&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55695&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55695&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55695&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55695&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55695&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55695&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55695&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55695&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55695&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55695&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55695&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55695&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55695&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55695&r=mysqlcfg
Bug #55673 [Asn]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1
ID: 55673
Updated by: larue...@php.net
Reported by:der...@php.net
Summary:Compiler creates (unused) compiled variables for
self::$foo
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3SVN-2011-09-12 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I'd better to report another one about the NOP opline, sorry agian.
Previous Comments:
[2011-09-14 15:24:23] larue...@php.net
OOPS!, I must lost my mind, what I was doing is erease NOP opline(god know How
can I read this bug as "REMOVE UNUSED NOP" opline)
sorry, but maybe this patch is also a litte useful...
[2011-09-14 15:10:14] larue...@php.net
I have made a patch for this, and make whole test after patched. made sure that
there is no new test failed after patched.
TEST RESULT:
trunk: http://pastebin.com/gMYc2Fp5
5.4branch: http://pastebin.com/7EePEE43
5.3branch: http://pastebin.com/m4wirXjr
[2011-09-14 15:07:01] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55673.diff
Revision: 1316012821
URL:
https://bugs.php.net/patch-display.php?bug=55673&patch=bug55673.diff&revision=1316012821
[2011-09-14 14:37:02] larue...@php.net
after a quick digging, I found this is caused by zend_do_early_binding, which
make
the declare_class to NOP after use it.
I will try to make a patch for this.
[2011-09-12 13:47:48] der...@php.net
Description:
When having the following code:
The compiler generates compiled variable !0 for $bar, even though it's a class
variable:
derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() {
self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
End of class foo.
14:41 <@Derick> dmitry: I am wondering why self::$foo creates a compiled
variable. Any idea?
14:42 <@Derick> dmitry: it creates it, but it's never used
14:44 <@dmitry> I see. It's probably because od simple one-pass compiler that
first interpret $foo as local variable and only then as a class variable :)
14:44 <@Derick> dmitry: any way we can fix that perhaps?
14:44 <@dmitry> Derick: could you please create a bug and assign it to me
14:44 <@Derick> yes, sure
--
Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Req #54577 [Csd->ReO]: script_name in status page
Edit report at https://bugs.php.net/bug.php?id=54577&edit=1 ID: 54577 Updated by: f...@php.net Reported by:erno dot kovacs at freemail dot hu Summary:script_name in status page -Status: Closed +Status: Re-Opened Type: Feature/Change Request Package:FPM related Operating System: linux PHP Version:5.3.6 Assigned To:fat Block user comment: N Private report: N Previous Comments: [2011-09-14 15:17:10] erno dot kovacs at freemail dot hu 5.3.8 is out and this feature is missing. [2011-07-04 18:42:04] f...@php.net In fact I revert the patch in 5.3.x because 5.3.x was in a relase process (for 5.3.7). I'll recommit the patch when 5.3.7 will be out. So please wait for 5.3.8 or use a 5.4 snapshot [2011-07-02 12:11:51] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Please see documentation in php-fpm.conf [2011-07-02 12:10:19] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=312812 Log: - Implemented FR #54577 (Enhanced status page with full status and details about each processes - Added a web page (status.html) for real-time FPM status - Fixed missing Expires and Cache-Control headers for ping and status pages [2011-04-20 19:07:28] erno dot kovacs at freemail dot hu Description: I can already see the script_filename in fpm_shm_slot_s structure, please add the currently served script filenames into the status page. Expected result: accepted conn:12073 pool: www process manager: static idle processes: 35 active processes: 65 total processes: 100 max children reached: 1 Active workers: www[pid=1234]: http://www.foobar.com/index1.php www[pid=1235]: http://www.foobar.com/index2.php otherpoolname[pid=1236]: http://www.foobar.com/index3.php Idle workers: www[pid=1237] www[pid=1238] -- Edit this bug report at https://bugs.php.net/bug.php?id=54577&edit=1
Bug #55673 [Asn]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1
ID: 55673
Updated by: larue...@php.net
Reported by:der...@php.net
Summary:Compiler creates (unused) compiled variables for
self::$foo
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3SVN-2011-09-12 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
OOPS!, I must lost my mind, what I was doing is erease NOP opline(god know How
can I read this bug as "REMOVE UNUSED NOP" opline)
sorry, but maybe this patch is also a litte useful...
Previous Comments:
[2011-09-14 15:10:14] larue...@php.net
I have made a patch for this, and make whole test after patched. made sure that
there is no new test failed after patched.
TEST RESULT:
trunk: http://pastebin.com/gMYc2Fp5
5.4branch: http://pastebin.com/7EePEE43
5.3branch: http://pastebin.com/m4wirXjr
[2011-09-14 15:07:01] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55673.diff
Revision: 1316012821
URL:
https://bugs.php.net/patch-display.php?bug=55673&patch=bug55673.diff&revision=1316012821
[2011-09-14 14:37:02] larue...@php.net
after a quick digging, I found this is caused by zend_do_early_binding, which
make
the declare_class to NOP after use it.
I will try to make a patch for this.
[2011-09-12 13:47:48] der...@php.net
Description:
When having the following code:
The compiler generates compiled variable !0 for $bar, even though it's a class
variable:
derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() {
self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
End of class foo.
14:41 <@Derick> dmitry: I am wondering why self::$foo creates a compiled
variable. Any idea?
14:42 <@Derick> dmitry: it creates it, but it's never used
14:44 <@dmitry> I see. It's probably because od simple one-pass compiler that
first interpret $foo as local variable and only then as a class variable :)
14:44 <@Derick> dmitry: any way we can fix that perhaps?
14:44 <@dmitry> Derick: could you please create a bug and assign it to me
14:44 <@Derick> yes, sure
--
Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Req #54577 [Com]: script_name in status page
Edit report at https://bugs.php.net/bug.php?id=54577&edit=1 ID: 54577 Comment by: erno dot kovacs at freemail dot hu Reported by:erno dot kovacs at freemail dot hu Summary:script_name in status page Status: Closed Type: Feature/Change Request Package:FPM related Operating System: linux PHP Version:5.3.6 Assigned To:fat Block user comment: N Private report: N New Comment: 5.3.8 is out and this feature is missing. Previous Comments: [2011-07-04 18:42:04] f...@php.net In fact I revert the patch in 5.3.x because 5.3.x was in a relase process (for 5.3.7). I'll recommit the patch when 5.3.7 will be out. So please wait for 5.3.8 or use a 5.4 snapshot [2011-07-02 12:11:51] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Please see documentation in php-fpm.conf [2011-07-02 12:10:19] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=312812 Log: - Implemented FR #54577 (Enhanced status page with full status and details about each processes - Added a web page (status.html) for real-time FPM status - Fixed missing Expires and Cache-Control headers for ping and status pages [2011-04-20 19:07:28] erno dot kovacs at freemail dot hu Description: I can already see the script_filename in fpm_shm_slot_s structure, please add the currently served script filenames into the status page. Expected result: accepted conn:12073 pool: www process manager: static idle processes: 35 active processes: 65 total processes: 100 max children reached: 1 Active workers: www[pid=1234]: http://www.foobar.com/index1.php www[pid=1235]: http://www.foobar.com/index2.php otherpoolname[pid=1236]: http://www.foobar.com/index3.php Idle workers: www[pid=1237] www[pid=1238] -- Edit this bug report at https://bugs.php.net/bug.php?id=54577&edit=1
Bug #55673 [Asn]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1
ID: 55673
Updated by: larue...@php.net
Reported by:der...@php.net
Summary:Compiler creates (unused) compiled variables for
self::$foo
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3SVN-2011-09-12 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I have made a patch for this, and make whole test after patched. made sure that
there is no new test failed after patched.
TEST RESULT:
trunk: http://pastebin.com/gMYc2Fp5
5.4branch: http://pastebin.com/7EePEE43
5.3branch: http://pastebin.com/m4wirXjr
Previous Comments:
[2011-09-14 15:07:01] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55673.diff
Revision: 1316012821
URL:
https://bugs.php.net/patch-display.php?bug=55673&patch=bug55673.diff&revision=1316012821
[2011-09-14 14:37:02] larue...@php.net
after a quick digging, I found this is caused by zend_do_early_binding, which
make
the declare_class to NOP after use it.
I will try to make a patch for this.
[2011-09-12 13:47:48] der...@php.net
Description:
When having the following code:
The compiler generates compiled variable !0 for $bar, even though it's a class
variable:
derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() {
self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
End of class foo.
14:41 <@Derick> dmitry: I am wondering why self::$foo creates a compiled
variable. Any idea?
14:42 <@Derick> dmitry: it creates it, but it's never used
14:44 <@dmitry> I see. It's probably because od simple one-pass compiler that
first interpret $foo as local variable and only then as a class variable :)
14:44 <@Derick> dmitry: any way we can fix that perhaps?
14:44 <@dmitry> Derick: could you please create a bug and assign it to me
14:44 <@Derick> yes, sure
--
Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Bug #55673 [PATCH]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1
ID: 55673
Patch added by: larue...@php.net
Reported by:der...@php.net
Summary:Compiler creates (unused) compiled variables for
self::$foo
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3SVN-2011-09-12 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug55673.diff
Revision: 1316012821
URL:
https://bugs.php.net/patch-display.php?bug=55673&patch=bug55673.diff&revision=1316012821
Previous Comments:
[2011-09-14 14:37:02] larue...@php.net
after a quick digging, I found this is caused by zend_do_early_binding, which
make
the declare_class to NOP after use it.
I will try to make a patch for this.
[2011-09-12 13:47:48] der...@php.net
Description:
When having the following code:
The compiler generates compiled variable !0 for $bar, even though it's a class
variable:
derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() {
self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
End of class foo.
14:41 <@Derick> dmitry: I am wondering why self::$foo creates a compiled
variable. Any idea?
14:42 <@Derick> dmitry: it creates it, but it's never used
14:44 <@dmitry> I see. It's probably because od simple one-pass compiler that
first interpret $foo as local variable and only then as a class variable :)
14:44 <@Derick> dmitry: any way we can fix that perhaps?
14:44 <@dmitry> Derick: could you please create a bug and assign it to me
14:44 <@Derick> yes, sure
--
Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Bug #55552 [Asn->Csd]: bad encoding not detected
Edit report at https://bugs.php.net/bug.php?id=2&edit=1 ID: 2 Updated by: dmi...@php.net Reported by:paj...@php.net Summary:bad encoding not detected -Status: Assigned +Status: Closed Type: Bug Package:Unicode Engine related Operating System: Windows PHP Version:5.4SVN-2011-08-31 (snap) Assigned To:dmitry Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-09-14 15:00:12] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=316751 Log: Fixed bug #2 (bad encoding not detected) [2011-08-31 12:43:15] paj...@php.net Description: See zend\tests\multibyte\multibyte_encoding_006.phpt, it fails under windows -- Edit this bug report at https://bugs.php.net/bug.php?id=2&edit=1
[PHP-BUG] Req #55694 [NEW]: Expose additionnal readline variable to prevent default filename completion
From:
Operating system:
PHP version: 5.3.8
Package: Readline related
Bug Type: Feature/Change Request
Bug description:Expose additionnal readline variable to prevent default
filename completion
Description:
Actually, when using a custom completion function with
readline_completion_function(), if this custom completion function does not
find any match, it falls back to the default filename completion.
In order to prevent this behaviour, the C API of readline provides a
variable named "rl_attempted_completion_over". Defining this variable to a
non-zero value disables the uses of the default filename completion.
This variable is not exposed to PHP and the filename completion cannot be
bypassed. The provided patch exposes this variable to PHP, and allows to
use readline_info("attempted_completion_over", 1) in the PHP completion
function to prevent default filename completion to occurs.
There is a bug report but it s closed since 2005
https://bugs.php.net/bug.php?id=31796
Another bug report for this https://bugs.php.net/bug.php?id=48089 with a
patch which does the job but in a wrong way, imo.
--
Edit bug report at https://bugs.php.net/bug.php?id=55694&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55694&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55694&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55694&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55694&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55694&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55694&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55694&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55694&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55694&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55694&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55694&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55694&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55694&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55694&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55694&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55694&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55694&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55694&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55694&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55694&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55694&r=mysqlcfg
Bug #55673 [Asn]: Compiler creates (unused) compiled variables for self::$foo
Edit report at https://bugs.php.net/bug.php?id=55673&edit=1
ID: 55673
Updated by: larue...@php.net
Reported by:der...@php.net
Summary:Compiler creates (unused) compiled variables for
self::$foo
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3SVN-2011-09-12 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
after a quick digging, I found this is caused by zend_do_early_binding, which
make
the declare_class to NOP after use it.
I will try to make a patch for this.
Previous Comments:
[2011-09-12 13:47:48] der...@php.net
Description:
When having the following code:
The compiler generates compiled variable !0 for $bar, even though it's a class
variable:
derick@whisky:/tmp$ php -dvld.active=1 -r 'class foo { function bar() {
self::$bar = 42; } }'
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: (null)
number of ops: 2
compiled vars: none
line # * op fetch ext return operands
-
1 0 > NOP
1> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 1
path #1: 0,
Class foo:
Function bar:
Finding entry points
Branch analysis from position: 0
Return found
filename: Command line code
function name: bar
number of ops: 4
compiled vars: !0 = $bar
line # * op fetch ext return operands
-
0 > ZEND_FETCH_CLASS 1
1 FETCH_W static member $1 'bar'
2 ASSIGN $1, 42
3> RETURN null
branch: # 0; line: 1-1; sop: 0; eop: 3
path #1: 0,
End of function bar.
End of class foo.
14:41 <@Derick> dmitry: I am wondering why self::$foo creates a compiled
variable. Any idea?
14:42 <@Derick> dmitry: it creates it, but it's never used
14:44 <@dmitry> I see. It's probably because od simple one-pass compiler that
first interpret $foo as local variable and only then as a class variable :)
14:44 <@Derick> dmitry: any way we can fix that perhaps?
14:44 <@dmitry> Derick: could you please create a bug and assign it to me
14:44 <@Derick> yes, sure
--
Edit this bug report at https://bugs.php.net/bug.php?id=55673&edit=1
Bug #54556 [Ver]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556&edit=1 ID: 54556 Updated by: dmi...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Assigned To:dmitry Block user comment: N Private report: N New Comment: I've added a bit better patch (for trunk), but I'm not sure we need it. At least it "breaks" about 30 tests. Previous Comments: [2011-09-14 13:51:04] dmi...@php.net The following patch has been added/updated: Patch Name: wrong-array-access.diff Revision: 1316008264 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=wrong-array-access.diff&revision=1316008264 [2011-09-14 07:28:36] larue...@php.net dmitry, plz look at this, thanks [2011-07-26 11:12:22] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311678742 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311678742 [2011-07-25 12:10:52] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311595852 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311595852 [2011-07-25 05:40:56] larue...@php.net I have submit a patch for this. and I think this situation should trigger a notice to help developers aware of this. since this mostly might be bad codes.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54556 -- Edit this bug report at https://bugs.php.net/bug.php?id=54556&edit=1
Bug #54556 [PATCH]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556&edit=1 ID: 54556 Patch added by: dmi...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: wrong-array-access.diff Revision: 1316008264 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=wrong-array-access.diff&revision=1316008264 Previous Comments: [2011-09-14 07:28:36] larue...@php.net dmitry, plz look at this, thanks [2011-07-26 11:12:22] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311678742 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311678742 [2011-07-25 12:10:52] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311595852 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311595852 [2011-07-25 05:40:56] larue...@php.net I have submit a patch for this. and I think this situation should trigger a notice to help developers aware of this. since this mostly might be bad codes.. [2011-07-25 05:29:29] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311586169 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311586169 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54556 -- Edit this bug report at https://bugs.php.net/bug.php?id=54556&edit=1
Bug #44989 [Com]: 64bit Oracle RPMs still not supported by pdo-oci
Edit report at https://bugs.php.net/bug.php?id=44989&edit=1 ID: 44989 Comment by: jbnance at tresgeek dot net Reported by:stevec at engr dot oregonstate dot edu Summary:64bit Oracle RPMs still not supported by pdo-oci Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.2.6 Assigned To:sixd Block user comment: N Private report: N New Comment: What distribution has /usr/lib sym linked to /usr/lib64? The patch works fine on RHEL 5 32-bit (and 64-bit) with Oracle 10 and 11.2 RPMs (from Oracle). Previous Comments: [2011-09-14 05:32:16] patrickalla...@php.net The committed patch introduced a regression for those who have a path like: /usr/lib64/oracle/10.2.0.3/client/include on x86_64 boxes. The path tried are: /usr/include/oracle/10.2.0.3/client64/oci.h /usr/lib/oracle/10.2.0.3/client64/include/oci.h /usr/sdk/include/oci.h /usr/client64/include/oci.h Because /usr/lib/ is a symlink to /usr/lib64/ on those boxes, it previously worked by using "client" rather than "client64". Now it fails with: configure: error: I'm too dumb to figure out where the include dir is in your Instant Client install [2011-03-30 19:35:23] s...@php.net With Oracle Instant Client 11.2 RPMs use: ./configure --with-pdo-oci=instantclient,/usr,11.2 or ./configure --with-pdo-oci=shared,instantclient,/usr,11.2 i.e. only use two components of the version number. [2011-03-29 20:41:26] fel...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks for the patch! [2011-03-29 20:40:23] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=309818 Log: - Fixed bug #44989 (64bit Oracle RPMs still not supported by pdo-oci) patch by: jbnance at tresgeek dot net [2010-08-16 23:12:49] jbnance at tresgeek dot net Bug still exists in 5.3.3. Patch uploaded. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=44989 -- Edit this bug report at https://bugs.php.net/bug.php?id=44989&edit=1
Req #55493 [Asn->Wfx]: Superglobal variable variables with ${expression} in non-global scope
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1
ID: 55493
Updated by: dmi...@php.net
Reported by:vovan-ve at yandex dot ru
Summary:Superglobal variable variables with ${expression} in
non-global scope
-Status: Assigned
+Status: Wont fix
Type: Feature/Change Request
Package:Variables related
Operating System: Windows XP SP3
PHP Version:5.3.7
Assigned To:dmitry
Block user comment: N
Private report: N
Previous Comments:
[2011-08-26 23:09:57] johan...@php.net
Mind that even when when this special case is treated it still won't work with
get_defined_vars() and others. I think the current behavior can be documented
in the clearest way giving the least confusion ... so I would not implement it.
[2011-08-24 14:34:30] vovan-ve at yandex dot ru
Programmers, who use variable variable, dooms themself to slowdown performance
at any way due to calculation of the expressions. They won't see the
difference, I think.
[2011-08-24 14:00:39] vovan-ve at yandex dot ru
But what about SUPERglobal? In fact they are almost superglobal :)
[2011-08-24 13:54:34] larue...@php.net
+1 for dmitry
[2011-08-24 13:04:22] dmi...@php.net
ZE decides if a variable have to be fetched from the global scope at compile
time checking predefined list of super-global variables.
The variable fetching by name (e.g. $$name) is always done from local scope.
Of course it's possible to extend executor to check for list of super-global
variables at run-time, but it'll introduce significant slowdown for each fetch
by name. I really don't like it.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55493
--
Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1
Bug #55578 [Asn->Csd]: Segfault on implode/concat
Edit report at https://bugs.php.net/bug.php?id=55578&edit=1
ID: 55578
Updated by: dmi...@php.net
Reported by:kontakt at beberlei dot de
Summary:Segfault on implode/concat
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0alpha3
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-09-14 13:18:04] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=316744
Log: Fixed bug #55578 (Segfault on implode/concat)
[2011-09-04 23:24:22] tyr...@php.net
I've just bisected the changes, the bug was introduced with
http://svn.php.net/viewvc?view=revision&revision=298207
Tyrael
[2011-09-04 21:18:01] tyr...@php.net
an even shorter test case:
'(',
'post' => ')',
'separator' => ' AND ',
);
class Foo
{
public function __toString()
{
return 'Foo';
}
}
function test($options, $queryPart)
{
return (isset($options['pre']) ? $options['pre'] : '')
. (is_array($queryPart) ? implode($options['separator'],
$queryPart) : $queryPart)
. (isset($options['post']) ? $options['post'] : '');
}
#echo test($options, "test"); // comment this in and the line after works aswell
echo test($options, new Foo()); // this segfaults
Expected result:
(Foo)
Actual result:
--
Segfault, Backtrace is:
#0 gc_remove_zval_from_buffer (zv=0xb5f5b1b0) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_gc.c:265
#1 0x083723c8 in _zval_ptr_dtor (zval_ptr=0x8913da8) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_execute_API.c:437
#2 0x08374065 in zend_call_function (fci=0xbfffc8ac, fci_cache=0xbfffc8d0) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_execute_API.c:1018
#3 0x0839660b in zend_call_method (object_pp=0xbfffc9a0, obj_ce=, fn_proxy=0xb5f76d38, function_name=0x8866e95 "__tostring",
function_name_len=10,
retval_ptr_ptr=0xbfffc97c, param_count=0, arg1=0x0, arg2=0x0) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_interfaces.c:97
#4 0x083a0f11 in zend_std_cast_object_tostring (readobj=0xb5f5b1b0,
writeobj=0xbfffca48, type=6)
at /home/benny/downloads/php-5.4.0alpha3/Zend/zend_object_handlers.c:1472
#5 0x0838152b in zend_make_printable_zval (expr=0xb5f5b1b0,
expr_copy=0xbfffca48, use_copy=0xbfffca68) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend.c:260
#6 0x0837c678 in concat_function (result=0xb5f5b1c0, op1=0xb5f5b170,
op2=0xb5f5b1b0) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_operators.c:1243
#7 0x083d4d53 in ZEND_CONCAT_SPEC_TMP_TMP_HANDLER (execute_data=0xb5f5b0f8) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_vm_execute.h:8133
#8 0x083e52e6 in execute (op_array=0x8a5e7b0) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend_vm_execute.h:410
#9 0x08381d82 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/benny/downloads/php-5.4.0alpha3/Zend/zend.c:1262
#10 0x083247a2 in php_execute_script (primary_file=0xbfffeebc) at
/home/benny/downloads/php-5.4.0alpha3/main/main.c:2385
#11 0x0842005e in do_cli (argc=2, argv=0xb144) at
/home/benny/downloads/php-5.4.0alpha3/sapi/cli/php_cli.c:983
#12 0x084208d7 in main (argc=2, argv=0xb144) at
/home/benny/downloads/php-5.4.0alpha3/sapi/cli/php_cli.c:1356
--
Edit this bug report at https://bugs.php.net/bug.php?id=55578&edit=1
Bug #54054 [Com]: Autoload not called in user-defined error handler function in case of E_STRICT
Edit report at https://bugs.php.net/bug.php?id=54054&edit=1
ID: 54054
Comment by: web at darrengordon dot net
Reported by:morpika at vipmail dot hu
Summary:Autoload not called in user-defined error handler
function in case of E_STRICT
Status: Open
Type: Bug
Package:*Programming Data Structures
Operating System: FreeBSD 8.0
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
The use of opcoding caching can cause this issue to not be reproducable.
Test steps:
1. Enable opcode caching (APC), restart your httpd to ensure the opcode cache
is clean.
2. Request testa.php to trigger the E_STRICT.
Result:
---
*error_handler(): "Declaration of Bar::baz() should be compatible with that of
Foo::baz()"
Fatal error: Class 'Error' not found in //trigger_e_strict.php on line 3
3. Uncomment line #25: "include('doesntexist');" and re-request testa.php to
trigger the E_WARNING.
Result:
---
*error_handler(): "include(doesntexist): failed to open stream: No such file or
directory"
*__autoload(): "Error"
*Error::output()
*error_handler(): "include(): Failed opening 'doesntexist' for inclusion
(include_path='.:/:/usr/share/php')"
*Error::output()
*error_handler(): "Declaration of Bar::baz() should be compatible with that of
Foo::baz()"
*Error::output()
4. Recomment line #25: "include('doesntexist');" and re-request testa.php to
trigger the E_STRICT.
Result:
---
*error_handler(): "Declaration of Bar::baz() should be compatible with that of
Foo::baz()"
*_autoload(): "Error"
*Error::output()
Expected result:
Steps 2. and 4. should output the same result as the code is identical.
Actual result:
Steps 2. and 4. output different results.
Step 2. behaves according to the "Actual result" of bug #54054.
Step 4. behaves according to the Expected result" of bug #54054.
Notes:
This behaviour should be noted when reproducing bug #54054 as it will cause the
issue to not be reproducable.
Environment:
PHP 5.3.2
Apache/2.2.14
Ubuntu 10.04.3 LTS
Code:
testa.php
-
testb.php
-
Previous Comments:
[2011-09-14 11:43:03] phil at propcom dot co dot uk
This is still an issue.
The 2 test cases below should hopefully sum this up for you.
Case 1...
include() call fails and generates an E_WARNING
E_WARNING is caught by the error handler
Error handler attempts to use \Error class and calls the autoloader because it
is not currently loaded
...Case 2
The included file (http://codepad.viper-7.com/xyCn8C) generates an E_STRICT
E_STRICT is caught by the error handler
Error handler attempts to use \Error class and fails with a fatal error WITHOUT
calling the autoloader
The problem is that, in case 2, it is expected that the autoloader would be
used to load the \Error class. This doesn't appear to be the case.
Case 1: http://codepad.viper-7.com/b065B1
Case 2: http://codepad.viper-7.com/qi5185
Included file (xyCn8C) in Case 2: http://codepad.viper-7.com/xyCn8C
[2011-02-19 14:39:37] morpika at vipmail dot hu
Description:
__autoload function is not called in user-defined error handler function in
case of E_STRICT error. In case of any other type of errors (thet user-defined
error handler function can handle) the autoload function is called properly.
Test script:
---
test.php:
nf.php (to create an E_STRICT ERROR: Redefining already defined constructor):
Expected result:
autoload called
Actual result:
--
Fatal error: Class 't_class' not found
--
Edit this bug report at https://bugs.php.net/bug.php?id=54054&edit=1
Bug #39199 [Com]: Cannot load Lob data with more than 4000 bytes on ORACLE 10
Edit report at https://bugs.php.net/bug.php?id=39199&edit=1 ID: 39199 Comment by: php at codejungle dot org Reported by:jarismar_silva at adplabs dot com dot br Summary:Cannot load Lob data with more than 4000 bytes on ORACLE 10 Status: Closed Type: Bug Package:PDO related Operating System: * PHP Version:5.2.0 Assigned To:felipe Block user comment: N Private report: N New Comment: I have the same problem, but with pdo (odbc & ms sql). Previous Comments: [2010-12-10 02:19:05] fel...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks for the patch! [2010-12-10 01:33:50] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=306149 Log: - Fixed bug #39199 (Cannot load Lob data with more than 4000 bytes on ORACLE 10) patch by: spatar at mail dot nnov dot ru [2010-12-04 18:08:13] s...@php.net Still reproduces. Workaround is to use fread() [2009-05-03 01:00:01] 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". [2009-04-25 14:39:25] 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/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=39199 -- Edit this bug report at https://bugs.php.net/bug.php?id=39199&edit=1
Bug #42098 [Com]: E_STRICT doesn't trigger __autoload()
Edit report at https://bugs.php.net/bug.php?id=42098&edit=1 ID: 42098 Comment by: phil at propcom dot co dot uk Reported by:nicolas dot grekas+php at gmail dot com Summary:E_STRICT doesn't trigger __autoload() Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.2.3 Block user comment: N Private report: N New Comment: This is related to https://bugs.php.net/bug.php?id=54054&edit=2 which I have just commented on proving some, hopefully, sane example code. Previous Comments: [2010-05-25 11:12:20] i at walkinraven dot name I think autoload will not work in exception_handler or error_handler, that is the problem. [2007-08-17 23:08:16] tony2...@php.net >Ah ah ! You play with words :) No, he just said the same thing in other words. >The first time, you said : >- "Only execute time errors can be caught with user error handler.", >and now: >- "during compile -> autoload wont be triggered" There are two stages: 1) compile; 2) execute. Compile-time errors cannot be caught, only execute-time errors can be. >But that's still a bug for me in this case. My workaround does >exactily what PHP internals should do automagically, nothing more ! This is how the things work. [2007-08-17 22:54:31] nicolas dot grekas+php at gmail dot com Ah ah ! You play with words :) The first time, you said : - "Only execute time errors can be caught with user error handler.", and now: - "during compile -> autoload wont be triggered" You was wrong the first time ! And you may be right the second time. But that's still a bug for me in this case. My workaround does exactily what PHP internals should do automagically, nothing more ! Please consider it quietly, I'm not submitting this bug for fun. I do know the workaround now. It's for others developpers around the world who enjoy PHP a its best... [2007-08-17 22:40:32] j...@php.net And that proves I'm right. __autoload() won't happen during compile. And this error happens during compile -> autoload wont be triggered. [2007-08-17 22:37:41] nicolas dot grekas+php at gmail dot com yes, with an include : replace the eval with include 'toto.php', where toto.php contains this is how I hit the bug the first time The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=42098 -- Edit this bug report at https://bugs.php.net/bug.php?id=42098&edit=1
Bug #54054 [Com]: Autoload not called in user-defined error handler function in case of E_STRICT
Edit report at https://bugs.php.net/bug.php?id=54054&edit=1 ID: 54054 Comment by: phil at propcom dot co dot uk Reported by:morpika at vipmail dot hu Summary:Autoload not called in user-defined error handler function in case of E_STRICT Status: Open Type: Bug Package:*Programming Data Structures Operating System: FreeBSD 8.0 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: This is still an issue. The 2 test cases below should hopefully sum this up for you. Case 1... include() call fails and generates an E_WARNING E_WARNING is caught by the error handler Error handler attempts to use \Error class and calls the autoloader because it is not currently loaded ...Case 2 The included file (http://codepad.viper-7.com/xyCn8C) generates an E_STRICT E_STRICT is caught by the error handler Error handler attempts to use \Error class and fails with a fatal error WITHOUT calling the autoloader The problem is that, in case 2, it is expected that the autoloader would be used to load the \Error class. This doesn't appear to be the case. Case 1: http://codepad.viper-7.com/b065B1 Case 2: http://codepad.viper-7.com/qi5185 Included file (xyCn8C) in Case 2: http://codepad.viper-7.com/xyCn8C Previous Comments: [2011-02-19 14:39:37] morpika at vipmail dot hu Description: __autoload function is not called in user-defined error handler function in case of E_STRICT error. In case of any other type of errors (thet user-defined error handler function can handle) the autoload function is called properly. Test script: --- test.php: nf.php (to create an E_STRICT ERROR: Redefining already defined constructor): Expected result: autoload called Actual result: -- Fatal error: Class 't_class' not found -- Edit this bug report at https://bugs.php.net/bug.php?id=54054&edit=1
Bug #55690 [Com]: Wrong behavior of sessionHandler
Edit report at https://bugs.php.net/bug.php?id=55690&edit=1
ID: 55690
Comment by: ar...@php.net
Reported by:larue...@php.net
Summary:Wrong behavior of sessionHandler
Status: Assigned
Type: Bug
Package:Session related
PHP Version:trunk-SVN-2011-09-14 (SVN)
Assigned To:arpad
Block user comment: N
Private report: N
New Comment:
SessionHandler isn't intended to work in any other context than
session_set_save_handler($handler). I'd be nervous about making such a change
now anyway.
However that error message is misleading. I'll update it.
Previous Comments:
[2011-09-14 05:57:24] larue...@php.net
I think you can remove the PS_SANITY_CHECK, and use PS(mod) instead of
PS(default_mod), this should be okey.
thanks
[2011-09-14 05:52:02] larue...@php.net
arpad plz look at this. thanks
[2011-09-14 05:50:42] larue...@php.net
Description:
in mod_use_class.c
there is a macro:
#define PS_SANITY_CHECK \
if (PS(default_mod) == NULL) { \
php_error_docref(NULL TSRMLS_CC, E_CORE_ERROR, "Called default
SessionHandler but session.save_handler is user"); \
RETURN_FALSE; \
}
but I think this is wrong.
since, the default session.save_handler is "file", and if no new
session.save_handler provide, PS(default_mod) will alyways be NULL(since
default_mod only be assign in OnUpdateSaveHandler
Test script:
---
php -dsession.save_handler=files -r
'var_dump(ini_get("session.save_handler")); $x=new SessionHandler; $x->gc(1);'
Actual result:
--
PHP Fatal error: SessionHandler::gc(): Called default SessionHandler but
session.save_handler is user in Unknown on line 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=55690&edit=1
[PHP-BUG] Bug #55692 [NEW]: SoapClient Fault
From:
Operating system: gentoo
PHP version: 5.3.8
Package: SOAP related
Bug Type: Bug
Bug description:SoapClient Fault
Description:
As described in Bug #47021, we still found the error Daniel found
SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://test.xxx.it/pipe/CHI.asmx?wsdl' : Start tag expected, '<' not
found
We bypass the problem following the note on
http://www.tek-tips.com/viewthread.cfm?qid=1602496&page=17
Test script:
---
$sc = new SoapClient("http://test.xxx.it/pipe/CHI.asmx?wsdl";, array('trace'
=> 1,'connection_timeout' => 300));
Expected result:
the SoapClient Object
Actual result:
--
SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://test.xxx.it/pipe/CHI.asmx?wsdl' : Start tag expected, '<' not found
--
Edit bug report at https://bugs.php.net/bug.php?id=55692&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55692&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55692&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55692&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55692&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55692&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55692&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55692&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55692&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55692&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55692&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55692&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55692&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55692&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55692&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55692&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55692&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55692&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55692&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55692&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55692&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55692&r=mysqlcfg
[PHP-BUG] Bug #55691 [NEW]: different results from finfo_file and finfo_buffer
From: Operating system: WinXP HE SP2 PHP version: 5.3.8 Package: Unknown/Other Function Bug Type: Bug Bug description:different results from finfo_file and finfo_buffer Description: different results from finfo_file and finfo_buffer Scenario: 1. MS Excel-File stored in mySQL database LONGBLOB-Column 2. This binary data selected from database 3. This binary data stored to tempfile 4. mime-type sniffing done by finfo_buffer on binary data > result: application/octet-stream 5. mime-type sniffing done by finfo_file on tempfile > result: application/vnd.ms-excel PROBLEM: different result, dependent on used Fileinfo Function Comment: The tempfile has NO extension like ".xls" that could be used as hint for mimetype-sniffing Test script: --- https://bugs.php.net/bug.php?id=55691&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55691&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55691&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55691&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55691&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55691&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55691&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55691&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55691&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55691&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55691&r=support Expected behavior: https://bugs.php.net/fix.php?id=55691&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55691&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55691&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55691&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55691&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55691&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55691&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55691&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55691&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55691&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55691&r=mysqlcfg
Bug #54556 [Ver]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556&edit=1 ID: 54556 Updated by: larue...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: dmitry, plz look at this, thanks Previous Comments: [2011-07-26 11:12:22] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311678742 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311678742 [2011-07-25 12:10:52] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311595852 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311595852 [2011-07-25 05:40:56] larue...@php.net I have submit a patch for this. and I think this situation should trigger a notice to help developers aware of this. since this mostly might be bad codes.. [2011-07-25 05:29:29] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311586169 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311586169 [2011-04-27 09:56:51] kal dot el dot ias at gmx dot net title changed The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=54556 -- Edit this bug report at https://bugs.php.net/bug.php?id=54556&edit=1
