[PHP-BUG] Bug #61920 [NEW]: "Segmentation fault" when \xfe is a part of mb_eregi_replace pattern
From: wojak
Operating system: Linux Ubuntu 10.04.2 LTS
PHP version: 5.3.11
Package: mbstring related
Bug Type: Bug
Bug description:"Segmentation fault" when \xfe is a part of mb_eregi_replace
pattern
Description:
I get "Segmentation fault" when \xfe is a part of pattern argument in
mb_eregi_replace() method.
Test script:
---
php -r 'mb_regex_encoding ("UTF-8");mb_internal_encoding("UTF-8");echo
mb_eregi_replace ("[^\xfe]" , "?" , "\xfe ");'
--
Edit bug report at https://bugs.php.net/bug.php?id=61920&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61920&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61920&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61920&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61920&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61920&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61920&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61920&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61920&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61920&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61920&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61920&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61920&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61920&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61920&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61920&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61920&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61920&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61920&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61920&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61920&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61920&r=mysqlcfg
Bug #61875 [Com]: mbsring frequently crashing httpd.exe
Edit report at https://bugs.php.net/bug.php?id=61875&edit=1 ID: 61875 Comment by: robertassaf1 at gmail dot com Reported by:robertassaf1 at gmail dot com Summary:mbsring frequently crashing httpd.exe Status: Feedback Type: Bug Package:Apache2 related Operating System: Windows 2003 R2 SP2 32bits PHP Version:5.3.11 Block user comment: N Private report: N New Comment: I have increased the stack to 8MB but httpd.exe is still crashing on mbstring dll. Thanks in advance Previous Comments: [2012-04-29 12:38:14] robertassaf1 at gmail dot com Hello, I increased the ThreadStackSize to 2097152 (2M) in httpd-mpm.conf but the error still occurs. I tried also to increase the same parameter to 8M but Apache and PHP became unstable, athough the server is running on VMWare and has alot of memory (4 GB) it seems that the kernel for some reason is not fully using the memory allocated. Regards, Robert [2012-04-28 10:02:42] paj...@php.net Please try to increase the apache stack (httpd.conf or changing the binary default stack). [2012-04-28 09:55:44] robertassaf1 at gmail dot com Description: We are facing frequent httpd.exe crashes reported in Windows 2003 event manager. It happens at least 4 to 10 times a day at random. The cause of the issue is unknown. The event manager reports the following: "Faulting application httpd.exe, version 2.2.21.0, faulting module php_mbstring.dll, version 5.3.10.0, fault address 0x0002c94c." Test script: --- Unfortunately we don't have any script to reproduce the issue as we don't know what is causing it. Actual result: -- Type of Analysis Performed Crash Analysis Machine Name INTRASRV1 Operating System Windows Server 2003 Service Pack 2 Number Of Processors 4 Process ID 3236 Process Image C:\wamp\bin\apache\apache2.2.21\bin\httpd.exe System Up-Time 9 day(s) 16:05:13 Process Up-Time 1 day(s) 21:20:02 Thread 107 - System ID 4544 Entry point msvcr90!_threadstartex Create time 4/26/2012 9:44:34 AM Time spent in user mode 0 Days 0:0:51.890 Time spent in kernel mode 0 Days 0:0:21.843 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php_mbstring!node_new_str+c 375b82af 375b82b0 03a4e8e0 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 1463 + c php_mbstring!parse_exp+79a 03a4e940 375b8378 03a4e968 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 4835 + c php_mbstring!parse_branch+94 03a4e908 03a4e940 375b8378 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5181 + 1d php_mbstring!parse_subexp+b2 05eff5b0 03a4e908 03a4e940 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5223 + 12 php_mbstring!onig_parse_make_tree+c1 03a4e958 375b82a0 375b8378 375b82b0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5279 + 3e php_mbstring!onig_compile+87 20074780 375b82a0 375b8378 03a4ea2c c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regcomp.c @ 5169 php_mbstring!onig_new+4c 03a4ea1c 375b82a0 375b8378 000d c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regcomp.c @ 5399 + 14 php_mbstring!php_mbregex_compile_pattern+ba 000d 01794440 0001 16cb4568 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 458 + 25 php_mbstring!_php_mb_regex_ereg_replace_exec+239 0003 0001 00df756a 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 857 + 27 php_mbstring!zif_mb_eregi_replace+14 0003 375b7fa0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 980 + 14 php5ts!execute_internal+3a 12296958 0001 16cd77d8 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\zend\zend_execute.c @ 1273 + 2c php_xdebug_2_1_2_5_3_vc9!get_module+205c Exception Information PHP_MBSTRING!NODE_NEW_STR+CIn httpd__PID__3236__Date__04_28_2012__Time_07_04_35AM__700__First Chance Access Violation.dmp the assembly instruction at php_mbstring!node_new_str+c in c:\wamp\bin\php\php5.3.11\ext\php_mbstring.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0100 on thread 107 Module Information Image Name: c:\wamp\bin\php\php5.3
Bug #44383 [Com]: PHP DateTime not converted to xsd:datetime
Edit report at https://bugs.php.net/bug.php?id=44383&edit=1 ID: 44383 Comment by: andyidol at gmail dot com Reported by:kevin dot craft at gmail dot com Summary:PHP DateTime not converted to xsd:datetime Status: Open Type: Bug Package:SOAP related Operating System: * PHP Version:5.*, 6 (2009-08-07 Block user comment: N Private report: N New Comment: Please fix this! I beg you ) Previous Comments: [2012-01-25 19:44:20] frozenf...@php.net I've encountered this issue today, and it would be really wonderful to have this patch applied. [2010-10-18 17:43:04] aldekein at myevil dot info It still does not work after 2.5 years in PHP 5.3.1 on Windows. Maybe this patch should be applied to official PHP branch? [2009-08-07 15:23:57] david dot zuelke at bitextender dot com Updated patch and tests: http://pastie.org/575559 [2009-06-29 08:56:29] lsm...@php.net Reopening since we now have a patch. [2009-06-29 08:28:26] david dot zuelke at bitextender dot com We've created a patch to implement this. Description (with patch and tests for download): http://article.gmane.org/gmane.comp.php.devel/57369 Patch (in case gmane doesn't work): http://pastie.org/527755 Tests (in case gmane doesn't work): http://pastie.org/527762 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=44383 -- Edit this bug report at https://bugs.php.net/bug.php?id=44383&edit=1
[PHP-BUG] Req #61921 [NEW]: ldap_parse_result returns server controls
From: Operating system: Debian testing PHP version: 5.4Git-2012-05-03 (Git) Package: LDAP related Bug Type: Feature/Change Request Bug description:ldap_parse_result returns server controls Description: ldap_parse_result returns any server controls in an array that mimic ASN.1. ldap_set_option has been modified to accept such array for server and client controls. This is not a duplicate of bug #34492 as this patch handles any server controls and it's a more elegant solution for paged result than resolution of bug #42060. -- Edit bug report at https://bugs.php.net/bug.php?id=61921&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61921&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61921&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61921&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61921&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61921&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61921&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61921&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61921&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61921&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61921&r=support Expected behavior: https://bugs.php.net/fix.php?id=61921&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61921&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61921&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61921&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61921&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61921&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61921&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61921&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61921&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61921&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61921&r=mysqlcfg
Bug #61892 [Ana->Csd]: Zend/tests/gc_029.phpt fails with ZTS mode in PHP 5.4.1
Edit report at https://bugs.php.net/bug.php?id=61892&edit=1 ID: 61892 Updated by: larue...@php.net Reported by:s...@php.net Summary:Zend/tests/gc_029.phpt fails with ZTS mode in PHP 5.4.1 -Status: Analyzed +Status: Closed Type: Bug Package:Testing related Operating System: Linux PHP Version:5.4.1 -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-05-03 02:18:39] larue...@php.net @sixed I think it's okey to separate this test for ZTS and no-ZTS mode. as we talked via mail. thanks :) [2012-05-01 22:22:00] s...@php.net Description: With ZTS enabled, the gc_collect_cycles() call in Zend/tests/gc_029.phpt is returning 3 instead of the expected 2. >From http://qa.php.net/reports, this seems to have started in PHP 5.4.1. -- Edit this bug report at https://bugs.php.net/bug.php?id=61892&edit=1
Bug #45155 [Com]: Constructors not called when using classmap option in SoapClient
Edit report at https://bugs.php.net/bug.php?id=45155&edit=1 ID: 45155 Comment by: andyidol at gmail dot com Reported by:david at globulebleu dot com Summary:Constructors not called when using classmap option in SoapClient Status: Open Type: Bug Package:SOAP related Operating System: * PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Same here with 5.3.10. Maybe such classes should implement some specific interface (to avoid situation when class constructor has some required arguments) and to add some extra functionality, e.g: Previous Comments: [2011-05-04 18:22:02] kissifrot at gmail dot com Same problems happens with PHP 5.3.6 (dotdeb version) on Lenny. This is quite annoying as we cannot later call the created object's methods due to some logic done in the constructor (such as sanitizing for instance) which is missing. [2010-05-04 18:10:39] philipp dot kempgen at amooma dot de Same thing applies to SoapServer as well. [2010-05-04 18:03:36] philipp dot kempgen at amooma dot de Bug still found in PHP 5.3.2. [2009-10-29 14:20:32] grzegorz dot drozd at esky dot pl __wakeup is not called before deserialization from session (if you store object in session of course). Only __set is called when setting properties. [2009-07-28 13:53:51] b...@php.net changed status because this bug still exists and is reproduced 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=45155 -- Edit this bug report at https://bugs.php.net/bug.php?id=45155&edit=1
Req #55181 [Com]: Enhance security by limiting the script extension
Edit report at https://bugs.php.net/bug.php?id=55181&edit=1
ID: 55181
Comment by: cbarry at artspan dot com
Reported by:f...@php.net
Summary:Enhance security by limiting the script extension
Status: Closed
Type: Feature/Change Request
Package:FPM related
Operating System: any
PHP Version:5.3.6
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
The default for this new setting should not be '.php'. There are many reasons
that people may choose different file extensions (or no extension at all), and
this new feature will break all those pages. ('Access Denied.' message)
I've found that a way to change this setting is to use:
security.limit_extensions = FALSE
Which should be the default, or at least documented in the configuration files
Using PHP 5.3.10-1ubuntu3 (latest available version for ubuntu precise)
Previous Comments:
[2012-01-16 10:32:37] gwenmael dot rouxel at neovote dot com
As said by the previous commenter...
My servers are installed by an automated script, which gets PHP-FPM from the
debian packages.
So the version was silently upgraded, and I was scratching my head for the
whole weekend trying to figure out this. Only this morning did I stumble upon
the changelog and was able to make configuration changes.
A warning in the PHP FPM log would really be useful indeed.
[2012-01-14 12:16:44] public at grik dot net
it would be MUCH better if you do the same way it's done with date.timezone: if
the setting is not defined, it gives a warning on PHP start
now everyone blindly upgrading to a minor release with the same php-fpm.conf
are
shooting their feet
[2012-01-13 08:57:15] laph at gmx dot net
This is a massive functionality change, breaking every application that doesn't
stick to the ".php" File-Extension when upgrading from 5.3.8 to 5.3.9 since if
"security.limit_extensions" is unset, it's limited to ".php".
Additionally this new configuration setting is not documented in the FPM-Docs.
Please, don't do such changes in minor releases. Or at lease document them
properly!
[2011-10-08 19:52:26] 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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-10-08 13:42:08] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=317894
Log: - Backported FR #55181 from 5.4 branch (Enhance security by limiting
access to user defined extensions)
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=55181
--
Edit this bug report at https://bugs.php.net/bug.php?id=55181&edit=1
[PHP-BUG] Bug #61922 [NEW]: PHP 5.4 ZTS build doesn't accept zend.script_encoding configure
From: laruence Operating system: PHP version: 5.4.1 Package: Scripting Engine problem Bug Type: Bug Bug description:PHP 5.4 ZTS build doesn't accept zend.script_encoding configure Description: in zts mode, following test faild: test for mbstring script_encoding for flex unsafe encoding (Shift_JIS) [Zend/tests/multibyte/multibyte_encoding_004.phpt] encoding conversion from script encoding into internal encoding [Zend/tests/multibyte/multibyte_encoding_005.phpt] after I digging, I found the reason: mbstring ext first set the CG(encoding_list) by calling zend_multibyte_set_functions, but after then zend_post_startup be called, then compiler_globals_ctor be called. then the encoding_list setting lost. so~ -- Edit bug report at https://bugs.php.net/bug.php?id=61922&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61922&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61922&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61922&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61922&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61922&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61922&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61922&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61922&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61922&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61922&r=support Expected behavior: https://bugs.php.net/fix.php?id=61922&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61922&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61922&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61922&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61922&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61922&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61922&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61922&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61922&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61922&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61922&r=mysqlcfg
[PHP-BUG] Bug #61924 [NEW]: cannot use self in interface function declaration
From:
Operating system:
PHP version: 5.4.1
Package: Class/Object related
Bug Type: Bug
Bug description:cannot use self in interface function declaration
Description:
I am reviewing existing code on a PHP5.4.1 testbed. I've discovered that
interface declarations using 'self' as a type hint no longer allow
implementations to use 'self' but require them to use the interface name.
It is no longer possible for an interface to declare a method that requires
the implementor's class as a typehint without declaring that class
specifically. And that would limit the usefulness of that interface to one
class only.
Test script:
---
interface IComparable {
public function equals(self $other);
}
class A implements IComparable{
protected $var;
public function __construct(self $v){
$this->var=$v;
}
public function equals($other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
$a1= new A(7);
$a2= new A(5);
$a3= new A(5);
echo $a1->equals($a2),"\n";
echo $a2->equals($a3),"\n";
Expected result:
different
equal
Actual result:
--
PHP Fatal error: Declaration of A::equals() must be compatible with
IComparable::equals(IComparable $other)
--
Edit bug report at https://bugs.php.net/bug.php?id=61924&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61924&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61924&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61924&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61924&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61924&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61924&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61924&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61924&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61924&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61924&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61924&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61924&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61924&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61924&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61924&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61924&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61924&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61924&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61924&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61924&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61924&r=mysqlcfg
Bug #61166 [Com]: PHP crashing (Drupal site)
Edit report at https://bugs.php.net/bug.php?id=61166&edit=1 ID: 61166 Comment by: mmoreno at pobox dot com Reported by:guaycuru at gmail dot com Summary:PHP crashing (Drupal site) Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows 7 x64 PHP Version:5.3SVN-2012-02-22 (snap) Block user comment: N Private report: N New Comment: Looks like this issue has been fixed in 5.3.11. Previous Comments: [2012-03-08 18:52:39] mmoreno at pobox dot com I've confirmed this problem has NOT been fixed using this snapshot (2012-03-08): http://windows.php.net/downloads/snaps/php-5.3/r324022/php-5.3-ts-windows-vc9-x86- r324022.zip [2012-03-07 10:36:35] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2012-02-23 17:55:28] guaycuru at gmail dot com Yep, that's exactly it! The file was 20480 bytes. Added one blank space and the crash was gone! It's definetely not fixed! =\ Thanks a lot for clearing this up! [2012-02-23 17:37:03] mmoreno at pobox dot com This was crashing Drupal 7 for me too. I bet you're encountering the 4096 byte bug referenced in bugs 60758 and 60998. The responses have been that it's either fixed in SVN or not a bug so I'm confused about the status since recent snapshots are still affected. Seems to only affect Windows. WORKAROUND: Find all Drupal files that are exactly 4096 bytes or a multiple (e.g. 8192, 12288) and edit them slightly by adding a blank line or a comment in order to change the file size. Hope this helps. [2012-02-22 19:12:33] guaycuru at gmail dot com I tried Apache 2.2.21 and 2.4.1, both downloaded from Apache Lounge. Anyway the crash happens using PHP CLI, so it's not apache related. I'm using Drupal 7 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=61166 -- Edit this bug report at https://bugs.php.net/bug.php?id=61166&edit=1
Bug #45191 [Com]: error_log ignores date.timezone php.ini val when setting logging timestamps
Edit report at https://bugs.php.net/bug.php?id=45191&edit=1
ID: 45191
Comment by: php at sboxx dot org
Reported by:info at organicdata dot co dot za
Summary:error_log ignores date.timezone php.ini val when
setting logging timestamps
Status: Closed
Type: Bug
Package:Date/time related
Operating System: Centos el5
PHP Version:5.2CVS-2008-06-05 (snap)
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Red Hat Entrprise Linux 6.2
PHP 5.4.1
date.timezone = Europe/Berlin
log_errors = On
error_log = /var/log/php_errors.log
All messages in /var/log/php_errors.log have UTC timestamps.
System time is set and correctly displayed as CET/CEST.
Previous Comments:
[2012-02-12 09:56:41] wadkar at gmail dot com
@christopher
Interesting observation. My report is with 5.3.8 version, which outputs the log
with UTC timestamp (the timezone is part of it). I am getting a feeling that
this might not be a direct issue with php-src but somewhere in between system
calls made by php-src for logging and the OS itself which passes on TZ data for
this call.
[2012-02-11 18:15:29] christopher at specialtyproduce dot com
It seems this bug may have reappeared between 5.3.8 and 5.3.9?
I have two MS 2008 R2 VMs, built from the same starting images. Both running
IIS 7.5, system timezone is set for "Pacific Standard Time" and the TZ
environment variable is not set.
Machine A : PHP 5.3.8 (cli) (built: Aug 23 2011 12:14:39)
(Originally configured with PHP 5.2.17 and subsequently upgraded to 5.3.8)
Machine B : PHP 5.3.9 (cli) (built: Jan 10 2012 16:33:06)
Their php.ini files are virtually identical, with:
log_errors = On
date.timezone=America/Los_Angeles
error_log="C:\PHP\logs\php53_errors.log"
I ran a version of the "mycode.php" from the original bug report on both
machines.
mycode.php
--
FIRSTBADCONSTANT;
date_default_timezone_set("UTC");
SOMEBADCONSTANT;
date_default_timezone_set("America/Los_Angeles");
ANOTHERBADCONSTANT;
Machine A php53_errors.log
--
[11-Feb-2012 09:39:18] PHP Notice: Use of undefined constant FIRSTBADCONSTANT
- assumed 'FIRSTBADCONSTANT' in C:\Temp\mycode.php on line 2
[11-Feb-2012 17:39:18] PHP Notice: Use of undefined constant SOMEBADCONSTANT -
assumed 'SOMEBADCONSTANT' in C:\Temp\mycode.php on line 4
[11-Feb-2012 09:39:18] PHP Notice: Use of undefined constant
ANOTHERBADCONSTANT - assumed 'ANOTHERBADCONSTANT' in C:\Temp\mycode.php on line
6
Machine B php53_errors.log
--
[11-Feb-2012 18:06:52 UTC] PHP Notice: Use of undefined constant
FIRSTBADCONSTANT - assumed 'FIRSTBADCONSTANT' in C:\Temp\mycode.php on line 2
[11-Feb-2012 18:06:52 UTC] PHP Notice: Use of undefined constant
SOMEBADCONSTANT - assumed 'SOMEBADCONSTANT' in C:\Temp\mycode.php on line 4
[11-Feb-2012 18:06:52 UTC] PHP Notice: Use of undefined constant
ANOTHERBADCONSTANT - assumed 'ANOTHERBADCONSTANT' in C:\Temp\mycode.php on line
6
The 5.3.9 error reporting seems locked in UTC.
[2012-02-09 23:21:35] daniel dot caillibaud at sesamath dot net
In an openvz VM, with php-fpm 5.3.10 (debian squeeze OS), with a sytem date
configured on UTC+1 (on physical host, but `date` in VM also show UTC+1), in
php.ini I've a
date.timezone = "Europe/Paris"
but php error_log date is displayed as UTC
[09-Feb-2012 23:15:08 UTC] PHP Notice: ...
while all others logs are in the system timezone, e.g nginx
[10/Feb/2012:00:16:46 +0100] ...
and syslog as well is UTC+1 (but doesn't show it on each log line).
Hope it helps...
[2012-01-30 09:20:08] wadkar at gmail dot com
This bug may still be a problem for someone, here are the details :
# php -v
PHP 5.3.8 (cli) (built: Dec 1 2011 12:23:50)
The problem is with the OS this time= CentOS 5+OpenVZ with IUS repo. The host
machine (with the OpenVZ kernel) has no problems
# uname -a
Linux vz-node2 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD
2011 x86_64 x86_64 x86_64 GNU/Linux
# echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r
'error_reporting(-1); SOMEBADCONSTANT;' && cat /tmp/error.log && date
[30-Jan-2012 14:38:56] PHP Notice: Use of undefined constant SOMEBADCONSTANT -
assumed 'SOMEBADCONSTANT' in Command line code on line 1
Mon Jan 30 14:38:56 IST 2012
The same code snippet, however, when run on a VM gives
# uname -a
Linux container1 2.6.18-274.el5.028stab093.2xen #1 SMP Tue Aug 23 16:50:42 MSD
2011 x86_64 x86_64 x86_64 GNU/Linux
# echo '' > /tmp/error.log && php -dlog_errors=On -derror_log=/tmp/error.log -r
'error_reporting(-1); SOMEBADCONS
Bug #61922 [Opn->Csd]: ZTS build doesn't accept zend.script_encoding config
Edit report at https://bugs.php.net/bug.php?id=61922&edit=1 ID: 61922 Updated by: larue...@php.net Reported by:larue...@php.net Summary:ZTS build doesn't accept zend.script_encoding config -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.4.1 -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-05-03 14:40:50] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=72f19e9a8bcf5712b24fa333a26616eff19ac1ce Log: Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config) [2012-05-03 14:40:02] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=72f19e9a8bcf5712b24fa333a26616eff19ac1ce Log: Fixed bug #61922 (ZTS build doesn't accept zend.script_encoding config) [2012-05-03 13:20:41] larue...@php.net Description: in zts mode, following test faild: test for mbstring script_encoding for flex unsafe encoding (Shift_JIS) [Zend/tests/multibyte/multibyte_encoding_004.phpt] encoding conversion from script encoding into internal encoding [Zend/tests/multibyte/multibyte_encoding_005.phpt] after I digging, I found the reason: mbstring ext first set the CG(encoding_list) by calling zend_multibyte_set_functions, but after then zend_post_startup be called, then compiler_globals_ctor be called. then the encoding_list setting lost. so~ -- Edit this bug report at https://bugs.php.net/bug.php?id=61922&edit=1
Bug #61924 [Opn]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Updated by: larue...@php.net
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
Status: Open
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
it's always not allowed since php 5.2, why are you thinking it worked once?
Previous Comments:
[2012-05-03 14:20:54] jenwelsh at yahoo dot com
Description:
I am reviewing existing code on a PHP5.4.1 testbed. I've discovered that
interface declarations using 'self' as a type hint no longer allow
implementations to use 'self' but require them to use the interface name.
It is no longer possible for an interface to declare a method that requires the
implementor's class as a typehint without declaring that class specifically.
And that would limit the usefulness of that interface to one class only.
Test script:
---
interface IComparable {
public function equals(self $other);
}
class A implements IComparable{
protected $var;
public function __construct(self $v){
$this->var=$v;
}
public function equals($other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
$a1= new A(7);
$a2= new A(5);
$a3= new A(5);
echo $a1->equals($a2),"\n";
echo $a2->equals($a3),"\n";
Expected result:
different
equal
Actual result:
--
PHP Fatal error: Declaration of A::equals() must be compatible with
IComparable::equals(IComparable $other)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
Bug #61920 [Com]: "Segmentation fault" when \xfe is a part of mb_eregi_replace pattern
Edit report at https://bugs.php.net/bug.php?id=61920&edit=1
ID: 61920
Comment by: larue...@php.net
Reported by:wo...@php.net
Summary:"Segmentation fault" when \xfe is a part of
mb_eregi_replace pattern
Status: Open
Type: Bug
Package:mbstring related
Operating System: Linux Ubuntu 10.04.2 LTS
PHP Version:5.3.11
Block user comment: N
Private report: N
New Comment:
only for php5.3, 5.4 works fine. bt is:
Core was generated by `php53 -r mb_regex_encoding ("UTF-
8");mb_internal_encoding("UTF-8");echo mb_ereg'.
Program terminated with signal 11, Segmentation fault.
#0 0x005f3273 in next_state_val (cc=0x2406d48, vs=0x7fff1e996960, v=0,
vs_israw=0x7fff1e9969b8, v_israw=0, intype=CCV_SB,
type=0x7fff1e9969b4, state=0x7fff1e9969b0, env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:3973
3973 BITSET_SET_BIT(cc->bs, (int )(*vs));
(gdb) bt
#0 0x005f3273 in next_state_val (cc=0x2406d48, vs=0x7fff1e996960, v=0,
vs_israw=0x7fff1e9969b8, v_israw=0, intype=CCV_SB,
type=0x7fff1e9969b4, state=0x7fff1e9969b0, env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:3973
#1 0x005f3f26 in parse_char_class (np=0x7fff1e996b48,
tok=0x7fff1e996bf0, src=0x7fff1e996c70, end=0x2516b24 "", env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:4342
#2 0x005f58ff in parse_exp (np=0x7fff1e996b48, tok=0x7fff1e996bf0,
term=0, src=0x7fff1e996c70, end=0x2516b24 "",
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5019
#3 0x005f609f in parse_branch (top=0x7fff1e996ba8, tok=0x7fff1e996bf0,
term=0, src=0x7fff1e996c70, end=0x2516b24 "",
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5171
#4 0x005f620a in parse_subexp (top=0x7fff1e996d98, tok=0x7fff1e996bf0,
term=0, src=0x7fff1e996c70, end=0x2516b24 "",
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5208
#5 0x005f6391 in parse_regexp (top=0x7fff1e996d98, src=0x7fff1e996c70,
end=0x2516b24 "", env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5252
#6 0x005f6464 in onig_parse_make_tree (root=0x7fff1e996d98,
pattern=0x2516b20 "[^\376]", end=0x2516b24 "", reg=0x24f9450,
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5279
#7 0x005de803 in onig_compile (reg=0x24f9450, pattern=0x2516b20 "
[^\376]", pattern_end=0x2516b24 "", einfo=0x7fff1e996e60)
at /home/huixinchen/opensource/php-5.3/ext/mbstring/oniguruma/regcomp.c:5168
#8 0x005deed5 in onig_new (reg=0x7fff1e996e78, pattern=0x2516b20 "
[^\376]", pattern_end=0x2516b24 "", option=13, enc=0x112a280,
syntax=0x1129dc0, einfo=0x7fff1e996e60) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regcomp.c:5399
#9 0x006280e0 in php_mbregex_compile_pattern (pattern=0x2516b20 "
[^\376]", patlen=4, options=13, enc=0x112a280, syntax=0x1129dc0)
at /home/huixinchen/opensource/php-5.3/ext/mbstring/php_mbregex.c:458
#10 0x006291f1 in _php_mb_regex_ereg_replace_exec (ht=3,
return_value=0x2518c28, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1, options=13) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/php_mbregex.c:857
#11 0x0062a384 in zif_mb_eregi_replace (ht=3, return_value=0x2518c28,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /home/huixinchen/opensource/php-5.3/ext/mbstring/php_mbregex.c:980
#12 0x008b1a97 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fe8cadd2090)
at /home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:320
#13 0x008b5fa0 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fe8cadd2090)
at /home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:1640
#14 0x008b0f70 in execute (op_array=0x2518970) at
/home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:107
#15 0x0086e5f1 in zend_eval_stringl (
Previous Comments:
[2012-05-03 08:33:12] wo...@php.net
Description:
I get "Segmentation fault" when \xfe is a part of pattern argument in
mb_eregi_replace() method.
Test script:
---
php -r 'mb_regex_encoding ("UTF-8");mb_internal_encoding("UTF-8");echo
mb_eregi_replace ("[^\xfe]" , "?" , "\xfe ");'
--
Edit this bug report at https://bugs.php.net/bug.php?id=61920&edit=1
Bug #61924 [Opn->Fbk]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Updated by: larue...@php.net
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
-Status: Open
+Status: Feedback
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
or you can change it to a feature request :)
Previous Comments:
[2012-05-03 14:45:32] larue...@php.net
it's always not allowed since php 5.2, why are you thinking it worked once?
[2012-05-03 14:20:54] jenwelsh at yahoo dot com
Description:
I am reviewing existing code on a PHP5.4.1 testbed. I've discovered that
interface declarations using 'self' as a type hint no longer allow
implementations to use 'self' but require them to use the interface name.
It is no longer possible for an interface to declare a method that requires the
implementor's class as a typehint without declaring that class specifically.
And that would limit the usefulness of that interface to one class only.
Test script:
---
interface IComparable {
public function equals(self $other);
}
class A implements IComparable{
protected $var;
public function __construct(self $v){
$this->var=$v;
}
public function equals($other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
$a1= new A(7);
$a2= new A(5);
$a3= new A(5);
echo $a1->equals($a2),"\n";
echo $a2->equals($a3),"\n";
Expected result:
different
equal
Actual result:
--
PHP Fatal error: Declaration of A::equals() must be compatible with
IComparable::equals(IComparable $other)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
Bug #61924 [Com]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Comment by: jenwelsh at yahoo dot com
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
Status: Feedback
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
The reason I "think" it did work, is because it is **currently** working on a
production site with PHP 5.3.11. And it **has** been working for over 2 years.
Previous Comments:
[2012-05-03 14:52:08] larue...@php.net
or you can change it to a feature request :)
[2012-05-03 14:45:32] larue...@php.net
it's always not allowed since php 5.2, why are you thinking it worked once?
[2012-05-03 14:20:54] jenwelsh at yahoo dot com
Description:
I am reviewing existing code on a PHP5.4.1 testbed. I've discovered that
interface declarations using 'self' as a type hint no longer allow
implementations to use 'self' but require them to use the interface name.
It is no longer possible for an interface to declare a method that requires the
implementor's class as a typehint without declaring that class specifically.
And that would limit the usefulness of that interface to one class only.
Test script:
---
interface IComparable {
public function equals(self $other);
}
class A implements IComparable{
protected $var;
public function __construct(self $v){
$this->var=$v;
}
public function equals($other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
$a1= new A(7);
$a2= new A(5);
$a3= new A(5);
echo $a1->equals($a2),"\n";
echo $a2->equals($a3),"\n";
Expected result:
different
equal
Actual result:
--
PHP Fatal error: Declaration of A::equals() must be compatible with
IComparable::equals(IComparable $other)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
[PHP-BUG] Bug #61925 [NEW]: Crashes on using variable equal to conditional shortcut
From:
Operating system: Windows 7 32-bit
PHP version: 5.4.1
Package: *Programming Data Structures
Bug Type: Bug
Bug description:Crashes on using variable equal to conditional shortcut
Description:
I am using Apache 2.4 with PHP 5.4 on Windows 7 32bit. When executing the
code shown, from within a private class method, the server crashes. PHP is
compiled as a DSO. If the code is changed to utilize long form conditional
processing the execution works.
If I use the command line to execute the script, the class loaded by
require does not get called.
// my index.php
require("C:/Infinity/application/shared/classes/a.php");
$x = new a();
// my a.php
class a { __constructor(){ $this->import_variables($_POST); }}
further code in test script.
Test script:
---
# retrieve caller name
$calledby = debug_backtrace(); print_r($calledby);
// does not work
$caller = (strlen($calledby[1]['class'])) ? $calledby[1]['class'] :
$calledby[0]['class'];
// works and does does not segfault
if (strlen($calledby[1]['class'])) $caller = $calledby[1]['class'];
else$caller = $calledby[0]['class'];
# arguments are required
if (!func_num_args()) { return; }
# fill variables with argument contents if exists
$variables = (func_num_args() == 0) ? NULL : (is_array(func_get_arg(0)) ?
func_get_arg(0) : NULL);
Expected result:
I expect that Apache will not SEGFAULT
--
Edit bug report at https://bugs.php.net/bug.php?id=61925&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61925&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61925&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61925&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61925&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61925&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61925&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61925&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61925&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61925&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61925&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61925&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61925&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61925&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61925&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61925&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61925&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61925&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61925&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61925&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61925&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61925&r=mysqlcfg
Bug #61924 [Fbk]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Updated by: larue...@php.net
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
Status: Feedback
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Oh, sorry I misunderstanded , assign to my self , should have Sth to do with a
fix
made by me
Previous Comments:
[2012-05-03 15:22:17] jenwelsh at yahoo dot com
The reason I "think" it did work, is because it is **currently** working on a
production site with PHP 5.3.11. And it **has** been working for over 2 years.
[2012-05-03 14:52:08] larue...@php.net
or you can change it to a feature request :)
[2012-05-03 14:45:32] larue...@php.net
it's always not allowed since php 5.2, why are you thinking it worked once?
[2012-05-03 14:20:54] jenwelsh at yahoo dot com
Description:
I am reviewing existing code on a PHP5.4.1 testbed. I've discovered that
interface declarations using 'self' as a type hint no longer allow
implementations to use 'self' but require them to use the interface name.
It is no longer possible for an interface to declare a method that requires the
implementor's class as a typehint without declaring that class specifically.
And that would limit the usefulness of that interface to one class only.
Test script:
---
interface IComparable {
public function equals(self $other);
}
class A implements IComparable{
protected $var;
public function __construct(self $v){
$this->var=$v;
}
public function equals($other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
$a1= new A(7);
$a2= new A(5);
$a3= new A(5);
echo $a1->equals($a2),"\n";
echo $a2->equals($a3),"\n";
Expected result:
different
equal
Actual result:
--
PHP Fatal error: Declaration of A::equals() must be compatible with
IComparable::equals(IComparable $other)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
Bug #61886 [Opn]: cURL returns error 209
Edit report at https://bugs.php.net/bug.php?id=61886&edit=1
ID: 61886
User updated by:develop1983 at gmail dot com
Reported by:develop1983 at gmail dot com
Summary:cURL returns error 209
Status: Open
Type: Bug
Package:cURL related
Operating System: win7 x86
PHP Version:5.3.11
Block user comment: N
Private report: N
New Comment:
> I can not reproduce it with php5.3-trunk and libcurl/7.21.6
It should work with libcurl/7.21.6 (I think), because it works with v7.21.7 (as
I mentioned).
It doesn't work with cURL v7.24.0 (in PHP 5.3.11)
> and I think it should not a issue of libcurl's version.
Hmmm... It notices cURL warnings...
And I don't think it is an issue of PHP.
> did you use APC or Eacc? thanks
I don't know. I downloaded the MSI file of PHP 5.3.11 and install the software
(as I did with PHP 5.3.9 ago).
I don't use any additional softwares. Just PHP "as is" as it installed with MSI
file.
Thanks.
Previous Comments:
[2012-05-03 06:09:27] larue...@php.net
I can not reproduce it with php5.3-trunk and libcurl/7.21.6
and I think it should not a issue of libcurl's version.
did you use APC or Eacc? thanks
[2012-05-01 10:50:07] develop1983 at gmail dot com
Test script:
-
'http://www.php.net/releases.atom',
'url2' => 'http://www.php.net/feed.atom'
);
$user_agent_string = getenv('HTTP_USER_AGENT');
foreach ($links as $key => $url) {
$cookies = '';
$cookiejar = dirname(__FILE__) . '/' . $key;
$headers = '';
$ch = curl_init($url);
if (substr($url, 0, 8) == 'https://') {
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
}
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 5000);
if (!file_exists($cookiejar)) {
if (!empty($cookies)) {
curl_setopt($ch, CURLOPT_COOKIE, $cookies);
}
} else {
curl_setopt($ch, CURLOPT_COOKIEFILE, $cookiejar);
}
curl_setopt($ch, CURLOPT_COOKIEJAR, $cookiejar);
if (!empty($headers)) {
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
}
curl_setopt($ch, CURLOPT_ENCODING, 'gzip');
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000);
curl_setopt($ch, CURLOPT_USERAGENT, $user_agent_string);
curl_multi_add_handle($mh, $ch);
$ch_array[$key] = $ch;
}
do {
$execReturnValue = curl_multi_exec($mh, $runningHandles);
} while ($execReturnValue == CURLM_CALL_MULTI_PERFORM);
while ($runningHandles && $execReturnValue == CURLM_OK) {
if (curl_multi_select($mh) != -1) {
do {
$execReturnValue = curl_multi_exec($mh, $runningHandles);
$info = curl_multi_info_read($mh);
if ($info['msg'] == CURLMSG_DONE) {
$ch = $info['handle'];
if ($info['result'] == CURLM_OK) {
// process data
echo 'process data' . PHP_EOL;
} else {
// error
echo 'error' . PHP_EOL;
}
curl_multi_remove_handle($mh, $ch);
curl_close($ch);
}
} while ($execReturnValue == CURLM_CALL_MULTI_PERFORM);
}
}
curl_multi_close($mh);
?>
[2012-05-01 09:26:48] paj...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2012-05-01 09:23:06] develop1983 at gmail dot com
PHP 5.3.9 cURL version - 7.21.7
PHP 5.3.11 cURL version - 7.24.0
[2012-05-01 07:36:52] develop1983 at gmail dot com
Description:
I get these warnings:
Warning: (null)(): 209 is not a valid cURL handle resource in Unknown on line 0
Warning: (null)(): 211 is not a valid cURL handle resource in Unknown on line 0
After it the script stoped by "max_execution_time" (=300).
Test script:
---
// Simple script to do multiple queries
// It works in PHP 5.3.9
// It doesn't work in PHP 5.3.11, 5.4.0
// I didn't tested in 5.4.1, but I think it still exists there (because it
exists in PHP 5.3.11)
// Requested URL is valid and I can get the content using the browser and with
PHP 5.3.9 (i mean the cURL in PHP 5.3.9 package)
$mh = curl_multi_init();
$ch_array = array ();
// $links - Zend_Db_Table_Rowset
// $link - Zend_Db_Table_Row
foreac
[PHP-BUG] Req #61926 [NEW]: strpos that finds multiple positions
From:
Operating system: any
PHP version: 5.4.1
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:strpos that finds multiple positions
Description:
I think we need a better strpos that can find multiple positions (an array)
quickly.
to avoid the use of functions like :
$str = "&foobar&foobaz";
$toFind = "foo";
$start = 0;
while( ($pos = strpos(($str),$toFind,$start) !== false)) {
echo 'Found '.$toFind.' at position '.$pos."\n";
$start = $pos+1; // start searching from next position.
}
//Output:
// Found foo at position 1
// Found foo at position 8
Expected result:
an array of all positions
Actual result:
--
a simple position
--
Edit bug report at https://bugs.php.net/bug.php?id=61926&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61926&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61926&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61926&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61926&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61926&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61926&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61926&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61926&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61926&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61926&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61926&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61926&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61926&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61926&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61926&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61926&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61926&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61926&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61926&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61926&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61926&r=mysqlcfg
[PHP-BUG] Bug #61927 [NEW]: ext/standard/tests/general_functions/debug_zval_dump_o.phpt diffs in ZTS mode
From: sixd
Operating system:
PHP version: 5.4.1
Package: Testing related
Bug Type: Bug
Bug description:ext/standard/tests/general_functions/debug_zval_dump_o.phpt
diffs in ZTS mode
Description:
Similar to https://bugs.php.net/bug.php?id=61892 the test
ext/standard/tests/general_functions/debug_zval_dump_o.phpt diffs in ZTS
mode.
This probably needs the test to be forked, but the code should be reviewed
first.
Expected result:
No diff
Actual result:
--
007+ long(10) refcount(1)
007- long(10) refcount(5)
009+ long(20) refcount(1)
009- long(20) refcount(5)
011+ long(30) refcount(1)
011- long(30) refcount(7)
013+ array(2) refcount(1){
013- array(2) refcount(5){
015+ long(1) refcount(5)
015- long(1) refcount(1)
017+ long(3) refcount(5)
017- long(3) refcount(1)
024+ long(10) refcount(1)
024- long(10) refcount(5)
026+ long(20) refcount(1)
026- long(20) refcount(5)
028+ long(30) refcount(1)
028- long(30) refcount(7)
030+ array(2) refcount(1){
030- array(2) refcount(5){
032+ long(1) refcount(5)
032- long(1) refcount(1)
034+ long(3) refcount(5)
034- long(3) refcount(1)
046+ long(30) refcount(1)
046- long(30) refcount(2)
048+ long(40) refcount(1)
048- long(40) refcount(2)
050+ long(50) refcount(1)
050- long(50) refcount(2)
056+ long(10) refcount(1)
056- long(10) refcount(5)
058+ long(20) refcount(1)
058- long(20) refcount(5)
060+ long(30) refcount(3)
060- long(30) refcount(7)
062+ array(2) refcount(1){
062- array(2) refcount(5){
064+ long(1) refcount(5)
064- long(1) refcount(1)
066+ long(3) refcount(5)
066- long(3) refcount(1)
073+ long(10) refcount(1)
073- long(10) refcount(5)
075+ long(20) refcount(1)
075- long(20) refcount(5)
077+ long(30) refcount(3)
077- long(30) refcount(7)
079+ array(2) refcount(1){
079- array(2) refcount(5){
081+ long(1) refcount(5)
081- long(1) refcount(1)
083+ long(3) refcount(5)
083- long(3) refcount(1)
094+ long(10) refcount(1)
094- long(10) refcount(5)
096+ long(20) refcount(1)
096- long(20) refcount(5)
098+ long(30) refcount(1)
098- long(30) refcount(7)
100+ array(2) refcount(1){
100- array(2) refcount(5){
102+ long(1) refcount(5)
102- long(1) refcount(1)
104+ long(3) refcount(5)
104- long(3) refcount(1)
111+ long(10) refcount(1)
111- long(10) refcount(5)
113+ long(20) refcount(1)
113- long(20) refcount(5)
115+ long(30) refcount(1)
115- long(30) refcount(7)
117+ array(2) refcount(1){
117- array(2) refcount(5){
119+ long(1) refcount(5)
119- long(1) refcount(1)
121+ long(3) refcount(5)
121- long(3) refcount(1)
132+ long(10) refcount(1)
132- long(10) refcount(5)
134+ long(20) refcount(1)
134- long(20) refcount(5)
136+ long(30) refcount(3)
136- long(30) refcount(7)
138+ array(2) refcount(1){
138- array(2) refcount(5){
140+ long(1) refcount(5)
140- long(1) refcount(1)
142+ long(3) refcount(5)
142- long(3) refcount(1)
149+ long(10) refcount(1)
149- long(10) refcount(5)
151+ long(20) refcount(1)
151- long(20) refcount(5)
153+ long(30) refcount(3)
153- long(30) refcount(7)
155+ array(2) refcount(1){
155- array(2) refcount(5){
157+ long(1) refcount(5)
157- long(1) refcount(1)
159+ long(3) refcount(5)
159- long(3) refcount(1)
170+ long(10) refcount(1)
170- long(10) refcount(5)
172+ long(20) refcount(1)
172- long(20) refcount(5)
174+ long(30) refcount(1)
174- long(30) refcount(7)
176+ array(2) refcount(1){
176- array(2) refcount(5){
178+ long(1) refcount(5)
178- long(1) refcount(1)
180+ long(3) refcount(5)
180- long(3) refcount(1)
187+ long(10) refcount(1)
187- long(10) refcount(5)
189+ long(20) refcount(1)
189- long(20) refcount(5)
191+ long(30) refcount(1)
191- long(30) refcount(7)
193+ array(2) refcount(1){
193- array(2) refcount(5){
195+ long(1) refcount(5)
195- long(1) refcount(1)
197+ long(3) refcount(5)
197- long(3) refcount(1)
209+ long(30) refcount(1)
209- long(30) refcount(2)
211+ long(40) refcount(1)
211- long(40) refcount(2)
213+ long(50) refcount(1)
213- long(50) refcount(2)
219+ long(10) refcount(1)
219- long(10) refcount(5)
221+ long(20) refcount(1)
221- long(20) refcount(5)
223+ long(30) refcount(3)
223- long(30) refcount(7)
225+ array(2) refcount(1){
225- array(2) refcount(5){
227+ long(1) refcount(5)
227- long(1) refcount(1)
229+ long(3) refcount(5)
229- long(3) re
[PHP-BUG] Bug #61928 [NEW]: Instanciate object for aliased class
From:
Operating system: Linux 3.3.4
PHP version: 5.3.12
Package: Class/Object related
Bug Type: Bug
Bug description:Instanciate object for aliased class
Description:
Creating a class from variable when it has been imported with use keyword
fails
with class not found error.
This problems persists in 5.3.11, 5.3.12 and 5.4.1
Test script:
---
use stdClass as Foo;
$class = "Foo";
new $class;
Expected result:
No output
Actual result:
--
PHP Fatal error: Class 'Foo' not found in /tmp/test.php on line 6
PHP Stack trace:
PHP 1. {main}() /tmp/test.php:0
Fatal error: Class 'Foo' not found in /tmp/test.php on line 6
Call Stack:
0.0003 631856 1. {main}() /tmp/test.php:0
--
Edit bug report at https://bugs.php.net/bug.php?id=61928&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61928&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61928&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61928&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61928&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61928&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61928&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61928&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61928&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61928&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61928&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61928&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61928&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61928&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61928&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61928&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61928&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61928&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61928&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61928&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61928&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61928&r=mysqlcfg
Bug #61928 [Com]: Instanciate object for aliased class
Edit report at https://bugs.php.net/bug.php?id=61928&edit=1 ID: 61928 Comment by: olav at fwt dot no Reported by:olav at fwt dot no Summary:Instanciate object for aliased class Status: Open Type: Bug Package:Class/Object related Operating System: Linux 3.3.4 PHP Version:5.3.12 Block user comment: N Private report: N New Comment: It seems this problem is not related to the use keyword but imported items in general: file: test2.php https://bugs.php.net/bug.php?id=61928&edit=1
[PHP-BUG] Bug #61929 [NEW]: Possible bug in ts_resource_ex of TSRM.c
From:
Operating system: All
PHP version: 5.4.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Possible bug in ts_resource_ex of TSRM.c
Description:
While reviewing source code for both 5.4.2 and 5.3.12 I noticed what looks
like a bug in the implementation of ts_resource_ex in TSRM.c
I have not experienced a problem, but from the code it looks like there is
a condition in which a mutex will be locked and never unlocked.
In TSRM.c within the implementation of ts_resource_ex, starting about line
345 I see the following:
tsrm_mutex_lock(tsmm_mutex);
...
else {
allocate_new_resource(&thread_resources->next, thread_id);
return ts_resource_ex(id, &thread_id);
/*
* thread_resources = thread_resources->next;
* break;
*/
... }
tsrm_mutex_unlock(tsmm_mutex);
I think the "break" in the old code that has been commented out is correct,
and the "return" in the new code is uncorrect. I think that in the event
this branch of execution be taken, the tsmm_mutex will be locked but will
never be unlocked.
Alternatively, if the thinking was that the recursive call to
ts_resource_ex would unlock the mutex, I think there is still a problem
because in this case the mutex would be locked twice, but unlocked only
once.
Finally, if somehow the code is correct as it stands, it is sufficiently
confusing that a comment should be added.
--
Edit bug report at https://bugs.php.net/bug.php?id=61929&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61929&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61929&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61929&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61929&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61929&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61929&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61929&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61929&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61929&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61929&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61929&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61929&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61929&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61929&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61929&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61929&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61929&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61929&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61929&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61929&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61929&r=mysqlcfg
[PHP-BUG] Bug #61930 [NEW]: openssl corrupts ssl key resource when using openssl_get_publickey()
From: Operating system: * PHP version: 5.4.2 Package: OpenSSL related Bug Type: Bug Bug description:openssl corrupts ssl key resource when using openssl_get_publickey() Description: If openssl_get_publickey() is applied to a key resource, the resource that comes out of it has wrong refcount and if freed, the argument of openssl_get_publickey() gets freed too. Test script: --- If we have a certificate in $cert and data in $data and valid signature in $sign, this works: $key = openssl_get_publickey($cert); var_dump(openssl_verify($data, $sig, $key)); however this does not: $key = openssl_get_publickey($cert); var_dump(openssl_get_publickey($key)); var_dump(openssl_verify($data, $sig, $key)); it produces errors like this: Warning: openssl_verify(): 4 is not a valid OpenSSL X.509/key resource in /Users/smalyshev/osslbug.php on line 29 Warning: openssl_verify(): supplied key param cannot be coerced into a public key in /Users/smalyshev/osslbug.php on line 29 -- Edit bug report at https://bugs.php.net/bug.php?id=61930&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61930&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61930&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61930&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61930&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61930&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61930&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61930&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61930&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61930&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61930&r=support Expected behavior: https://bugs.php.net/fix.php?id=61930&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61930&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61930&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61930&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61930&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61930&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61930&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61930&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61930&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61930&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61930&r=mysqlcfg
Req #60832 [Com]: run webserver in silent-mode for script
Edit report at https://bugs.php.net/bug.php?id=60832&edit=1 ID: 60832 Comment by: roberts at x0 dot lv Reported by:info at jdhome dot net Summary:run webserver in silent-mode for script Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: winXP PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: It is not the purpose of built-in web server to be used in "silent mode" like that, therefore this is not a problem of PHP itself. You could use some server manager or other 3rd party tools, e.g LIT Porter of mine, to start PHP process and then You can close control center window. Previous Comments: [2012-01-21 16:56:56] info at jdhome dot net Description: I want to run the built-in Webserver in silent Mode. Why? I love the ultramicro built-in-server to execute some scripts written in php by browsing an ultramicro-website or to generate file-overview to browse in. The php-win isn't able to run that built-in server and so its not possible to run that server real quitly in background. All i want is the built-in-server functions without that annoying cli-window :) So please add the builtin-webserver in the php-win.exe!! -- Edit this bug report at https://bugs.php.net/bug.php?id=60832&edit=1
Bug #61930 [Opn]: openssl corrupts ssl key resource when using openssl_get_publickey()
Edit report at https://bugs.php.net/bug.php?id=61930&edit=1
ID: 61930
Updated by: s...@php.net
Reported by:s...@php.net
Summary:openssl corrupts ssl key resource when using
openssl_get_publickey()
Status: Open
Type: Bug
Package:OpenSSL related
Operating System: *
PHP Version:5.4.2
Block user comment: N
Private report: N
New Comment:
The problem happens because php_openssl_evp_from_zval on receiving resource
with
public key, is doing just this:
if (resourceval) {
*resourceval = Z_LVAL_PP(val);
}
and then:
return (EVP_PKEY*)what;
while openssl_pkey_get_public() does this:
Z_TYPE_P(return_value) = IS_RESOURCE;
pkey = php_openssl_evp_from_zval(cert, 1, NULL, 1, &Z_LVAL_P(return_value)
TSRMLS_CC);
so the refcount of the resource in return_value is never increased, even though
it is assigned now to another variable. When the return_value is freed, so is
the resource, thus corrupting data in $key.
Previous Comments:
[2012-05-03 20:18:08] s...@php.net
Description:
If openssl_get_publickey() is applied to a key resource, the resource that
comes
out of it has wrong refcount and if freed, the argument of
openssl_get_publickey() gets freed too.
Test script:
---
If we have a certificate in $cert and data in $data and valid signature in
$sign, this works:
$key = openssl_get_publickey($cert);
var_dump(openssl_verify($data, $sig, $key));
however this does not:
$key = openssl_get_publickey($cert);
var_dump(openssl_get_publickey($key));
var_dump(openssl_verify($data, $sig, $key));
it produces errors like this:
Warning: openssl_verify(): 4 is not a valid OpenSSL X.509/key resource in
/Users/smalyshev/osslbug.php on line 29
Warning: openssl_verify(): supplied key param cannot be coerced into a public
key in /Users/smalyshev/osslbug.php on line 29
--
Edit this bug report at https://bugs.php.net/bug.php?id=61930&edit=1
Bug #55334 [Com]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Comment by: mattfic...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: johannes, your patch works for me with 5.4.1 on a 4-way and an 8-way windows 2008r2 server with: ab -n 1 -c 20 ab -n 10 -c 20 ab -n 10 -c 50 and ab -n 1 -c 50. Previous Comments: [2012-05-02 09:47:14] johan...@php.net Matt, can you give it a new run. The change http://git.php.net/?p=php-src.git;a=commit;h=ea3e0d5a7370df63af9372780b91a749fda773b1 which is in 5.4.1 should fix the issue for 5.4. See also http://news.php.net/php.internals/59353 I wasn't able to see an issue neither in 5.3 nor 5.4 after having a 64-way Solaris machine running for a few hours. For Windows I did only a shorter test on a 4-way machine. [2012-04-08 22:19:22] ricardo dot nuno dot rodrigues at hotmail dot com Hi there, In PHP 5.4 TS VC9 (Win) I have the same problem. Under stress goes down. With file mysql_test.php: Under: ab -n 1 -c 50 http://127.0.0.1/mysql_test.php It restart server (apache 2.2.21). Sometimes creates a delay. Under xdebug there's a big time to connect. Thanks Ricardo [2012-03-12 17:21:41] paj...@php.net Johannes, See last comment, I can also still reproduce it locally (dual quad). [2012-03-09 23:08:26] mattfic...@php.net To repro this problem, your test environment needs to have 4+ cpus, which the environment I was previously using didn't have. [2012-03-09 19:07:38] mattfic...@php.net Closing bug 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=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
[PHP-BUG] Req #61931 [NEW]: Built-in web server should have a seperate log file
From: Operating system: Windows PHP version: 5.4.2 Package: Built-in web server Bug Type: Feature/Change Request Bug description:Built-in web server should have a seperate log file Description: All PHP version 5.4.+ built-in web servers does log errors only in STDOUT with no option to redirect this output to file via command line option. Command line redirect would not be a option here, as because one needs to stop PHP web server instance before output gets written to the file. There should be .ini option added - server_log or similar, to configure log output to file or to STDOUT. -- Edit bug report at https://bugs.php.net/bug.php?id=61931&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61931&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61931&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61931&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61931&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61931&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61931&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61931&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61931&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61931&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61931&r=support Expected behavior: https://bugs.php.net/fix.php?id=61931&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61931&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61931&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61931&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61931&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61931&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61931&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61931&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61931&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61931&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61931&r=mysqlcfg
[PHP-BUG] Req #61932 [NEW]: garbage collector destroys session of caller, no write
From: Operating system: ubuntu PHP version: Irrelevant Package: Session related Bug Type: Feature/Change Request Bug description:garbage collector destroys session of caller, no write Description: The order is session open, session read, session gc. This applies to the case where the garbage collector is triggered by the client X and the session is of client X. The session variables are available in script, but the sessionfile is deleted and no write of the session takes place. For the php user and the php application user there is the impression that the session still is alive. Example: User is logged in with cookie with sessionid in an admin application and is logged in as admin which is registerred in the session. Has admin form bookmarked or in history. Php script does gc removes sessionfile. But the session variables indicate that the user is logged in and so the script spits out the form. User does a post and poof suddenly there is no session. This is seemingly random behaviour and no ordinary php programmer and user has any idea what is going on. This sounds like one in a million but could happen quite often with a database application in a small business. So either the session should be removed before open and read, which I understand you won't do (Bug #35479) or it should be continued and rewritten to file, which is what the bahaviour when you write the most straightforward handler for a session database Also as a dev. how do I know it is garbage collected? Test script: --- setup: ubuntu package mod php 5.3.10 on apache2 mpm prefork relevant and changed ini setting: session.gc_maxlifetime = 1 session.save_path = /tmp Expected result: session that is garbage collected by invocation of session owner (http client) is rewritten to a new file Actual result: -- session variables are available but session is effectively destroyed, giving the impression that the session is still live when it is not -- Edit bug report at https://bugs.php.net/bug.php?id=61932&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61932&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61932&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61932&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61932&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61932&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61932&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61932&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61932&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61932&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61932&r=support Expected behavior: https://bugs.php.net/fix.php?id=61932&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61932&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61932&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61932&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61932&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61932&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61932&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61932&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61932&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61932&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61932&r=mysqlcfg
Bug #61909 [Com]: PHP realpath on Windows Case Issue
Edit report at https://bugs.php.net/bug.php?id=61909&edit=1
ID: 61909
Comment by: david at panmedia dot co dot nz
Reported by:david at panmedia dot co dot nz
Summary:PHP realpath on Windows Case Issue
Status: Not a bug
Type: Bug
Package:Filesystem function related
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@pajoye, you missed my point about realpath not resolving the correct link
target if the case is different. See my first comment.
Previous Comments:
[2012-05-03 05:51:04] paj...@php.net
We do not support case sensitive paths on windows, so do 99.999% of the windows
apps as well.
strcasecmp is what you actually need.
[2012-05-03 03:16:50] david at panmedia dot co dot nz
@larue...@php.net
Well, not always. In Windows Server 2008 it can be configured.
http://technet.microsoft.com/en-us/library/cc725747.aspx
Also, the point of realpath is to return the canonicalized absolute pathname,
but it does not. Especially in the case of nested symlinks, as I pointed out in
my other comment.
You should be able to test if a path is the same by going
if (realpath('c:\path-to-link') === realpath('C:\RealPathToTarget')) ...
[2012-05-03 03:10:56] larue...@php.net
path in windows is case insensitive..
[2012-05-02 17:46:25] david at panmedia dot co dot nz
On further investigation I have noticed that on Windows symlinks are only
followed 1 level deep:
// F:\>mkdir link-target
// F:\>mklink /D link f:\link-target
// F:\>mklink /D link2 f:\link
$dir = realpath('f:\link2');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
// string 'f:\link' (length=7)
// string 'f:\link-target' (length=14)
// string 'F:\link-target' (length=14)
[2012-05-02 17:37:52] david at panmedia dot co dot nz
Description:
I have a symlink on my Windows server which was made like this:
F:\>mkdir link-target
F:\>mklink /D link f:\link-target
(Note the lower case f: in the symlink target)
In PHP I run this:
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Which outputs:
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
Notice the change in case on the second realpath.
The expected output is:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Test script:
---
mkdir link-target
// F:\>mklink /D link f:\link-target
$dir = realpath('f:\link');
var_dump($dir);
$dir = realpath($dir);
var_dump($dir);
Expected result:
string 'F:\link-target' (length=14)
string 'F:\link-target' (length=14)
Actual result:
--
string 'f:\link-target' (length=14)
string 'F:\link-target' (length=14)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61909&edit=1
[PHP-BUG] Bug #61933 [NEW]: realpath not resolving symlinks corrrectly
From:
Operating system: Windows Vista/7
PHP version: Irrelevant
Package: *Directory/Filesystem functions
Bug Type: Bug
Bug description:realpath not resolving symlinks corrrectly
Description:
When creating a symlink in Windows to an absolute path with a lower case
drive letter, PHP will not resolve the canonicalized absolute pathname
(realpath) correctly.
This is obvious when you have nested symlinks.
When you run realpath of a nested symlink it returns the next symlink it
links to, rather than the top absolute pathname.
On Linux it works correctly.
One work around that can be used is:
$link = 'f:\link3';
do {
$link = realpath($link);
} while (realpath($link) !== false && $link !== realpath($link));
Test script:
---
Windows test:
F:\>mkdir target
F:\>mklink /D link1 f:\target
F:\>mklink /D link2 f:\link1
F:\>mklink /D link3 f:\link2
F:\>php -r "var_dump(realpath('link3'));"
Linux test:
$ mkdir target
$ ln -s target link1
$ ln -s link1 link2
$ ln -s link2 link3
$ php -r "var_dump(realpath('link3'));"
Expected result:
Windows test:
string(9) "F:\target"
Linux test:
string(12) "/root/target"
Actual result:
--
Windows test:
string(9) "f:\\link2"
Linux test:
string(12) "/root/target"
--
Edit bug report at https://bugs.php.net/bug.php?id=61933&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61933&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61933&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61933&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61933&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61933&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61933&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61933&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61933&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61933&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61933&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61933&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61933&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61933&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61933&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61933&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61933&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61933&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61933&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61933&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61933&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61933&r=mysqlcfg
Bug #61933 [Opn->Fbk]: realpath not resolving symlinks corrrectly
Edit report at https://bugs.php.net/bug.php?id=61933&edit=1
ID: 61933
Updated by: paj...@php.net
Reported by:david at panmedia dot co dot nz
Summary:realpath not resolving symlinks corrrectly
-Status: Open
+Status: Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
It does work, it gives you the target of the given link.
The only difference is an OS specific implementation where all links are
resolved.
I suppose you use a TS php on windows and a NTS on linux, right?
Previous Comments:
[2012-05-03 21:32:36] david at panmedia dot co dot nz
Description:
When creating a symlink in Windows to an absolute path with a lower case drive
letter, PHP will not resolve the canonicalized absolute pathname (realpath)
correctly.
This is obvious when you have nested symlinks.
When you run realpath of a nested symlink it returns the next symlink it links
to, rather than the top absolute pathname.
On Linux it works correctly.
One work around that can be used is:
$link = 'f:\link3';
do {
$link = realpath($link);
} while (realpath($link) !== false && $link !== realpath($link));
Test script:
---
Windows test:
F:\>mkdir target
F:\>mklink /D link1 f:\target
F:\>mklink /D link2 f:\link1
F:\>mklink /D link3 f:\link2
F:\>php -r "var_dump(realpath('link3'));"
Linux test:
$ mkdir target
$ ln -s target link1
$ ln -s link1 link2
$ ln -s link2 link3
$ php -r "var_dump(realpath('link3'));"
Expected result:
Windows test:
string(9) "F:\target"
Linux test:
string(12) "/root/target"
Actual result:
--
Windows test:
string(9) "f:\\link2"
Linux test:
string(12) "/root/target"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61933&edit=1
Bug #61933 [Com]: realpath not resolving symlinks corrrectly
Edit report at https://bugs.php.net/bug.php?id=61933&edit=1
ID: 61933
Comment by: david at panmedia dot co dot nz
Reported by:david at panmedia dot co dot nz
Summary:realpath not resolving symlinks corrrectly
Status: Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@pajoye I am using VC9 NTS version on Windows.
Previous Comments:
[2012-05-03 22:43:36] paj...@php.net
It does work, it gives you the target of the given link.
The only difference is an OS specific implementation where all links are
resolved.
I suppose you use a TS php on windows and a NTS on linux, right?
[2012-05-03 21:32:36] david at panmedia dot co dot nz
Description:
When creating a symlink in Windows to an absolute path with a lower case drive
letter, PHP will not resolve the canonicalized absolute pathname (realpath)
correctly.
This is obvious when you have nested symlinks.
When you run realpath of a nested symlink it returns the next symlink it links
to, rather than the top absolute pathname.
On Linux it works correctly.
One work around that can be used is:
$link = 'f:\link3';
do {
$link = realpath($link);
} while (realpath($link) !== false && $link !== realpath($link));
Test script:
---
Windows test:
F:\>mkdir target
F:\>mklink /D link1 f:\target
F:\>mklink /D link2 f:\link1
F:\>mklink /D link3 f:\link2
F:\>php -r "var_dump(realpath('link3'));"
Linux test:
$ mkdir target
$ ln -s target link1
$ ln -s link1 link2
$ ln -s link2 link3
$ php -r "var_dump(realpath('link3'));"
Expected result:
Windows test:
string(9) "F:\target"
Linux test:
string(12) "/root/target"
Actual result:
--
Windows test:
string(9) "f:\\link2"
Linux test:
string(12) "/root/target"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61933&edit=1
Bug #61933 [Fbk]: realpath not resolving symlinks corrrectly
Edit report at https://bugs.php.net/bug.php?id=61933&edit=1
ID: 61933
Updated by: paj...@php.net
Reported by:david at panmedia dot co dot nz
Summary:realpath not resolving symlinks corrrectly
Status: Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I mean on linux too, is it TS or NTS?
Previous Comments:
[2012-05-03 22:58:18] david at panmedia dot co dot nz
@pajoye I am using VC9 NTS version on Windows.
[2012-05-03 22:43:36] paj...@php.net
It does work, it gives you the target of the given link.
The only difference is an OS specific implementation where all links are
resolved.
I suppose you use a TS php on windows and a NTS on linux, right?
[2012-05-03 21:32:36] david at panmedia dot co dot nz
Description:
When creating a symlink in Windows to an absolute path with a lower case drive
letter, PHP will not resolve the canonicalized absolute pathname (realpath)
correctly.
This is obvious when you have nested symlinks.
When you run realpath of a nested symlink it returns the next symlink it links
to, rather than the top absolute pathname.
On Linux it works correctly.
One work around that can be used is:
$link = 'f:\link3';
do {
$link = realpath($link);
} while (realpath($link) !== false && $link !== realpath($link));
Test script:
---
Windows test:
F:\>mkdir target
F:\>mklink /D link1 f:\target
F:\>mklink /D link2 f:\link1
F:\>mklink /D link3 f:\link2
F:\>php -r "var_dump(realpath('link3'));"
Linux test:
$ mkdir target
$ ln -s target link1
$ ln -s link1 link2
$ ln -s link2 link3
$ php -r "var_dump(realpath('link3'));"
Expected result:
Windows test:
string(9) "F:\target"
Linux test:
string(12) "/root/target"
Actual result:
--
Windows test:
string(9) "f:\\link2"
Linux test:
string(12) "/root/target"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61933&edit=1
Bug #61933 [Com]: realpath not resolving symlinks corrrectly
Edit report at https://bugs.php.net/bug.php?id=61933&edit=1
ID: 61933
Comment by: david at panmedia dot co dot nz
Reported by:david at panmedia dot co dot nz
Summary:realpath not resolving symlinks corrrectly
Status: Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Windows Vista/7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
@pajoye, sorry, NTS on Linux too.
Previous Comments:
[2012-05-03 23:04:48] paj...@php.net
I mean on linux too, is it TS or NTS?
[2012-05-03 22:58:18] david at panmedia dot co dot nz
@pajoye I am using VC9 NTS version on Windows.
[2012-05-03 22:43:36] paj...@php.net
It does work, it gives you the target of the given link.
The only difference is an OS specific implementation where all links are
resolved.
I suppose you use a TS php on windows and a NTS on linux, right?
[2012-05-03 21:32:36] david at panmedia dot co dot nz
Description:
When creating a symlink in Windows to an absolute path with a lower case drive
letter, PHP will not resolve the canonicalized absolute pathname (realpath)
correctly.
This is obvious when you have nested symlinks.
When you run realpath of a nested symlink it returns the next symlink it links
to, rather than the top absolute pathname.
On Linux it works correctly.
One work around that can be used is:
$link = 'f:\link3';
do {
$link = realpath($link);
} while (realpath($link) !== false && $link !== realpath($link));
Test script:
---
Windows test:
F:\>mkdir target
F:\>mklink /D link1 f:\target
F:\>mklink /D link2 f:\link1
F:\>mklink /D link3 f:\link2
F:\>php -r "var_dump(realpath('link3'));"
Linux test:
$ mkdir target
$ ln -s target link1
$ ln -s link1 link2
$ ln -s link2 link3
$ php -r "var_dump(realpath('link3'));"
Expected result:
Windows test:
string(9) "F:\target"
Linux test:
string(12) "/root/target"
Actual result:
--
Windows test:
string(9) "f:\\link2"
Linux test:
string(12) "/root/target"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61933&edit=1
Bug #61924 [Fbk]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Updated by: larue...@php.net
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
Status: Feedback
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Actually, I think it's a improvement of PHP-5.4, this change is introduced by
fixing this issue: https://bugs.php.net/bug.php?id=60573
before this, you declare
class A implements IComparable{
public function equals(self $other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
actullay the self in here is A, not IComparable.
but in the IComparable, the self means IComparable itsself.
In scrupulously, A is_a Icomparable, but not equal to Icomperable, what do you
think?
thanks
Previous Comments:
[2012-05-03 16:48:08] larue...@php.net
Oh, sorry I misunderstanded , assign to my self , should have Sth to do with a
fix
made by me
[2012-05-03 15:22:17] jenwelsh at yahoo dot com
The reason I "think" it did work, is because it is **currently** working on a
production site with PHP 5.3.11. And it **has** been working for over 2 years.
[2012-05-03 14:52:08] larue...@php.net
or you can change it to a feature request :)
[2012-05-03 14:45:32] larue...@php.net
it's always not allowed since php 5.2, why are you thinking it worked once?
[2012-05-03 14:20:54] jenwelsh at yahoo dot com
Description:
I am reviewing existing code on a PHP5.4.1 testbed. I've discovered that
interface declarations using 'self' as a type hint no longer allow
implementations to use 'self' but require them to use the interface name.
It is no longer possible for an interface to declare a method that requires the
implementor's class as a typehint without declaring that class specifically.
And that would limit the usefulness of that interface to one class only.
Test script:
---
interface IComparable {
public function equals(self $other);
}
class A implements IComparable{
protected $var;
public function __construct(self $v){
$this->var=$v;
}
public function equals($other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
$a1= new A(7);
$a2= new A(5);
$a3= new A(5);
echo $a1->equals($a2),"\n";
echo $a2->equals($a3),"\n";
Expected result:
different
equal
Actual result:
--
PHP Fatal error: Declaration of A::equals() must be compatible with
IComparable::equals(IComparable $other)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
Bug #61924 [Fbk]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Updated by: col...@php.net
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
Status: Feedback
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The rule was previously accepted as the type hints where simple syntactic check
(basically string comparisons). This was wrong, and got fixed in 5.4.
You cannot use self/parent as type hints as they depend on the current type in
a
covariant fashion, and type hints need to be contravariant.
To explicit the problem in 5.3:
interface A { public function foo(self $a); }
class B implements A { public function foo(self $a) { } }
class C implements A { public function foo(self $a) { } }
If B (and C) are valid (per foo(new C); }
test(new B) will fail
test(new C) will work
A side effect from this fix is that the wrong typehint now fails with an error,
since B/C are invalid implementations of A.
Previous Comments:
[2012-05-04 00:48:01] larue...@php.net
Actually, I think it's a improvement of PHP-5.4, this change is introduced by
fixing this issue: https://bugs.php.net/bug.php?id=60573
before this, you declare
class A implements IComparable{
public function equals(self $other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
actullay the self in here is A, not IComparable.
but in the IComparable, the self means IComparable itsself.
In scrupulously, A is_a Icomparable, but not equal to Icomperable, what do you
think?
thanks
[2012-05-03 16:48:08] larue...@php.net
Oh, sorry I misunderstanded , assign to my self , should have Sth to do with a
fix
made by me
[2012-05-03 15:22:17] jenwelsh at yahoo dot com
The reason I "think" it did work, is because it is **currently** working on a
production site with PHP 5.3.11. And it **has** been working for over 2 years.
[2012-05-03 14:52:08] larue...@php.net
or you can change it to a feature request :)
[2012-05-03 14:45:32] larue...@php.net
it's always not allowed since php 5.2, why are you thinking it worked once?
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=61924
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
Bug #61924 [Fbk->Nab]: cannot use self in interface function declaration
Edit report at https://bugs.php.net/bug.php?id=61924&edit=1
ID: 61924
Updated by: col...@php.net
Reported by:jenwelsh at yahoo dot com
Summary:cannot use self in interface function declaration
-Status: Feedback
+Status: Not a bug
Type: Bug
Package:Class/Object related
PHP Version:5.4.1
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Just to make it clear, you can use self/parent as type hints, as long as the
class they reference is right, for instance:
class A {
public function foo(self $plop) { }
}
class B extends A {
public function foo(A $plop) { }
}
class C extends A {
public function foo(parent $plop) { }
}
are all equally fine. since parent in C is A, and self in A is A.
Previous Comments:
[2012-05-04 02:18:34] col...@php.net
The rule was previously accepted as the type hints where simple syntactic check
(basically string comparisons). This was wrong, and got fixed in 5.4.
You cannot use self/parent as type hints as they depend on the current type in
a
covariant fashion, and type hints need to be contravariant.
To explicit the problem in 5.3:
interface A { public function foo(self $a); }
class B implements A { public function foo(self $a) { } }
class C implements A { public function foo(self $a) { } }
If B (and C) are valid (per foo(new C); }
test(new B) will fail
test(new C) will work
A side effect from this fix is that the wrong typehint now fails with an error,
since B/C are invalid implementations of A.
[2012-05-04 00:48:01] larue...@php.net
Actually, I think it's a improvement of PHP-5.4, this change is introduced by
fixing this issue: https://bugs.php.net/bug.php?id=60573
before this, you declare
class A implements IComparable{
public function equals(self $other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}
actullay the self in here is A, not IComparable.
but in the IComparable, the self means IComparable itsself.
In scrupulously, A is_a Icomparable, but not equal to Icomperable, what do you
think?
thanks
[2012-05-03 16:48:08] larue...@php.net
Oh, sorry I misunderstanded , assign to my self , should have Sth to do with a
fix
made by me
[2012-05-03 15:22:17] jenwelsh at yahoo dot com
The reason I "think" it did work, is because it is **currently** working on a
production site with PHP 5.3.11. And it **has** been working for over 2 years.
[2012-05-03 14:52:08] larue...@php.net
or you can change it to a feature request :)
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=61924
--
Edit this bug report at https://bugs.php.net/bug.php?id=61924&edit=1
[PHP-BUG] Bug #61936 [NEW]: GDB：____executor_globals fails when EG/CG symbol may not visible in some module
From: Operating system: *Nix PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:GDBï¼executor_globals fails when EG/CG symbol may not visible in some module Description: when debug using GDB, sometime executor_globals failed to execute because in some module eg:zend_gc.c did have zend_executor_global exposed(Only ZTS model affectedï¼since executor_globals always available). Test script: --- (gdb) b gc_zval_possible_root Breakpoint 1 at 0x1005aa7d0: file zend_gc.c, line 132. (gdb) r circle.php Starting program: /Users/reeze/Opensource/php-src/sapi/cli/php circle.php Reading symbols for shared libraries ++.. done Breakpoint 1, gc_zval_possible_root (zv=0x100dcbb58, tsrm_ls=0x100e009b0) at zend_gc.c:132 warning: Source file is more recent than executable. 132 if (UNEXPECTED(GC_G(free_list) != NULL && (gdb) printzv zv No symbol "zend_executor_globals" in current context. Expected result: print zval correctly Actual result: -- No symbol "zend_executor_globals" in current context. -- Edit bug report at https://bugs.php.net/bug.php?id=61936&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61936&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61936&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61936&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61936&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61936&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61936&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61936&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61936&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61936&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61936&r=support Expected behavior: https://bugs.php.net/fix.php?id=61936&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61936&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61936&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61936&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61936&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61936&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61936&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61936&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61936&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61936&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61936&r=mysqlcfg
Bug #61936 [Com]: GDB：____executor_globals fails when EG/CG symbol may not visible in some modul
Edit report at https://bugs.php.net/bug.php?id=61936&edit=1 ID: 61936 Comment by: reeze dot xia at gmail dot com Reported by:reeze dot xia at gmail dot com Summary:GDBï¼executor_globals fails when EG/CG symbol may not visible in some modul Status: Open Type: Bug Package:*General Issues Operating System: *Nix PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Hi, I've sent a pull request. open this bug ticket just for record. see https://github.com/php/php-src/pull/74/ Thanks. Previous Comments: [2012-05-04 03:57:14] reeze dot xia at gmail dot com Description: when debug using GDB, sometime executor_globals failed to execute because in some module eg:zend_gc.c did have zend_executor_global exposed(Only ZTS model affectedï¼since executor_globals always available). Test script: --- (gdb) b gc_zval_possible_root Breakpoint 1 at 0x1005aa7d0: file zend_gc.c, line 132. (gdb) r circle.php Starting program: /Users/reeze/Opensource/php-src/sapi/cli/php circle.php Reading symbols for shared libraries ++.. done Breakpoint 1, gc_zval_possible_root (zv=0x100dcbb58, tsrm_ls=0x100e009b0) at zend_gc.c:132 warning: Source file is more recent than executable. 132 if (UNEXPECTED(GC_G(free_list) != NULL && (gdb) printzv zv No symbol "zend_executor_globals" in current context. Expected result: print zval correctly Actual result: -- No symbol "zend_executor_globals" in current context. -- Edit this bug report at https://bugs.php.net/bug.php?id=61936&edit=1
Bug #61936 [Opn]: GDB：____executor_globals fails when EG/CG symbol may not visible in some modul
Edit report at https://bugs.php.net/bug.php?id=61936&edit=1 ID: 61936 User updated by:reeze dot xia at gmail dot com Reported by:reeze dot xia at gmail dot com Summary:GDBï¼executor_globals fails when EG/CG symbol may not visible in some modul Status: Open Type: Bug Package:*General Issues Operating System: *Nix PHP Version:Irrelevant Block user comment: N Private report: N New Comment: sorry I missed " in non-ZTS build " after "affectedï¼since executor_globals always available)." It's: "Only ZTS build affectedï¼since executor_globals/compiler_globals always available in non-ZTS build" Previous Comments: [2012-05-04 04:03:46] reeze dot xia at gmail dot com Hi, I've sent a pull request. open this bug ticket just for record. see https://github.com/php/php-src/pull/74/ Thanks. [2012-05-04 03:57:14] reeze dot xia at gmail dot com Description: when debug using GDB, sometime executor_globals failed to execute because in some module eg:zend_gc.c did have zend_executor_global exposed(Only ZTS model affectedï¼since executor_globals always available). Test script: --- (gdb) b gc_zval_possible_root Breakpoint 1 at 0x1005aa7d0: file zend_gc.c, line 132. (gdb) r circle.php Starting program: /Users/reeze/Opensource/php-src/sapi/cli/php circle.php Reading symbols for shared libraries ++.. done Breakpoint 1, gc_zval_possible_root (zv=0x100dcbb58, tsrm_ls=0x100e009b0) at zend_gc.c:132 warning: Source file is more recent than executable. 132 if (UNEXPECTED(GC_G(free_list) != NULL && (gdb) printzv zv No symbol "zend_executor_globals" in current context. Expected result: print zval correctly Actual result: -- No symbol "zend_executor_globals" in current context. -- Edit this bug report at https://bugs.php.net/bug.php?id=61936&edit=1
