Bug #62837 [Fbk->NoF]: ISAPI方式使用PHP,会导致web服务器崩溃.
Edit report at https://bugs.php.net/bug.php?id=62837&edit=1 ID: 62837 Updated by: a...@php.net Reported by:175384354 at qq dot com Summary:ISAPIæ¹å¼ä½¿ç¨PHP,ä¼å¯¼è´webæå¡å¨å´©æº. -Status: Feedback +Status: No Feedback Type: Bug Package:*General Issues Operating System: windows server 2003 PHP Version:5.3.15 Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. Previous Comments: [2013-06-20 09:52:21] a...@php.net Besides I don't see any php related information, do you experience the same with 5.4? Please get the debug symbols as well to produce a useful BT. [2012-08-17 08:05:35] 175384354 at qq dot com Analysis Summary Type Description Recommendation Error In IOCP_HTTP_SERVER__PID__2468__Date__08_17_2012__Time_03_45_11PM__582__Second_Chance_Exception_C008.dmp the assembly instruction at ntdll!KiRaiseUserExceptionDispatcher+37 in C:\WINDOWS\system32\ntdll.dll has caused an unknown exception (0xc008) on thread 2 This exception originated from IOCP_HTTP_SERVER+ce93. This exception occured as a result of an invalid handle passed to KERNEL32!CLOSEHANDLE by the following function: IOCP_HTTP_SERVER+ce93 Please follow up with the vendor of this module for further assistance with this issue. Information DebugDiag determined that this dump file (IOCP_HTTP_SERVER__PID__2468__Date__08_17_2012__Time_03_45_11PM__582__Second_Chance_Exception_C008.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose "Allow Blocked Content..." or enable the "Allow active content to run in files on My Computer*" setting on the Advanced tab of your "Internet Options" dialog to avoid being prompted in the future Table Of Contents IOCP_HTTP_SERVER__PID__2468__Date__08_17_2012__Time_03_45_11PM__582__Second_Chance_Exception_C008.dmp Faulting Thread Faulting Module Information Report for IOCP_HTTP_SERVER__PID__2468__Date__08_17_2012__Time_03_45_11PM__582__Second_Chance_Exception_C008.dmp Report for IOCP_HTTP_SERVER__PID__2468__Date__08_17_2012__Time_03_45_11PM__582__Second_Chance_Exception_C008.dmp Type of Analysis Performed Crash Analysis Machine Name WS-YY-WEB Operating System Windows Server 2003 Service Pack 2 Number Of Processors 4 Process ID 2468 Process Image D:\I\IOCP_HTTP_SERVER.exe System Up-Time 31 day(s) 16:44:41 Process Up-Time 00:00:06 Thread 2 - System ID 3992 Entry point IOCP_HTTP_SERVER+8407 Create time 2012-8-17 15:45:06 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.15 Function Arg 1 Arg 2 Arg 3 Source ntdll!KiRaiseUserExceptionDispatcher+37 7c956d49 7c823eb3 01c0 ntdll!KiFastSystemCall+3 7c823eb3 01c0 0124fd4c ntdll!ZwClose+c 01c0 0124fd4c 0040ce93 kernel32!CloseHandle+59 01c0 01c0 IOCP_HTTP_SERVER+ce93 0124fd58 00ae2cc4 IOCP_HTTP_SERVER+a6ed 019c 00ae2724 0124ff08 IOCP_HTTP_SERVER+8871 00ae260c 0261 IOCP_HTTP_SERVER+853c 017c kernel32!BaseThreadStart+34 00408407 017c In IOCP_HTTP_SERVER__PID__2468__Date__08_17_2012__Time_03_45_11PM__582__Second_Chance_Exception_C008.dmp the assembly instruction at ntdll!KiRaiseUserExceptionDispatcher+37 in C:\WINDOWS\system32\ntdll.dll has caused an unknown exception (0xc008) on thread 2 This exception originated from IOCP_HTTP_SERVER+ce93. Module Information Image Name: D:\I\IOCP_HTTP_SERVER.exe Symbol Type: None Base address: 0x0040 Time Stamp: Thu Jan 01 11:25:45 1970 Checksum: 0x Comments: COM DLL: False Company Name: ISAPIExtension: False File Description: ISAPIFilter: False File Version: Managed DLL: False Internal Name: VB DLL: False Legal Copyright: Loaded Image Name: IOCP_HTTP_SERV
[PHP-BUG] Bug #65131 [NEW]: $UserData & $_SESSION
From: buhsoft at mail dot ru Operating system: Windows 7 PHP version: 5.3.26 Package: Session related Bug Type: Bug Bug description:$UserData & $_SESSION Description: First output: Array ( [UserData] => 999 ) Array ( [UserData] => 999 ) After page updating in browser output: Array ( [UserData] => 999 ) Array ( [UserData] => ) i.e. using variable $UserData impact on content of $_SESSION array Test script: --- ТÐСТ 2 \n"; $UserData=""; print_r($_SESSION); echo "\n"; ?> -- Edit bug report at https://bugs.php.net/bug.php?id=65131&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65131&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65131&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65131&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65131&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65131&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65131&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65131&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65131&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65131&r=support Expected behavior: https://bugs.php.net/fix.php?id=65131&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65131&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65131&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65131&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65131&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65131&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65131&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65131&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65131&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65131&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65131&r=mysqlcfg
Bug #65015 [Opn->Asn]: pg_send_query does not flush send buffer
Edit report at https://bugs.php.net/bug.php?id=65015&edit=1
ID: 65015
Updated by: yohg...@php.net
Reported by:adam at vektah dot net
Summary:pg_send_query does not flush send buffer
-Status: Open
+Status: Assigned
Type: Bug
Package:PostgreSQL related
Operating System: Linux
PHP Version:5.4.16
-Assigned To:
+Assigned To:yohgaki
Block user comment: N
Private report: N
New Comment:
Thanks for reporting. I'll commit this fix.
Previous Comments:
[2013-06-25 06:32:39] adam at vektah dot net
Updated summary.
[2013-06-12 03:05:50] adam at vektah dot net
Description:
When sending asynchronous postgres queries using pg_send_query() a notice will
be raised for large queries:
PHP Notice: pg_send_query(): Cannot set connection to blocking mode in
longquery.php on line 6
This only seems to happen on databases NOT hosted on the local machine.
pg_send_query() roughly does:
PQ_SETNONBLOCKING(1)
PQsendQuery()
PQ_SETNONBLOCKING(0)
PQ_SETNONBLOCKING will do this towards the end:
if (pqFlush(conn))
return -1;
and fail raising the notice if the connection still has data left in the send
buffer.
http://www.postgresql.org/docs/8.3/static/libpq-async.html mentions that:
After sending any command or data on a non-blocking connection, call PQflush.
If
it returns 1, wait for the socket to be write-ready and call it again; repeat
until it returns 0. Once PQflush returns 0, wait for the socket to be
read-ready
and then read the response as described above.
The attached patch adds a loop that waits for the buffer to empty before
calling
PQ_SETNONBLOCKING(0), and raises a notice on any errors.
PHP Versions tested:
- 5.4.9 (ubuntu package)
- 5.4.13 (source)
- 5.4.16 (source)
Postgres configurations tested:
- 9.1.9 client with 2.2.4 server
- 9.2.4 client and server
Operating systems tested:
- Ubuntu 13.04
- Centos 6
Test script:
---
$len = 10; // This may need to be increased, depending on db server.
$sql = "select 1" . str_repeat(' ', $len - 8);
$con = pg_connect('host=db-host.example.com dbname=postgres user=postgres
password=password');
pg_send_query($con, $sql);
pg_get_result($con);
Expected result:
The query should run, no notices should be rasied and the connection should be
put back into blocking mode again.
Actual result:
--
PHP Notice: pg_send_query(): Cannot set connection to blocking mode in
longquery.php on line 6
PHP Stack trace:
PHP 1. {main}()longquery.php:0
PHP 2. pg_send_query() longquery.php:6
--
Edit this bug report at https://bugs.php.net/bug.php?id=65015&edit=1
Req #65130 [Opn->Wfx]: partial XP support
Edit report at https://bugs.php.net/bug.php?id=65130&edit=1 ID: 65130 Updated by: yohg...@php.net Reported by:qtantofaz at hotmail dot com Summary:partial XP support -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Unknown/Other Function Operating System: Windows XP PHP Version:5.5.0 Block user comment: N Private report: N New Comment: XP/2003 support will be ended next year. Use older supported PHP versions. Previous Comments: [2013-06-26 03:04:36] qtantofaz at hotmail dot com Description: I run Windows XP. When I replace PHP 5.3 with 5.5, PHP gives a Server Error. This is probably intended because officially support for XP has ended. BUT: lots of people in Africa and elsewhere use still use XP extensively. And.. I presume the core isn't OS-dependent, but many libraries are. So.. why deprecate ALL of XP? Just document which libraries need something better than XP. If the core works, anyone using XP can still run with a subset of the libraries (or none at all). Which is undoubtedly sufficient for most users (developers)! -- Edit this bug report at https://bugs.php.net/bug.php?id=65130&edit=1
Bug #60803 [Fbk->Opn]: pdo-oci configuring bug
Edit report at https://bugs.php.net/bug.php?id=60803&edit=1 ID: 60803 User updated by:gureedo at gmail dot com Reported by:gureedo at gmail dot com Summary:pdo-oci configuring bug -Status: Feedback +Status: Open Type: Bug Package:PDO related Operating System: linux x86-64 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: Currently can't reproduce this bug. I think it's self fixed. Previous Comments: [2013-06-25 20:36:02] fel...@php.net Still you facing such a problem? [2012-01-19 12:00:43] gureedo at gmail dot com Description: This bug is regression from this bug solution: https://bugs.php.net/bug.php?id=44989 And same bug on gentoo site: https://bugs.gentoo.org/show_bug.cgi?id=380581 I've attached patch that searches for instant client in both oracle and orace64 dirs. -- Edit this bug report at https://bugs.php.net/bug.php?id=60803&edit=1
[PHP-BUG] Req #65130 [NEW]: partial XP support
From: qtantofaz at hotmail dot com Operating system: Windows XP PHP version: 5.5.0 Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:partial XP support Description: I run Windows XP. When I replace PHP 5.3 with 5.5, PHP gives a Server Error. This is probably intended because officially support for XP has ended. BUT: lots of people in Africa and elsewhere use still use XP extensively. And.. I presume the core isn't OS-dependent, but many libraries are. So.. why deprecate ALL of XP? Just document which libraries need something better than XP. If the core works, anyone using XP can still run with a subset of the libraries (or none at all). Which is undoubtedly sufficient for most users (developers)! -- Edit bug report at https://bugs.php.net/bug.php?id=65130&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65130&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65130&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65130&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65130&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65130&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65130&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65130&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65130&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65130&r=support Expected behavior: https://bugs.php.net/fix.php?id=65130&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65130&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65130&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65130&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65130&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65130&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65130&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65130&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65130&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65130&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65130&r=mysqlcfg
Bug #65128 [Opn->Fbk]: undefined reference to `curl_easy_(un)escape'
Edit report at https://bugs.php.net/bug.php?id=65128&edit=1 ID: 65128 Updated by: fel...@php.net Reported by:a178235 at yahoo dot com Summary:undefined reference to `curl_easy_(un)escape' -Status: Open +Status: Feedback Type: Bug Package:cURL related Operating System: Linux 2.6.18-348.6.1.el5PAE PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Hmm, it seems there's some messy about different version on build. Check out the libcurl version on config.log.(`cat config.log | grep -i libcurl`) Previous Comments: [2013-06-26 00:43:00] a178235 at yahoo dot com /usr/include/curl/curlver.h #define LIBCURL_VERSION "7.15.5" [2013-06-26 00:39:46] a178235 at yahoo dot com -bash-3.2$ curl-config --version libcurl 7.15.0 [2013-06-25 23:57:39] fel...@php.net What's the libcurl version are you using? [2013-06-25 23:52:47] a178235 at yahoo dot com Description: ext/curl/.libs/interface.o: In function `zif_curl_unescape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined reference to `curl_easy_unescape' ext/curl/.libs/interface.o: In function `zif_curl_escape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined reference to `curl_easy_escape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Test script: --- tar -xf php-5.5.0.tar.gz cd php-5.5.0/ ./configure --prefix=$HOME --with-curl make -- Edit this bug report at https://bugs.php.net/bug.php?id=65128&edit=1
Bug #65128 [Opn]: undefined reference to `curl_easy_(un)escape'
Edit report at https://bugs.php.net/bug.php?id=65128&edit=1 ID: 65128 User updated by:a178235 at yahoo dot com Reported by:a178235 at yahoo dot com Summary:undefined reference to `curl_easy_(un)escape' Status: Open Type: Bug Package:cURL related Operating System: Linux 2.6.18-348.6.1.el5PAE PHP Version:5.5.0 Block user comment: N Private report: N New Comment: /usr/include/curl/curlver.h #define LIBCURL_VERSION "7.15.5" Previous Comments: [2013-06-26 00:39:46] a178235 at yahoo dot com -bash-3.2$ curl-config --version libcurl 7.15.0 [2013-06-25 23:57:39] fel...@php.net What's the libcurl version are you using? [2013-06-25 23:52:47] a178235 at yahoo dot com Description: ext/curl/.libs/interface.o: In function `zif_curl_unescape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined reference to `curl_easy_unescape' ext/curl/.libs/interface.o: In function `zif_curl_escape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined reference to `curl_easy_escape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Test script: --- tar -xf php-5.5.0.tar.gz cd php-5.5.0/ ./configure --prefix=$HOME --with-curl make -- Edit this bug report at https://bugs.php.net/bug.php?id=65128&edit=1
Bug #62475 [Opn->Csd]: variant_* functions causes crash when null given as an argument
Edit report at https://bugs.php.net/bug.php?id=62475&edit=1
ID: 62475
Updated by: fel...@php.net
Reported by:deadb17ch at gmail dot com
Summary:variant_* functions causes crash when null given as
an argument
-Status: Open
+Status: Closed
Type: Bug
Package:COM related
Operating System: Windows XP SP3
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of felipe...@gmail.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=42896968282a607a26e4aa152d3c8dc90dad5826
Log: - Fixed bug #62475 (variant_* functions causes crash when null given as an
argument)
Previous Comments:
[2013-02-20 11:42:13] user at kkdf2 dot sakura dot ne dot jp
z is NULL, and then Z_TYPE_P(z) gets access violation, because
zend_parse_parameters eats "z!z!". It may be safe with "zz".
---
PHP_COM_DOTNET_API void php_com_variant_from_zval(VARIANT *v, zval *z, int
codepage TSRMLS_DC)
{
OLECHAR *olestring;
php_com_dotnet_object *obj;
switch (Z_TYPE_P(z)) {
case IS_NULL:
V_VT(v) = VT_NULL;
break;
---
[2012-07-03 20:56:12] deadb17ch at gmail dot com
Description:
As we can read in the php manual :
"As with all the variant arithmetic functions, the parameters for this function
can be either a PHP native type (integer, string, floating point, boolean or
NULL), or an instance of a COM, VARIANT or DOTNET class. "
but actuall php instance crashes when we give NULL as first or second argument
to some of the functions from variant_* familly.
Thoes functions are:
variant_neg
variant_pow
variant_cat
variant_div
variant_fix
variant_idiv
variant_imp
variant_int
variant_mod
variant_mul
variant_neg
variant_not
variant_rount
variant_set
variant_sub
variant_xor
variant_or
variant_eqv
variant_cmp
variant_abs
variant_and
Test script:
---
Expected result:
nothing happens or an error occurs
Actual result:
--
crash
eax= ebx=01250080 ecx=00c0fac8 edx=1039bac6 esi= edi=00c0fac8
eip=100f4036 esp=00c0fa90 ebp=02296f08 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=00200246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\\xampp\\php\\php5ts.dll -
php5ts!php_com_variant_from_zval+0x6:
100f4036 0fb6460cmovzx eax,byte ptr [esi+0Ch] ds:0023:000c=??
--
Edit this bug report at https://bugs.php.net/bug.php?id=62475&edit=1
Bug #65128 [Fbk->Opn]: undefined reference to `curl_easy_(un)escape'
Edit report at https://bugs.php.net/bug.php?id=65128&edit=1 ID: 65128 User updated by:a178235 at yahoo dot com Reported by:a178235 at yahoo dot com Summary:undefined reference to `curl_easy_(un)escape' -Status: Feedback +Status: Open Type: Bug Package:cURL related Operating System: Linux 2.6.18-348.6.1.el5PAE PHP Version:5.5.0 Block user comment: N Private report: N New Comment: -bash-3.2$ curl-config --version libcurl 7.15.0 Previous Comments: [2013-06-25 23:57:39] fel...@php.net What's the libcurl version are you using? [2013-06-25 23:52:47] a178235 at yahoo dot com Description: ext/curl/.libs/interface.o: In function `zif_curl_unescape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined reference to `curl_easy_unescape' ext/curl/.libs/interface.o: In function `zif_curl_escape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined reference to `curl_easy_escape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Test script: --- tar -xf php-5.5.0.tar.gz cd php-5.5.0/ ./configure --prefix=$HOME --with-curl make -- Edit this bug report at https://bugs.php.net/bug.php?id=65128&edit=1
Bug #61547 [Opn->Fbk]: session.progress
Edit report at https://bugs.php.net/bug.php?id=61547&edit=1
ID: 61547
Updated by: fel...@php.net
Reported by:info at sperlingprog dot com
Summary:session.progress
-Status: Open
+Status: Feedback
Type: Bug
Package:Session related
Operating System: Windows
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Have you figured what was going wrong there?
Previous Comments:
[2012-03-28 19:30:08] info at sperlingprog dot com
Description:
---
>From manual page: http://www.php.net/session.upload-progress
---
there are no session data for upload infos in the session on windows
i have test is on 3 windows systems
all php.ini settings are ok.
upload ok session progress is empty.
$_SESSION = empty!!
Greetings steffen
Test script:
---
session_start();
$key = ini_get("session.upload_progress.prefix") . "myForm";
if (!empty($_SESSION[$key]))
{
$current = $_SESSION[$key]["bytes_processed"];
$total = $_SESSION[$key]["content_length"];
echo $current < $total ? ceil($current / $total * 100) : 100;
}
else
{
echo " PHP_VERSION: " . PHP_VERSION ." " . date("H:m:s") . "key:
$key";
var_dump($_SESSION);
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61547&edit=1
Bug #62672 [Opn->Csd]: Error on serialize of ArrayObject
Edit report at https://bugs.php.net/bug.php?id=62672&edit=1
ID: 62672
Updated by: fel...@php.net
Reported by:t dot weber at interexa dot de
Summary:Error on serialize of ArrayObject
-Status: Open
+Status: Closed
Type: Bug
Package:SPL related
Operating System: Cent OS
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of felipe...@gmail.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=04db57066deb73ef9c960a2c5bebad49195bc1bb
Log: - Fixed bug #62672 (Error on serialize of ArrayObject) patch by: lior dot
k at zend dot com
Previous Comments:
[2012-11-25 11:16:18] lior dot k at zend dot com
ping ?
[2012-08-05 12:56:09] lior dot k at zend dot com
Please see the attached patch by Yoram Bar-Haim
[2012-07-27 16:08:41] j dot henge-ernst at interexa dot de
The problem is that the unserialize of ArrayIterator (and also maybe
ArrayObject or other SPL classes) can not dereference object references.
A simpler Testcase:
getIterator());
$s = serialize($t);
$e = unserialize($s);
Fatal error: Uncaught exception 'UnexpectedValueException' with message 'Error
at offset 13 of 26 bytes' in /tmp/test2.php:5
Stack trace:
#0 [internal function]: ArrayIterator->unserialize('x:i:16777216;r:...')
#1 /tmp/test2.php(5): unserialize('a:2:{i:0;C:11:"...')
#2 {main}
thrown in /tmp/test2.php on line 5
If the order in the array is reversed it works, as now the ArrayObject is only
a reference in the array.
Same behaviour with PHP 5.4.5
[2012-07-27 11:04:48] t dot weber at interexa dot de
Description:
Serialize and direct unserialize of Objects does not work if return value of
ArrayObject::getIterator is contained in parent class (see Test script)
Test script:
---
class ObjA
{
private $_varA;
public function __construct(Iterator $source)
{
$this->_varA = $source;
}
}
class ObjB extends ObjA
{
private $_varB;
public function __construct(ArrayObject $keys)
{
$this->_varB = $keys;
parent::__construct($keys->getIterator());
}
}
$obj = new ObjB(new ArrayObject());
unserialize(serialize($obj));
--
Edit this bug report at https://bugs.php.net/bug.php?id=62672&edit=1
Bug #65128 [Opn->Fbk]: undefined reference to `curl_easy_(un)escape'
Edit report at https://bugs.php.net/bug.php?id=65128&edit=1 ID: 65128 Updated by: fel...@php.net Reported by:a178235 at yahoo dot com Summary:undefined reference to `curl_easy_(un)escape' -Status: Open +Status: Feedback Type: Bug Package:cURL related Operating System: Linux 2.6.18-348.6.1.el5PAE PHP Version:5.5.0 Block user comment: N Private report: N New Comment: What's the libcurl version are you using? Previous Comments: [2013-06-25 23:52:47] a178235 at yahoo dot com Description: ext/curl/.libs/interface.o: In function `zif_curl_unescape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined reference to `curl_easy_unescape' ext/curl/.libs/interface.o: In function `zif_curl_escape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined reference to `curl_easy_escape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Test script: --- tar -xf php-5.5.0.tar.gz cd php-5.5.0/ ./configure --prefix=$HOME --with-curl make -- Edit this bug report at https://bugs.php.net/bug.php?id=65128&edit=1
[PHP-BUG] Bug #65128 [NEW]: undefined reference to `curl_easy_(un)escape'
From: a178235 at yahoo dot com Operating system: Linux 2.6.18-348.6.1.el5PAE PHP version: 5.5.0 Package: cURL related Bug Type: Bug Bug description:undefined reference to `curl_easy_(un)escape' Description: ext/curl/.libs/interface.o: In function `zif_curl_unescape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined reference to `curl_easy_unescape' ext/curl/.libs/interface.o: In function `zif_curl_escape': /ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined reference to `curl_easy_escape' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Test script: --- tar -xf php-5.5.0.tar.gz cd php-5.5.0/ ./configure --prefix=$HOME --with-curl make -- Edit bug report at https://bugs.php.net/bug.php?id=65128&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65128&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65128&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65128&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65128&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65128&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65128&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65128&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65128&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65128&r=support Expected behavior: https://bugs.php.net/fix.php?id=65128&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65128&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65128&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65128&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65128&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65128&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65128&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65128&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65128&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65128&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65128&r=mysqlcfg
Bug #65120 [Fbk->Opn]: fpm build fails on ppc: #error Unsupported processor
Edit report at https://bugs.php.net/bug.php?id=65120&edit=1 ID: 65120 User updated by:php-bugs-2013 at ryandesign dot com Reported by:php-bugs-2013 at ryandesign dot com Summary:fpm build fails on ppc: #error Unsupported processor -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: Mac OS X 10.5.8 PHP Version:5.5.0 Block user comment: N Private report: N New Comment: I am not a C programmer and I'm not familiar with your code, so I'm probably not the best candidate to fix this. Previous Comments: [2013-06-25 15:56:54] fel...@php.net Can you provide a patch that works on such architecture? [2013-06-25 08:55:27] php-bugs-2013 at ryandesign dot com Description: Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling with Apple's gcc 4.0.1 which comes with Xcode, with the following error: :info:build /bin/sh /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps -- mode=compile /usr/bin/gcc-4.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/main - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/date/lib - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex - I/Volumes/Data/macports/leopard/include/libxml2 - I/Volumes/Data/macports/leopard/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/TSRM - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/Zend - I/Volumes/Data/macports/leopard/include -no-cpp-precomp -pipe -O2 -arch ppc - fvisibility=hidden -c /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo :info:build In file included from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15, :info:build from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21: :info:build /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). Previous bug reports about fpm sapi build failure on PowerPC or POWER processors include #51214 (closed as not a bug because fpm wasn't part of php at that time); #51772 (closed as no feedback; there was a patch attached but someone said it was unstable); #54273 (closed as won't fix because the person handling the bug had no access to PowerPC equipment). -- Edit this bug report at https://bugs.php.net/bug.php?id=65120&edit=1
Bug #62964 [Opn->Csd]: Cross-Site Scripting
Edit report at https://bugs.php.net/bug.php?id=62964&edit=1
ID: 62964
Updated by: fel...@php.net
Reported by:ymaryshev at ptsecurity dot ru
Summary:Cross-Site Scripting
-Status: Open
+Status: Closed
Type: Bug
Package:*General Issues
Operating System: win
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of felipe...@gmail.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=41b73e4cee9ce68b8b78a00eddd4322b0d48dd06
Log: - Fixed bug #62964 (Possible XSS on "Registered stream filters"
info) patch by: david at nnucomputerwhiz dot com
Previous Comments:
[2012-09-14 05:59:28] david at nnucomputerwhiz dot com
Added patch. It's a really simple change to use php_info_print_html_esc when
appropriate. We do the same thing with other functions like
php_print_gpcse_array()
[2012-09-14 05:35:31] david at nnucomputerwhiz dot com
I can't imagine this bug ever causing any real security problems but whenever
outputting anything to the browser that could contain html entities they should
be encoded. So php_info_print should probably be modified to use htmlentities
so
if it ever tried to print a '&' or '<' to the browser it will be displayed
properly.
[2012-09-01 17:18:40] zyss at mail dot zp dot ua
Unfortunately most of PHP output functions are vulnerable in the same way...
For example, built-in echo function:
$a = "alert('Positive')";
echo $a; // echo IS VULNERABLE!!!11oneoneeleven
Seriously, healthy programmer never allows untrusted data (user input) to be
passed to stream_filter_register() as well as to other functions.
Moreover, phpinfo() should never be exposed.
[2012-08-29 12:06:08] ymaryshev at ptsecurity dot ru
Description:
An attacker can conduct cross-site scripting attack because of incorrect
implementation of php_info_print_stream_hash function in phpinfo in PHP.
Vulnerability exists in /ext/sqlite3/ info.c file. Here is the vulnerable code:
static void php_info_print_stream_hash(const char *name, HashTable *ht
TSRMLS_DC)
/* {{{ */ {
...
while (zend_hash_get_current_key_ex(ht, &key, &len,
NULL,
0, &pos) == HASH_KEY_IS_STRING)
{
php_info_print(key);
...
Test script:
---
alert('Positive')","a");
phpinfo();
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=62964&edit=1
Bug #62345 [Opn->Csd]: Misspelling of Occurred
Edit report at https://bugs.php.net/bug.php?id=62345&edit=1 ID: 62345 Updated by: fel...@php.net Reported by:marc at easen dot co dot uk Summary:Misspelling of Occurred -Status: Open +Status: Closed Type: Bug Package:Unknown/Other Function Operating System: All PHP Version:Irrelevant -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: Such typos has been already fixed. Thanks. Previous Comments: [2012-06-17 19:26:55] marc at easen dot co dot uk Description: There are quite a few occurrences where the word 'occurred' is spelt incorrect https://github.com/php/php-src/pull/104/files -- Edit this bug report at https://bugs.php.net/bug.php?id=62345&edit=1
Bug #60803 [Opn->Fbk]: pdo-oci configuring bug
Edit report at https://bugs.php.net/bug.php?id=60803&edit=1 ID: 60803 Updated by: fel...@php.net Reported by:gureedo at gmail dot com Summary:pdo-oci configuring bug -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: linux x86-64 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: Still you facing such a problem? Previous Comments: [2012-01-19 12:00:43] gureedo at gmail dot com Description: This bug is regression from this bug solution: https://bugs.php.net/bug.php?id=44989 And same bug on gentoo site: https://bugs.gentoo.org/show_bug.cgi?id=380581 I've attached patch that searches for instant client in both oracle and orace64 dirs. -- Edit this bug report at https://bugs.php.net/bug.php?id=60803&edit=1
Bug #60732 [Opn->Csd]: php_error_docref links to invalid pages
Edit report at https://bugs.php.net/bug.php?id=60732&edit=1
ID: 60732
Updated by: fel...@php.net
Reported by:vr...@php.net
Summary:php_error_docref links to invalid pages
-Status: Open
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.4SVN-2012-01-12 (SVN)
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of felipe...@gmail.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=6ba93a4bae355ac1d247d1e474381bb92d1eb038
Log: - Fixed bug #60732 (php_error_docref links to invalid pages) patch by:
Jakub Vrana
Previous Comments:
[2012-01-12 17:22:43] vr...@php.net
The following patch has been added/updated:
Patch Name: php_error_docref-strip-leading-dashes
Revision: 1326388963
URL:
https://bugs.php.net/patch-display.php?bug=60732&patch=php_error_docref-strip-leading-dashes&revision=1326388963
[2012-01-12 17:18:05] vr...@php.net
Description:
Links to PHP Manual generated in case of an error are wrong if the function or
method begins by __.
Test script:
---
try {
new DateTimeZone("x");
} catch (Exception $e) {
echo $e->getMessage();
}
Expected result:
DateTimeZone::__construct() [datetimezone.construct.php]: Unknown or bad
timezone (x)
Actual result:
--
DateTimeZone::__construct() [datetimezone.--construct.php]: Unknown or bad
timezone (x)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60732&edit=1
Bug #65116 [Csd->Nab]: fgets() fails to return newline at end of string
Edit report at https://bugs.php.net/bug.php?id=65116&edit=1
ID: 65116
Updated by: s...@php.net
Reported by:strideroflands at yahoo dot com
Summary:fgets() fails to return newline at end of string
-Status: Closed
+Status: Not a bug
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.16
Assigned To:ab
Block user comment: N
Private report: N
Previous Comments:
[2013-06-25 06:40:43] strideroflands at yahoo dot com
sorry. it is keeping the newline as expected after all. please delete this
bug.
[2013-06-25 04:10:16] strideroflands at yahoo dot com
Description:
---
>From manual page: http://www.php.net/function.fgets
---
In "C" programming, the function fgets() returns the end of line character at
the end of the string. The description of stream_get_line says
"This function is nearly identical to fgets() except in that it allows end of
line delimiters other than the standard \n, \r, and \r\n, and does not return
the delimiter itself."
This suggests that fgets() should indeed return a newline character. Such
functionality would be very useful. In "C", fgets(fp) is known to be a known
source of bugs, since it overwrites memory buffers when the line is longer than
intended. In PHP, fgets() allows an additional parameter to limit the size of
a buffer it can fill. If fgets() does not return a newline if it reaches one,
how are we supposed to know if it reached the end of the "length" parameter, or
if it reached a newline?
In the test script, it can report if a line is longer than expected only if the
newline is returned. However, this does not happen. The only way to know if
this happened would be 1) write your own fgets() function, 2) see if you are at
the end of the file, use ftell to determine the position, read a byte, seek to
the position ftell just reported, and test on the byte. This is more laborious
than the simple test for a newline below. The lack of returning the newline
effectively obviates the usefulness of the "length" parameter. If one were to
encounter a large video file, e.g., the whole thing might be read into memory,
and there would be no convenient way to detect it.
I generally detest any changes that break existing code by changing the
language. Therefore, I suggest making another function that won't be giving
existing applications newline characters they didn't have before; or else
having a variable that you set to make fgets() return newlines like it should.
This is actually vers. 5.4.15.
Test script:
---
$hndl = fopen("aFileWithNewlines.txt", "r+");
$line= fgets ($hndl,80);
if (strpos($line,"\n")==false)
echo "error";
else
echo "no error";
Expected result:
"error" if the line is longer than 80 characters, otherwise, "no error".
Actual result:
--
always "error"
--
Edit this bug report at https://bugs.php.net/bug.php?id=65116&edit=1
Bug #54428 [Opn->Fbk]: [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed!
Edit report at https://bugs.php.net/bug.php?id=54428&edit=1 ID: 54428 Updated by: fel...@php.net Reported by:hoangvu4000 at gmail dot com Summary:[function.imagecreatefromjpeg]: failed to open stream: HTTP request failed! -Status: Open +Status: Feedback Type: Bug Package:GD related Operating System: Windows 7 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: What if you supply an url encoded one? Previous Comments: [2011-03-31 04:29:30] hoangvu4000 at gmail dot com Description: --- >From manual page: http://www.php.net/function.imagecreatefromjpeg#Description --- Warning: imagecreatefromjpeg(http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg) [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/thegioitru/domains/thegioitruyentranh.vn/public_html/z/facebook.php on line 39 Every things are OK if the URL don't have any space, Ext: imagecreatefromjpeg(http://acb.com/PhotoImages.jpg) ==> OK But: imagecreatefromjpeg(http://acb.com/Photo Images.jpg) ==> "failed to open stream: HTTP request failed!" (have one space in "Photo" & "Images") we get images form orther host, so we can rename the suorce images, How we can get it with imagecreatefromjpeg. if this is Bug, please fix it. Thank! Test script: --- //return: OK //$up_file = "http://truyentranhtuan.com/IMAGES/MANGA/Kimi_ni_Todoke/034/01.JPG";; // return: "failed to open stream: HTTP request failed!" $up_file = "http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg"; $new_image=imagecreatefromjpeg($up_file); Expected result: Warning: imagecreatefromjpeg(http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg) [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/thegioitru/domains/thegioitruyentranh.vn/public_html/z/facebook.php on line 39 -- Edit this bug report at https://bugs.php.net/bug.php?id=54428&edit=1
Bug #53442 [Opn]: [fix provided] configure --with-iconv=DIR fails due to two faulty tests
Edit report at https://bugs.php.net/bug.php?id=53442&edit=1 ID: 53442 Updated by: fel...@php.net Reported by:fransmeulenbroeks at gmail dot com Summary:[fix provided] configure --with-iconv=DIR fails due to two faulty tests Status: Open Type: Bug Package:Compile Failure Operating System: linux PHP Version:5.2SVN-2010-12-01 (snap) Block user comment: N Private report: N New Comment: There is a check right after what you have quoted which handles the supplied path. ... dnl dnl Check external libs for iconv funcs dnl if test "$found_iconv" = "no"; then for i in $PHP_ICONV /usr/local /usr; do ... Previous Comments: [2010-12-01 23:10:25] fransmeulenbroeks at gmail dot com oh and the subject line is wrong this reports and fixes only one faulty test, the other one is reported and fixed in 53443 [2010-12-01 23:09:00] fransmeulenbroeks at gmail dot com oops, made typo in patch This line: + if test "$PHP_ICONV" != no"; then is missing a " and must read + if test "$PHP_ICONV" != "no"; then Uploaded a new patch. Sorry for any inconvenience! [2010-12-01 22:50:49] fransmeulenbroeks at gmail dot com Description: when trying to cross-compile configure picked up the host iconv, not the target one, resulting in wrong paths later on and configure failing. configure was called with configure --with-iconv=DIR (where DIR is the dir to find the iconv stuff). This fails at two places. First one is due to a faulty test in acinclude.m4 It tests PHP_ICONV against "yes". However PHP_ICONV in my case contains the path so we should test against not "no" (PHP_ICONV can be a dir because otherwise this code later on would not make any sense: for i in $PHP_ICONV /usr/local /usr; do ) The following patch is for 5.2.13, but I have verified it is also in the 5.2 snap from today. Index: php-5.2.13/acinclude.m4 === --- php-5.2.13.orig/acinclude.m4 +++ php-5.2.13/acinclude.m4 @@ -2430,7 +2430,8 @@ AC_DEFUN([PHP_SETUP_ICONV], [ dnl dnl Check libc first if no path is provided in --with-iconv dnl - if test "$PHP_ICONV" = "yes"; then + dnl must check against no, not against yes as PHP_ICONV can also include a path, which implies yes + if test "$PHP_ICONV" != no"; then AC_CHECK_FUNC(iconv, [ found_iconv=yes ],[ -- Edit this bug report at https://bugs.php.net/bug.php?id=53442&edit=1
Bug #53156 [Opn->Asn]: imagerectangle problem with point ordering
Edit report at https://bugs.php.net/bug.php?id=53156&edit=1 ID: 53156 Updated by: fel...@php.net Reported by:ljb9832 at pobox dot com Summary:imagerectangle problem with point ordering -Status: Open +Status: Assigned Type: Bug Package:GD related Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N New Comment: What do you think about, Pierre? Previous Comments: [2010-10-25 21:50:51] ljb9832 at pobox dot com Description: The documentation says imagerectangle() requires the upper left point first, then the lower right, whereas imagefilledrectangle() accepts the points in any order. In fact, imagerectangle() does work with all 4 possible orderings of the points, but only when drawing with unit thickness. When drawing rectangles with thickness > 1, only 2 of the 4 cases work. Before marking this as "working as documented" (which it is), please consider that there seems to be incorrect logic in gdImageRectangle() when handling the points. It tests for y2https://bugs.php.net/bug.php?id=53156&edit=1
Bug #65125 [Fbk]: On running PHP scipt using PDO server for db execution, it crashes apache
Edit report at https://bugs.php.net/bug.php?id=65125&edit=1 ID: 65125 Updated by: a...@php.net Reported by:lavesh626 at gmail dot com Summary:On running PHP scipt using PDO server for db execution, it crashes apache Status: Feedback Type: Bug Package:Apache related Operating System: Windows server 2008 R2 PHP Version:5.4Git-2013-06-25 (Git) Block user comment: N Private report: N New Comment: Please retry using apache from http://www.apachelounge.com/ and an official PHP build. If you get the same crash, please extract the reproduce code and follow the instructions on this page to produce a backtrace https://bugs.php.net/bugs- generating-backtrace-win32.php . Previous Comments: [2013-06-25 15:49:50] larue...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2013-06-25 15:11:37] lavesh626 at gmail dot com Description: I am running a php script which executes stored procedures using pdo driver for ms sql server 2008. Sometimes the script executes perfectly while sometimes it crashes the server. Velow is the eroor as in event view Faulting application name: httpd.exe, version: 2.4.3.0, time stamp: 0x502f70a3 Faulting module name: php5ts.dll, version: 5.4.7.0, time stamp: 0x505114f8 Exception code: 0xc005 Fault offset: 0x0005cfc7 Faulting process id: 0x117c Faulting application start time: 0x01ce71ad20bc08f7 Faulting application path: C:\xampp\apache\bin\httpd.exe Faulting module path: C:\xampp\php\php5ts.dll Report Id: 8c31acd1-dda0-11e2-9540-8b5a486c809c -- Edit this bug report at https://bugs.php.net/bug.php?id=65125&edit=1
Bug #65120 [Opn->Fbk]: fpm build fails on ppc: #error Unsupported processor
Edit report at https://bugs.php.net/bug.php?id=65120&edit=1 ID: 65120 Updated by: fel...@php.net Reported by:php-bugs-2013 at ryandesign dot com Summary:fpm build fails on ppc: #error Unsupported processor -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Mac OS X 10.5.8 PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Can you provide a patch that works on such architecture? Previous Comments: [2013-06-25 08:55:27] php-bugs-2013 at ryandesign dot com Description: Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling with Apple's gcc 4.0.1 which comes with Xcode, with the following error: :info:build /bin/sh /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps -- mode=compile /usr/bin/gcc-4.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/main - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/date/lib - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex - I/Volumes/Data/macports/leopard/include/libxml2 - I/Volumes/Data/macports/leopard/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/TSRM - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/Zend - I/Volumes/Data/macports/leopard/include -no-cpp-precomp -pipe -O2 -arch ppc - fvisibility=hidden -c /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo :info:build In file included from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15, :info:build from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21: :info:build /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). Previous bug reports about fpm sapi build failure on PowerPC or POWER processors include #51214 (closed as not a bug because fpm wasn't part of php at that time); #51772 (closed as no feedback; there was a patch attached but someone said it was unstable); #54273 (closed as won't fix because the person handling the bug had no access to PowerPC equipment). -- Edit this bug report at https://bugs.php.net/bug.php?id=65120&edit=1
Bug #65125 [Opn->Fbk]: On running PHP scipt using PDO server for db execution, it crashes apache
Edit report at https://bugs.php.net/bug.php?id=65125&edit=1 ID: 65125 Updated by: larue...@php.net Reported by:lavesh626 at gmail dot com Summary:On running PHP scipt using PDO server for db execution, it crashes apache -Status: Open +Status: Feedback Type: Bug Package:Apache related Operating System: Windows server 2008 R2 PHP Version:5.4Git-2013-06-25 (Git) Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2013-06-25 15:11:37] lavesh626 at gmail dot com Description: I am running a php script which executes stored procedures using pdo driver for ms sql server 2008. Sometimes the script executes perfectly while sometimes it crashes the server. Velow is the eroor as in event view Faulting application name: httpd.exe, version: 2.4.3.0, time stamp: 0x502f70a3 Faulting module name: php5ts.dll, version: 5.4.7.0, time stamp: 0x505114f8 Exception code: 0xc005 Fault offset: 0x0005cfc7 Faulting process id: 0x117c Faulting application start time: 0x01ce71ad20bc08f7 Faulting application path: C:\xampp\apache\bin\httpd.exe Faulting module path: C:\xampp\php\php5ts.dll Report Id: 8c31acd1-dda0-11e2-9540-8b5a486c809c -- Edit this bug report at https://bugs.php.net/bug.php?id=65125&edit=1
Bug #65111 [Asn->Nab]: Calling traits directly with static properties/methods
Edit report at https://bugs.php.net/bug.php?id=65111&edit=1 ID: 65111 Updated by: fel...@php.net Reported by:ryan dot brothers at gmail dot com Summary:Calling traits directly with static properties/methods -Status: Assigned +Status: Not a bug Type: Bug Package:Class/Object related Operating System: Linux PHP Version:5.5.0 -Assigned To:gron +Assigned To: Block user comment: N Private report: N New Comment: Thanks for explaining it. Previous Comments: [2013-06-25 07:19:04] g...@php.net Yes, traits are not supposed to be instantiated. However, this behavior is not really related to instantiation. Traits are still a lexical entity, i.e., a programming language entity that provides a lexical scope when defined. Since PHP allows us to define functions in such scopes, we can define also static methods on traits. The way to avoid that would be to change the grammar for traits. I decided to not do that back in the day. And I still feel that it is unclear whether it would be conceptually cleaner if it is not possible to defined static state/methods. So, I would leave it as it is. Except, someone comes up with a good reason to change it. But it would also be quite a bit of a BC issue. [2013-06-25 04:30:41] larue...@php.net hmm, trait is actually a class in php, I have a quick look into this.. changing this will needs a significant works.. actually, the is_callable / do_call alreay is a little mess now. I mean the codes [2013-06-24 16:52:52] ryan dot brothers at gmail dot com Description: The documentation for traits indicates that "it is not possible to instantiate a Trait on its own", but I have noticed that a trait can be called directly if it has a static property or method, as per the below example. Is this intended behavior? Or should traits be restricted from being called directly? I was under the impression that traits cannot be called directly per the documentation. If not, is there a way to prevent traits from being called directly as in the below example? Test script: --- https://bugs.php.net/bug.php?id=65111&edit=1
[PHP-BUG] Bug #65125 [NEW]: On running PHP scipt using PDO server for db execution, it crashes apache
From: lavesh626 at gmail dot com Operating system: Windows server 2008 R2 PHP version: 5.4Git-2013-06-25 (Git) Package: Apache related Bug Type: Bug Bug description:On running PHP scipt using PDO server for db execution, it crashes apache Description: I am running a php script which executes stored procedures using pdo driver for ms sql server 2008. Sometimes the script executes perfectly while sometimes it crashes the server. Velow is the eroor as in event view Faulting application name: httpd.exe, version: 2.4.3.0, time stamp: 0x502f70a3 Faulting module name: php5ts.dll, version: 5.4.7.0, time stamp: 0x505114f8 Exception code: 0xc005 Fault offset: 0x0005cfc7 Faulting process id: 0x117c Faulting application start time: 0x01ce71ad20bc08f7 Faulting application path: C:\xampp\apache\bin\httpd.exe Faulting module path: C:\xampp\php\php5ts.dll Report Id: 8c31acd1-dda0-11e2-9540-8b5a486c809c -- Edit bug report at https://bugs.php.net/bug.php?id=65125&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65125&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65125&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65125&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65125&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65125&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65125&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65125&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65125&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65125&r=support Expected behavior: https://bugs.php.net/fix.php?id=65125&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65125&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65125&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65125&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65125&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65125&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65125&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65125&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65125&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65125&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65125&r=mysqlcfg
[PHP-BUG] Bug #65124 [NEW]: SYBASE_CT_SHARED_LIBADD knob has -L after the -l
From: mi+php at aldan dot algebra dot com Operating system: Solaris PHP version: 5.4.16 Package: Sybase-ct (ctlib) related Bug Type: Bug Bug description:SYBASE_CT_SHARED_LIBADD knob has -L after the -l Description: Unlike all other *_LIBADD knobs generated by configure, the SYBASE_CT_SHARED_LIBADD lists the directory after the libraries: SYBASE_CT_SHARED_LIBADD = -lsybtcl -lsybintl -lsybcomn -lsybct -lsybcs -L/foo/bar/OCS-15_0/lib this prevents the linker from finding the libraries -- at least, on Solaris. The above line should read: SYBASE_CT_SHARED_LIBADD = -L/foo/bar/OCS-15_0/lib -lsybtcl -lsybintl -lsybcomn -lsybct -lsybcs I'm munging the generated Makefile here after the configure-run, but the proper fix would, likely, involve fixing the ext/sybase_ct/config.m4 Test script: --- Run configure with a valid --with-sybase-ct= setting. Grep the generated Makefile for ^SYBASE_CT_SHARED_LIBADD. -- Edit bug report at https://bugs.php.net/bug.php?id=65124&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65124&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65124&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65124&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65124&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65124&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65124&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65124&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65124&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65124&r=support Expected behavior: https://bugs.php.net/fix.php?id=65124&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65124&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65124&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65124&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65124&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65124&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65124&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65124&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65124&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65124&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65124&r=mysqlcfg
Bug #65115 [Nab]: flush() disables compression from ob_gzhandler
Edit report at https://bugs.php.net/bug.php?id=65115&edit=1 ID: 65115 Updated by: m...@php.net Reported by:preinhei...@php.net Summary:flush() disables compression from ob_gzhandler Status: Not a bug Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.16 Assigned To:mike Block user comment: N Private report: N New Comment: Ok, my explanation pretty much applies to the Apache SAPI. Due to premature flush()'ing the ob_gzhandler cannot set its headers anymore when it's actually run. Previous Comments: [2013-06-25 13:56:15] preinhei...@php.net I'm using the apache 2.0 SAPI. The build of PHP I used to confirm the bug doesn't include XHProf (I wanted a clean build to report on). I built with: Command './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql=mysqlnd' '--with-gd' '--enable-soap' '--with-libxml-dir=/usr/lib/' '--with-mysql-sock=/tmp' '--with-tidy' '--with-jpeg-dir=/usr/lib/' '--with-xsl' '--with-curl' '--with-zlib' '--enable-gd-native-ttf' '--with-openssl' '--with-mcrypt' '--with-pdo-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-bz2' '--enable-bcmath' [2013-06-25 13:49:38] m...@php.net Looks like my explanation off the top of my head was not correct. Which SAPI are you using? Does XHPROF override SAPI methods? [2013-06-25 12:33:48] preinhei...@php.net So if I run: http://test.local/obtest.php It looks (to me) like the entire output is compressed. The difference in behavior seems, well, necessary to allow the end agent to actually be able to read the output. But confusing from a "different output depending on what happened earlier" standpoint. [2013-06-25 05:30:36] m...@php.net Actually, this is debatable. Flush flushes the SAPI's I/O layer and we just note that output has irreversibly sent. If you want to flush the output buffering layer you have to use ob_flush prior flush. [2013-06-25 04:32:20] larue...@php.net I encountered this problem too. a workaround is don't use php's gzip handler, use the webserver's 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=65115 -- Edit this bug report at https://bugs.php.net/bug.php?id=65115&edit=1
Bug #65115 [Com]: flush() disables compression from ob_gzhandler
Edit report at https://bugs.php.net/bug.php?id=65115&edit=1 ID: 65115 Comment by: preinhei...@php.net Reported by:preinhei...@php.net Summary:flush() disables compression from ob_gzhandler Status: Not a bug Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.16 Assigned To:mike Block user comment: N Private report: N New Comment: I'm using the apache 2.0 SAPI. The build of PHP I used to confirm the bug doesn't include XHProf (I wanted a clean build to report on). I built with: Command './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql=mysqlnd' '--with-gd' '--enable-soap' '--with-libxml-dir=/usr/lib/' '--with-mysql-sock=/tmp' '--with-tidy' '--with-jpeg-dir=/usr/lib/' '--with-xsl' '--with-curl' '--with-zlib' '--enable-gd-native-ttf' '--with-openssl' '--with-mcrypt' '--with-pdo-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-bz2' '--enable-bcmath' Previous Comments: [2013-06-25 13:49:38] m...@php.net Looks like my explanation off the top of my head was not correct. Which SAPI are you using? Does XHPROF override SAPI methods? [2013-06-25 12:33:48] preinhei...@php.net So if I run: http://test.local/obtest.php It looks (to me) like the entire output is compressed. The difference in behavior seems, well, necessary to allow the end agent to actually be able to read the output. But confusing from a "different output depending on what happened earlier" standpoint. [2013-06-25 05:30:36] m...@php.net Actually, this is debatable. Flush flushes the SAPI's I/O layer and we just note that output has irreversibly sent. If you want to flush the output buffering layer you have to use ob_flush prior flush. [2013-06-25 04:32:20] larue...@php.net I encountered this problem too. a workaround is don't use php's gzip handler, use the webserver's [2013-06-24 21:08:07] preinhei...@php.net Description: Hi, Consider the test script. One might expect to see: Content-Encoding: gzip in the response headers, but it's not there. If however you comment out that flush() compression is applied. As a small amount of background, I work on two tools that help display data from the xhprof extension. They both include flush(); ignore_user_abort(); before doing work to store the profiling information in attempt to have as little impact on the user as possible. Clearly flush() wasn't the safe command I thought it was, as it's having a large affect on the application I'm profiling. I'm prepared to write this up in the documentation, but I don't really think this is expected behavior. Test script: --- https://bugs.php.net/bug.php?id=65115&edit=1
Bug #65115 [Nab]: flush() disables compression from ob_gzhandler
Edit report at https://bugs.php.net/bug.php?id=65115&edit=1 ID: 65115 Updated by: m...@php.net Reported by:preinhei...@php.net Summary:flush() disables compression from ob_gzhandler Status: Not a bug Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.16 Assigned To:mike Block user comment: N Private report: N New Comment: Looks like my explanation off the top of my head was not correct. Which SAPI are you using? Does XHPROF override SAPI methods? Previous Comments: [2013-06-25 12:33:48] preinhei...@php.net So if I run: http://test.local/obtest.php It looks (to me) like the entire output is compressed. The difference in behavior seems, well, necessary to allow the end agent to actually be able to read the output. But confusing from a "different output depending on what happened earlier" standpoint. [2013-06-25 05:30:36] m...@php.net Actually, this is debatable. Flush flushes the SAPI's I/O layer and we just note that output has irreversibly sent. If you want to flush the output buffering layer you have to use ob_flush prior flush. [2013-06-25 04:32:20] larue...@php.net I encountered this problem too. a workaround is don't use php's gzip handler, use the webserver's [2013-06-24 21:08:07] preinhei...@php.net Description: Hi, Consider the test script. One might expect to see: Content-Encoding: gzip in the response headers, but it's not there. If however you comment out that flush() compression is applied. As a small amount of background, I work on two tools that help display data from the xhprof extension. They both include flush(); ignore_user_abort(); before doing work to store the profiling information in attempt to have as little impact on the user as possible. Clearly flush() wasn't the safe command I thought it was, as it's having a large affect on the application I'm profiling. I'm prepared to write this up in the documentation, but I don't really think this is expected behavior. Test script: --- https://bugs.php.net/bug.php?id=65115&edit=1
Bug #65115 [Com]: flush() disables compression from ob_gzhandler
Edit report at https://bugs.php.net/bug.php?id=65115&edit=1 ID: 65115 Comment by: preinhei...@php.net Reported by:preinhei...@php.net Summary:flush() disables compression from ob_gzhandler Status: Not a bug Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.16 Assigned To:mike Block user comment: N Private report: N New Comment: So if I run: http://test.local/obtest.php It looks (to me) like the entire output is compressed. The difference in behavior seems, well, necessary to allow the end agent to actually be able to read the output. But confusing from a "different output depending on what happened earlier" standpoint. Previous Comments: [2013-06-25 05:30:36] m...@php.net Actually, this is debatable. Flush flushes the SAPI's I/O layer and we just note that output has irreversibly sent. If you want to flush the output buffering layer you have to use ob_flush prior flush. [2013-06-25 04:32:20] larue...@php.net I encountered this problem too. a workaround is don't use php's gzip handler, use the webserver's [2013-06-24 21:08:07] preinhei...@php.net Description: Hi, Consider the test script. One might expect to see: Content-Encoding: gzip in the response headers, but it's not there. If however you comment out that flush() compression is applied. As a small amount of background, I work on two tools that help display data from the xhprof extension. They both include flush(); ignore_user_abort(); before doing work to store the profiling information in attempt to have as little impact on the user as possible. Clearly flush() wasn't the safe command I thought it was, as it's having a large affect on the application I'm profiling. I'm prepared to write this up in the documentation, but I don't really think this is expected behavior. Test script: --- https://bugs.php.net/bug.php?id=65115&edit=1
Req #64048 [Opn->Wfx]: Case Insensitive Data In Firebird/Interbase
Edit report at https://bugs.php.net/bug.php?id=64048&edit=1 ID: 64048 Updated by: mar...@php.net Reported by:jackmason at mindspring dot com Summary:Case Insensitive Data In Firebird/Interbase -Status: Open +Status: Wont fix Type: Feature/Change Request Package:InterBase related Operating System: Linux/Windows PHP Version:5.3.21 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You need to use a Case Insensitive Collation on the server side http://www.destructor.de/firebird/caseinsensitivesearch.htm Previous Comments: [2013-03-22 13:58:44] matheus at gigatron dot com dot br What exactly is the limitation that the PDO-Firebird (or Interbase) interfaces has? What sort of query or procedure can you do on a firebird client (such as IBExpert) that you cannot do through the pdo/interbase interfaces? [2013-01-22 15:51:27] jackmason at mindspring dot com Description: Firebird/InterBase databases provide case insensitive data capabilities for both tables and queries but no such feature seems to exist in the PHP interface to either Firebird or InterBase. The data we need to access will have wide variations in uppercase and lowercase such as McGraw, Macarthur, MacArthur, Magee, MaGee as well as similar variations in data such as "the Last..." versus "The Last...", "an Invitat..." versus "An Invit..." or even "an invit..". Please provide a method of issuing a query for "McGraw" that would find "mcgraw", "Mcgraw", and "mcGraw". -- Edit this bug report at https://bugs.php.net/bug.php?id=64048&edit=1
Bug #65055 [Asn]: new Operator shuld never return a NULL new ResourceBundle
Edit report at https://bugs.php.net/bug.php?id=65055&edit=1
ID: 65055
Updated by: larue...@php.net
Reported by:goetas at lignano dot it
Summary:new Operator shuld never return a NULL new
ResourceBundle
Status: Assigned
Type: Bug
Package:I18N and L10N related
Operating System: ubuntu 12.04
PHP Version:5.4.16
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
hmm, there are also some similar cases in file info
Previous Comments:
[2013-06-25 07:06:15] goetas at lignano dot it
Similar behaviour has been verified with NumberFormatter class
[2013-06-24 03:14:19] fel...@php.net
Seems it is not the only class which has such behavior.
[2013-06-18 07:59:01] goetas at lignano dot it
Description:
sapi/cli/php -v
PHP 5.4.16 (cli) (built: Jun 18 2013 09:34:40)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
Instantiating ResourceBundle class, a "new" operator should never return null.
http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new
"To create an instance of a class, the new keyword must be used. An object will
always be created unless the object has a constructor defined that throws an
exception on error."
This behaviour it's also verified by Symfony team
https://github.com/symfony/Intl/blob/master/ResourceBundle/Reader/BinaryBundleReader.php
Test script:
---
sapi/cli/php -r 'var_dump(new \ResourceBundle("ANY WRONG PATH", "it"));'
Expected result:
Thrown some exception
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=65055&edit=1
Req #65122 [Opn->Fbk]: Class DOTNET not found with PHP 5.4.7
Edit report at https://bugs.php.net/bug.php?id=65122&edit=1 ID: 65122 Updated by: a...@php.net Reported by:joshua dot ce20 at gmail dot com Summary:Class DOTNET not found with PHP 5.4.7 -Status: Open +Status: Feedback Type: Feature/Change Request Package:COM related Operating System: Win 8 64bit PHP Version:5.4.16 Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Please post the output of the the following commando while in the php root dir php -n -d extension_dir=ext -d extension=php_com_dotnet.dll --rc DOTNET Previous Comments: [2013-06-25 10:11:03] joshua dot ce20 at gmail dot com Description: I was trying to use DOTNET class with PHP 5.4.7 version.. and i read that there is no support in latest version, but some said i can use it with including "php_com_dotnet.dll" in ext folder and add "extension=php_com_dotnet.dll" in php.ini file.. but still i cant fix the issue.. is there any other way to include Dotnet support in the latest PHP versions.. Expected result: Hello .Net Actual result: -- Fatal error: Class 'DOTNET' not found -- Edit this bug report at https://bugs.php.net/bug.php?id=65122&edit=1
[PHP-BUG] Req #65122 [NEW]: Class DOTNET not found with PHP 5.4.7
From: joshua dot ce20 at gmail dot com Operating system: Win 8 64bit PHP version: 5.4.16 Package: COM related Bug Type: Feature/Change Request Bug description:Class DOTNET not found with PHP 5.4.7 Description: I was trying to use DOTNET class with PHP 5.4.7 version.. and i read that there is no support in latest version, but some said i can use it with including "php_com_dotnet.dll" in ext folder and add "extension=php_com_dotnet.dll" in php.ini file.. but still i cant fix the issue.. is there any other way to include Dotnet support in the latest PHP versions.. Expected result: Hello .Net Actual result: -- Fatal error: Class 'DOTNET' not found -- Edit bug report at https://bugs.php.net/bug.php?id=65122&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65122&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65122&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65122&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65122&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65122&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65122&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65122&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65122&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65122&r=support Expected behavior: https://bugs.php.net/fix.php?id=65122&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65122&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65122&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65122&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65122&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65122&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65122&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65122&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65122&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65122&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65122&r=mysqlcfg
[PHP-BUG] Bug #65120 [NEW]: fpm build fails on ppc: #error Unsupported processor
From: php-bugs-2013 at ryandesign dot com Operating system: Mac OS X 10.5.8 PHP version: 5.5.0 Package: Compile Failure Bug Type: Bug Bug description:fpm build fails on ppc: #error Unsupported processor Description: Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling with Apple's gcc 4.0.1 which comes with Xcode, with the following error: :info:build /bin/sh /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps -- mode=compile /usr/bin/gcc-4.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/main - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0 - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/date/lib - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex - I/Volumes/Data/macports/leopard/include/libxml2 - I/Volumes/Data/macports/leopard/include - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/TSRM - I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports _lang_php/php55-fpm/work/php-5.5.0/Zend - I/Volumes/Data/macports/leopard/include -no-cpp-precomp -pipe -O2 -arch ppc - fvisibility=hidden -c /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo :info:build In file included from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15, :info:build from /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21: :info:build /Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_ lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). Previous bug reports about fpm sapi build failure on PowerPC or POWER processors include #51214 (closed as not a bug because fpm wasn't part of php at that time); #51772 (closed as no feedback; there was a patch attached but someone said it was unstable); #54273 (closed as won't fix because the person handling the bug had no access to PowerPC equipment). -- Edit bug report at https://bugs.php.net/bug.php?id=65120&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65120&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65120&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65120&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65120&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65120&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65120&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65120&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65120&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65120&r=support Expected behavior: https://bugs.php.net/fix.php?id=65120&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65120&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65120&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65120&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65120&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65120&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65120&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65120&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65120&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65120&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65120&r=mysqlcfg
Req #54043 [Com]: Remove inconsitency of internal exceptions and user defined exceptions
Edit report at https://bugs.php.net/bug.php?id=54043&edit=1
ID: 54043
Comment by: jwalton at m3hc dot com
Reported by:sht dot alien at gmx dot net
Summary:Remove inconsitency of internal exceptions and user
defined exceptions
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: Ubuntu Linux 10.04 x64
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Added patch which puts setting last error until AFTER its determined that an
exception is thrown, and will only set it, if no exception is actually thrown.
I'm not really sure the purpose of setting the error if no error is actually
thrown (ala not suppressed by @)
IMO, it would make MORE sense to have shutdown function know if it is being
shutdown because of an error.
Previous Comments:
[2011-02-18 10:10:24] sht dot alien at gmx dot net
Sorry, I mixed up actual result and expected result. It should be the other way
round...
So actual result is expected result, and expected result is actual result ;-)
[2011-02-18 10:08:28] sht dot alien at gmx dot net
Description:
Exceptions thrown by standard PHP classes are handled inconsistently to user
defined exceptions, but should not.
An internal exception, like the one thrown by DateTime::__construct() when
supplying and invalid date string (like '-11-33') also trigger a E_WARNING.
User defined Exceptions do not trigger an additional E_WARNING.
If you create a custom error handler which converts all PHP errors to
exceptions, catching internal exceptions inline therefore throws another
Exception in the custom error handler, making it impossible to really catch the
Exception.
REQUEST:
Both exception types should work consistently likewise, preferrably without
triggering an E_WARNING.
Or there should be means to distinguish an error triggered by an internal
exception from an actual error and provide data if the exception was already
handled/catched.
Test script:
---
getMessage());
}
echo 'END' . PHP_EOL;
function shutdown()
{
$error = error_get_last();
var_dump('Error ', @$error);
}
?>
getMessage());
}
echo 'END' . PHP_EOL;
function shutdown()
{
$error = error_get_last();
var_dump('Error ', @$error);
}
?>
Expected result:
Output DateTime::__construct() exception:
string(10) "Exception:"
string(105) "DateTime::__construct(): Failed to parse time string (-11-33)
at position 9 (3): Unexpected character"
END
string(6) "Error "
array(4) {
["type"]=>
int(2)
["message"]=>
string(105) "DateTime::__construct(): Failed to parse time string
(-11-33) at position 9 (3): Unexpected character"
["file"]=>
string(67)
"/home/jebner/Zend/workspaces/DefaultWorkspace7/sandbox/datetime.php"
["line"]=>
int(8)
}
Output user defined exception:
string(10) "Exception:"
string(13) "Foo Exception"
END
string(6) "Error "
NULL
Actual result:
--
Output DateTime::__construct() exception:
string(10) "Exception:"
string(105) "DateTime::__construct(): Failed to parse time string (-11-33)
at position 9 (3): Unexpected character"
END
string(4) "Error "
NULL
}
Output user defined exception:
string(10) "Exception:"
string(13) "Foo Exception"
END
string(6) "Error "
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=54043&edit=1
[PHP-BUG] Req #65119 [NEW]: provide a way to inherit a final class or overriding final methods
From: knight at kopernet dot org Operating system: PHP version: Irrelevant Package: Reflection related Bug Type: Feature/Change Request Bug description:provide a way to inherit a final class or overriding final methods Description: Please provide a way to make possible to bypass the final keyword restriction in similar way the ReflectionAPI makes possible to call private or protected members. -- Edit bug report at https://bugs.php.net/bug.php?id=65119&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65119&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65119&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65119&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65119&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65119&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65119&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65119&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65119&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65119&r=support Expected behavior: https://bugs.php.net/fix.php?id=65119&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65119&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65119&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65119&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65119&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65119&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65119&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65119&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65119&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65119&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65119&r=mysqlcfg
Req #65103 [Com]: consider the final keyword depracation
Edit report at https://bugs.php.net/bug.php?id=65103&edit=1 ID: 65103 Comment by: knight at kopernet dot org Reported by:knight at kopernet dot org Summary:consider the final keyword depracation Status: Wont fix Type: Feature/Change Request Package:Class/Object related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: But the implementation is sealed. The only way to override the construction is to use a factory method e.g. call your constructor and proceed with remaining initialization in the factory method. My initialization in the extended class can be as critical as yours yet I cannot do anything to prevent someone creating an object of my new type with only your(e.g. base) constructor called. On the other hand if someone creates an object and forgets to call your constructor and it's so obvious as you say it segfaults than the programmer gets feedback immediately so I don't get why you insist on preventing it. But your point is very good. I've seen that hundred times: someone tries to extend a framework component without truly understanding its lifecycle. A sealed constructor is a good way to make sure it is used correctly. Better yet if the constructor is protected so that only the factory method can be used to create the object. That's however imposes the need to adopt the usage of factory method throughout your codebase. Previous Comments: [2013-06-25 07:45:43] a...@php.net @knight at kopernet dot org IMHO that should be either a request to implement something like Reflection makeInheritable() . The final keyword has its uses and PHP isn't Java. If you're really in the mood, please consider writing your thoughts about what should be done as improvement at this place, and discussing it on the internals list. Such a request is rather useless without discussing all possible pro and contra. [2013-06-25 04:36:35] larue...@php.net I think Final is very useful in the following case: like I did in Yaf, I got a Yaf class, there are some key resource need to be initialized. if these resource didn't intialized, then maybe segfault later. so, I defined a constructor. and do such initialization. but user can extends my Yaf class, and they also might define there own constructor, and doesn't call the parent::construct... so I make the Yaf::construct final every is fine now. [2013-06-23 09:16:07] knight at kopernet dot org Description: The final keyword is widely recognized among many programmers that adopted OOP paradigim esp. comming from or knowing Java. I find it very problematic though. Without a real compilation stage using the final keyword in the type hints does not make sure that all execution paths in the calling code passes an object of the expected type. This is completely different from Java which actually makes sure the correctness of the passed arguments. Also when it comes to writing unit tests - there's no way to override a final class and test code that makes use or depends on such an object. Please consider deprecating, removing the final keyword or release the imposed restriction. -- Edit this bug report at https://bugs.php.net/bug.php?id=65103&edit=1
Bug #65116 [Opn->Csd]: fgets() fails to return newline at end of string
Edit report at https://bugs.php.net/bug.php?id=65116&edit=1
ID: 65116
Updated by: a...@php.net
Reported by:strideroflands at yahoo dot com
Summary:fgets() fails to return newline at end of string
-Status: Open
+Status: Closed
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.16
-Assigned To:
+Assigned To:ab
Block user comment: N
Private report: N
Previous Comments:
[2013-06-25 06:40:43] strideroflands at yahoo dot com
sorry. it is keeping the newline as expected after all. please delete this
bug.
[2013-06-25 04:10:16] strideroflands at yahoo dot com
Description:
---
>From manual page: http://www.php.net/function.fgets
---
In "C" programming, the function fgets() returns the end of line character at
the end of the string. The description of stream_get_line says
"This function is nearly identical to fgets() except in that it allows end of
line delimiters other than the standard \n, \r, and \r\n, and does not return
the delimiter itself."
This suggests that fgets() should indeed return a newline character. Such
functionality would be very useful. In "C", fgets(fp) is known to be a known
source of bugs, since it overwrites memory buffers when the line is longer than
intended. In PHP, fgets() allows an additional parameter to limit the size of
a buffer it can fill. If fgets() does not return a newline if it reaches one,
how are we supposed to know if it reached the end of the "length" parameter, or
if it reached a newline?
In the test script, it can report if a line is longer than expected only if the
newline is returned. However, this does not happen. The only way to know if
this happened would be 1) write your own fgets() function, 2) see if you are at
the end of the file, use ftell to determine the position, read a byte, seek to
the position ftell just reported, and test on the byte. This is more laborious
than the simple test for a newline below. The lack of returning the newline
effectively obviates the usefulness of the "length" parameter. If one were to
encounter a large video file, e.g., the whole thing might be read into memory,
and there would be no convenient way to detect it.
I generally detest any changes that break existing code by changing the
language. Therefore, I suggest making another function that won't be giving
existing applications newline characters they didn't have before; or else
having a variable that you set to make fgets() return newlines like it should.
This is actually vers. 5.4.15.
Test script:
---
$hndl = fopen("aFileWithNewlines.txt", "r+");
$line= fgets ($hndl,80);
if (strpos($line,"\n")==false)
echo "error";
else
echo "no error";
Expected result:
"error" if the line is longer than 80 characters, otherwise, "no error".
Actual result:
--
always "error"
--
Edit this bug report at https://bugs.php.net/bug.php?id=65116&edit=1
Req #65103 [Fbk->Wfx]: consider the final keyword depracation
Edit report at https://bugs.php.net/bug.php?id=65103&edit=1 ID: 65103 Updated by: a...@php.net Reported by:knight at kopernet dot org Summary:consider the final keyword depracation -Status: Feedback +Status: Wont fix Type: Feature/Change Request Package:Class/Object related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: @knight at kopernet dot org IMHO that should be either a request to implement something like Reflection makeInheritable() . The final keyword has its uses and PHP isn't Java. If you're really in the mood, please consider writing your thoughts about what should be done as improvement at this place, and discussing it on the internals list. Such a request is rather useless without discussing all possible pro and contra. Previous Comments: [2013-06-25 04:36:35] larue...@php.net I think Final is very useful in the following case: like I did in Yaf, I got a Yaf class, there are some key resource need to be initialized. if these resource didn't intialized, then maybe segfault later. so, I defined a constructor. and do such initialization. but user can extends my Yaf class, and they also might define there own constructor, and doesn't call the parent::construct... so I make the Yaf::construct final every is fine now. [2013-06-23 09:16:07] knight at kopernet dot org Description: The final keyword is widely recognized among many programmers that adopted OOP paradigim esp. comming from or knowing Java. I find it very problematic though. Without a real compilation stage using the final keyword in the type hints does not make sure that all execution paths in the calling code passes an object of the expected type. This is completely different from Java which actually makes sure the correctness of the passed arguments. Also when it comes to writing unit tests - there's no way to override a final class and test code that makes use or depends on such an object. Please consider deprecating, removing the final keyword or release the imposed restriction. -- Edit this bug report at https://bugs.php.net/bug.php?id=65103&edit=1
Bug #65111 [Asn]: Calling traits directly with static properties/methods
Edit report at https://bugs.php.net/bug.php?id=65111&edit=1 ID: 65111 Updated by: g...@php.net Reported by:ryan dot brothers at gmail dot com Summary:Calling traits directly with static properties/methods Status: Assigned Type: Bug Package:Class/Object related Operating System: Linux PHP Version:5.5.0 Assigned To:gron Block user comment: N Private report: N New Comment: Yes, traits are not supposed to be instantiated. However, this behavior is not really related to instantiation. Traits are still a lexical entity, i.e., a programming language entity that provides a lexical scope when defined. Since PHP allows us to define functions in such scopes, we can define also static methods on traits. The way to avoid that would be to change the grammar for traits. I decided to not do that back in the day. And I still feel that it is unclear whether it would be conceptually cleaner if it is not possible to defined static state/methods. So, I would leave it as it is. Except, someone comes up with a good reason to change it. But it would also be quite a bit of a BC issue. Previous Comments: [2013-06-25 04:30:41] larue...@php.net hmm, trait is actually a class in php, I have a quick look into this.. changing this will needs a significant works.. actually, the is_callable / do_call alreay is a little mess now. I mean the codes [2013-06-24 16:52:52] ryan dot brothers at gmail dot com Description: The documentation for traits indicates that "it is not possible to instantiate a Trait on its own", but I have noticed that a trait can be called directly if it has a static property or method, as per the below example. Is this intended behavior? Or should traits be restricted from being called directly? I was under the impression that traits cannot be called directly per the documentation. If not, is there a way to prevent traits from being called directly as in the below example? Test script: --- https://bugs.php.net/bug.php?id=65111&edit=1
Bug #65055 [Asn]: new Operator shuld never return a NULL new ResourceBundle
Edit report at https://bugs.php.net/bug.php?id=65055&edit=1
ID: 65055
User updated by:goetas at lignano dot it
Reported by:goetas at lignano dot it
Summary:new Operator shuld never return a NULL new
ResourceBundle
Status: Assigned
Type: Bug
Package:I18N and L10N related
Operating System: ubuntu 12.04
PHP Version:5.4.16
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Similar behaviour has been verified with NumberFormatter class
Previous Comments:
[2013-06-24 03:14:19] fel...@php.net
Seems it is not the only class which has such behavior.
[2013-06-18 07:59:01] goetas at lignano dot it
Description:
sapi/cli/php -v
PHP 5.4.16 (cli) (built: Jun 18 2013 09:34:40)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
Instantiating ResourceBundle class, a "new" operator should never return null.
http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new
"To create an instance of a class, the new keyword must be used. An object will
always be created unless the object has a constructor defined that throws an
exception on error."
This behaviour it's also verified by Symfony team
https://github.com/symfony/Intl/blob/master/ResourceBundle/Reader/BinaryBundleReader.php
Test script:
---
sapi/cli/php -r 'var_dump(new \ResourceBundle("ANY WRONG PATH", "it"));'
Expected result:
Thrown some exception
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=65055&edit=1
