[PHP-BUG] Bug #51806 [NEW]: chdir wont'work on phar files
From: Operating system: Slackware PHP version: 5.3.2 Package: PHAR related Bug Type: Bug Bug description:chdir wont'work on phar files Description: cant change current working directory into phar package file Test script: --- '; include 'phar://test.tar.phar/index.php'; Expected result: string(50) "phar:///mnt/md1/www/htdocs/test/phar/test.tar.phar" bool(true) Actual result: -- string(50) "phar:///mnt/md1/www/htdocs/test/phar/test.tar.phar" Warning: chdir() [function.chdir]: No such file or directory (errno 2) in phar:///mnt/md1/www/htdocs/test/phar/test.tar.phar/indxed.php on line 1 bool(false) -- Edit bug report at http://bugs.php.net/bug.php?id=51806&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51806&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51806&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51806&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51806&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51806&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51806&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51806&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51806&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51806&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51806&r=support Expected behavior: http://bugs.php.net/fix.php?id=51806&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51806&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51806&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51806&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51806&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51806&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51806&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51806&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51806&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51806&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51806&r=mysqlcfg
[PHP-BUG] Bug #51807 [NEW]: set_exception_handler
From:
Operating system: win.xp.sp3
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:set_exception_handler
Description:
faultCode1faultStringWarning:set_exception_handler() expects the argument
(exception_handler) to be a valid callback in
C:\WebServers\htdocs\count\new\test.php on line 6
if(DEBUG) set_exception_handler('exception_handler');
function exception_handler(Exception $ex){
$str_time = $ex->getFile() .":". $ex->getLine() ." ".
htmlentities($ex->getMessage()) ." (". $ex->getCode() .") [".
get_class($ex) ."]\r\n";
echo $str_time;
}
Test script:
---
if(DEBUG) set_exception_handler('exception_handler');
function exception_handler(Exception $ex){
$str_time = $ex->getFile() .":". $ex->getLine() ." ".
htmlentities($ex->getMessage()) ." (". $ex->getCode() .") [".
get_class($ex) ."]\r\n";
echo $str_time;
}
--
Edit bug report at http://bugs.php.net/bug.php?id=51807&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51807&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51807&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51807&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51807&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51807&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51807&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51807&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51807&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51807&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51807&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51807&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51807&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51807&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51807&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51807&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51807&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51807&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51807&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51807&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51807&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51807&r=mysqlcfg
[PHP-BUG] Req #51808 [NEW]: Operator `new' does not support expressions for class name
From:
Operating system: linux/current
PHP version: 5.2.13
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Operator `new' does not support expressions for class name
Description:
Operator `new' accepts either class name as either symbol token or
variable
containing class name (T_STRING or
T_VARIABLE), but does not allow expressions returning class name.
Test script:
---
/* first form, works */
$handler = new SomeClass($constructorParam);
/* second form, works */
$handlerClass = handlerFor($something); /* returns name of some class to be
instantiated */
$handler = new $handlerClass($constructorParam);
/* third form -- does not work */
$handler = new (handlerFor($something))($constructorParam);
Expected result:
The third form ought to work just like the other two, so one doesn't need
to
create extra variable for single use.
Actual result:
--
PHP Parse error: syntax error, unexpected '(', expecting T_STRING or
T_VARIABLE
or '$'
--
Edit bug report at http://bugs.php.net/bug.php?id=51808&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51808&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51808&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51808&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51808&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51808&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51808&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51808&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51808&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51808&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51808&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51808&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51808&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51808&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51808&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51808&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51808&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51808&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51808&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51808&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51808&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51808&r=mysqlcfg
[PHP-BUG] Bug #51810 [NEW]: empty line added if $header is given to mail()
From: Operating system: Linux / SuSE 11.2 and 10.2 PHP version: 5.3.2 Package: Mail related Bug Type: Bug Bug description:empty line added if $header is given to mail() Description: If mail() is called with the $header argument, an empty line is inserted before the $header ĺine. Therefore the content of $header is not seen as valid mail header. Test script: --- Actual result: -- If $header is given (see example above) the (shortened) mail text looks like: --- from here Return-Path: <> Received: To: m...@example.com Subject: my sub X-Mailer: PHP/5.3.1 Message-Id: <...> From: ... Message-Id: <...> Date: ... X-Length: 2014 X-UID: 252148 Message-Id: <...> Date: From: my body -- with header1 -- to here Now After X-UID: there is an empty line, which should n ot be there (in my opinion). -- Edit bug report at http://bugs.php.net/bug.php?id=51810&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51810&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51810&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51810&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51810&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51810&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51810&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51810&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51810&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51810&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51810&r=support Expected behavior: http://bugs.php.net/fix.php?id=51810&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51810&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51810&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51810&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51810&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51810&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51810&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51810&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51810&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51810&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51810&r=mysqlcfg
Bug #51803 [Fbk->Bgs]: Interface implementation silently fails
Edit report at http://bugs.php.net/bug.php?id=51803&edit=1
ID: 51803
Updated by: dtajchre...@php.net
Reported by: kherge at me dot com
Summary: Interface implementation silently fails
-Status: Feedback
+Status: Bogus
Type: Bug
Package: Reproducible crash
Operating System: Windows XP SP3
PHP Version: 5.3.2
New Comment:
Closing as bogus.
Previous Comments:
[2010-05-12 22:43:48] dtajchre...@php.net
Ditto on reproducing it.
C:\Documents and Settings\David\Desktop\php-5.3.2-Win32-VC6-x86>php
..\test.php
Fatal error: Access level to MyClass::_test() must be public (as in
class MyInte
rface) in C:\Documents and Settings\David\Desktop\test.php on line 9
C:\Documents and Settings\David\Desktop\php-5.3.2-Win32-VC6-x86>echo
%ERRORLEVEL%
255
I think it's a configuration issue on your end. Check your error
log/display error settings. Your class has to implement the method the
way that the interface describes it. Your interface defaults to public
for _test() and test() but you alter that.. a simpler test case:
class A implements Iterator {
private function next() { }
}
should yield the same error as in your example.
[2010-05-12 22:09:18] kherge at me dot com
Error reporting is currently set to 32767 (E_ALL | E_STRICT).
[2010-05-12 22:05:32] dtajchre...@php.net
Do you have error reporting settings at the right level.. display
errors? I get a nice fatal error as expected..
da...@beirut:~$ php test.php
PHP Fatal error: Access level to MyClass::_test() must be public (as in
class MyInterface) in /home/david/test.php on line 9
Fatal error: Access level to MyClass::_test() must be public (as in
class MyInterface) in /home/david/test.php on line 9
da...@beirut:~$ echo $?
255
[2010-05-12 21:55:55] kherge at me dot com
Description:
Running the test script, PHP silently exists with the error code 255.
If you
remove the protected access type from the _test() function in the
MyClass class,
the script executes normally.
Test script:
---
http://bugs.php.net/bug.php?id=51803&edit=1
Bug #51807 [Opn->Fbk]: set_exception_handler
Edit report at http://bugs.php.net/bug.php?id=51807&edit=1
ID: 51807
Updated by: dtajchre...@php.net
Reported by: cybermerlin at ya dot ru
Summary: set_exception_handler
-Status: Open
+Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win.xp.sp3
PHP Version: 5.3.2
New Comment:
Your test script works fine. But the line number in your error doesn't
match up with your script so that makes me think your test script is
just a snippet of what you're actually using. You need to provide the
entire test script that failed, not snippets of one.
If the exception_handler function is a class method, you need to change
your callback, see: http://php.net/callback
Previous Comments:
[2010-05-13 10:22:02] cybermerlin at ya dot ru
Description:
faultCode1faultStringWarning:set_exception_handler() expects the
argument (exception_handler) to be a valid callback in
C:\WebServers\htdocs\count\new\test.php on line 6
if(DEBUG) set_exception_handler('exception_handler');
function exception_handler(Exception $ex){
$str_time = $ex->getFile() .":". $ex->getLine() ." ".
htmlentities($ex->getMessage()) ." (". $ex->getCode() .") [".
get_class($ex) ."]\r\n";
echo $str_time;
}
Test script:
---
if(DEBUG) set_exception_handler('exception_handler');
function exception_handler(Exception $ex){
$str_time = $ex->getFile() .":". $ex->getLine() ." ".
htmlentities($ex->getMessage()) ." (". $ex->getCode() .") [".
get_class($ex) ."]\r\n";
echo $str_time;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51807&edit=1
Bug #51810 [Opn->Fbk]: empty line added if $header is given to mail()
Edit report at http://bugs.php.net/bug.php?id=51810&edit=1 ID: 51810 Updated by: ka...@php.net Reported by: juergen dot vollmer at informatik-vollmer dot de Summary: empty line added if $header is given to mail() -Status: Open +Status: Feedback Type: Bug Package: Mail related Operating System: Linux / SuSE 11.2 and 10.2 PHP Version: 5.3.2 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-05-13 16:58:13] juergen dot vollmer at informatik-vollmer dot de Description: If mail() is called with the $header argument, an empty line is inserted before the $header ĺine. Therefore the content of $header is not seen as valid mail header. Test script: --- Actual result: -- If $header is given (see example above) the (shortened) mail text looks like: --- from here Return-Path: <> Received: To: m...@example.com Subject: my sub X-Mailer: PHP/5.3.1 Message-Id: <...> From: ... Message-Id: <...> Date: ... X-Length: 2014 X-UID: 252148 Message-Id: <...> Date: From: my body -- with header1 -- to here Now After X-UID: there is an empty line, which should n ot be there (in my opinion). -- Edit this bug report at http://bugs.php.net/bug.php?id=51810&edit=1
Bug #51761 [Fbk->Opn]: Memory Error: IPR in language scanner
Edit report at http://bugs.php.net/bug.php?id=51761&edit=1 ID: 51761 User updated by: russell dot tempero at rightnow dot com Reported by: russell dot tempero at rightnow dot com Summary: Memory Error: IPR in language scanner -Status: Feedback +Status: Open Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.2 New Comment: If you are confident that these errors can be fixed by altering the grammar, I'll do some more looking to see what I can come up with. This is probably going to take me a little while though. Based on what I was seeing, I thought this was more a problem with how flex generated the scanner from the grammar. Previous Comments: [2010-05-12 09:34:12] m...@php.net This should have been set to feedback, shouldn't it? [2010-05-08 11:58:17] ka...@php.net Hi You should change the grammar in zend_language_scanner.l instead of the .c file which is generated based on the contains from the .l file. Else the patch looks good [2010-05-07 00:21:08] russell dot tempero at rightnow dot com Here is some useful debug information if you wish to trace exactly where the IPRs are happening: . . . state: 476 char: ? addr: 0xf1c7885e state: 140 char: ? addr: 0xf1c7885e state: 121 char: ? addr: 0xf1c7885e state: -1 char: ? addr: 0xffce705b state: 166 char: ? addr: 0xf1c7885e state: 201 char: > addr: 0xf1c7885f state: 203 char: addr: 0xf1c78860 RUSSELL: YYCURSOR: 0xf1c78860 YYLIMIT: 0xf1c78861 state: 202 char: state: 0 char: state: 4 char: state: 3 char: RUSSELL: returning 0 in yy3 [2010-05-07 00:13:10] russell dot tempero at rightnow dot com Description: When running PHP through Purify, I am seeing Invalid Pointer Read (IPR) errors such as the following: IPR: Invalid pointer read: * This is occurring while in thread 8075: lex_scan [zend_language_scanner.c:3174] zendlex[zend_compile.c:4950] zendparse [zend_language_parser.c:3280] compile_file [zend_language_scanner.l:343] rnt_compile_file [rnt_opcode_cache.c:1008] compile_filename [zend_language_scanner.l:386] * Reading 1 byte from 0xf735f332 between the heap and the stack. It appears that script files are memory mapped and then a cursor pointer is used to iterate over the mapped memory. The problem is that the cursor pointer is not properly checked when reaching the end of the file and memory values are read that are not part of the mapped memory. I manually fixed one case of this (see attached diff). However, there are others. It looks like this file is generated (using flex?) so this is probably not actually a PHP issue. However, I thought I would start here. Let me know if this needs to be submitted to somebody else. -- Edit this bug report at http://bugs.php.net/bug.php?id=51761&edit=1
[PHP-BUG] Bug #51813 [NEW]: Cannot declare a class property with a closure value
From: Operating system: Linux PHP version: 5.3.2 Package: *General Issues Bug Type: Bug Bug description:Cannot declare a class property with a closure value Description: When declaring a class one cannot use a closure as the value of a class property. Test script: --- http://pastie.org/958947 Expected result: I expect closures to be allowed when defining a class's properties; it seems inconsistent that one can assign a closure to a property dynamically at run time, but not when defining a class. -- Edit bug report at http://bugs.php.net/bug.php?id=51813&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51813&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51813&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51813&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51813&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51813&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51813&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51813&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51813&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51813&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51813&r=support Expected behavior: http://bugs.php.net/fix.php?id=51813&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51813&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51813&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51813&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51813&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51813&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51813&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51813&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51813&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51813&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51813&r=mysqlcfg
Bug #47412 [Com]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Edit report at http://bugs.php.net/bug.php?id=47412&edit=1 ID: 47412 Comment by: tser at deltacontrols dot com Reported by: tser at deltacontrols dot com Summary: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI Status: No Feedback Type: Bug Package: CGI related Operating System: win32 only - Vista PHP Version: 5.2.9RC2 Assigned To: pajoye New Comment: I cannot re-open the bug. There are more info on handling of SignalBeforeTerminateSeconds Please refer to http://forums.iis.net/t/1167753.aspx Previous Comments: [2010-05-12 02:12:15] tser at deltacontrols dot com More information. Using the latest FastCGI update on IIS7 (KB980363) which support SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being called. Look into the code in sapi/cgi/fastcgi.c A thread fcgi_shutdown_thread has been created to trap the "_FCGI_SHUTDOWN_EVENT_" event but the code simply set in_shutdown to 1. After that, PHP_MSHUTDOWN_FUNCTION in the extension code is still not being called. [2010-01-12 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-01-04 18:52:37] tser at deltacontrols dot com To answer the question, the values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests ar eboth 1. But they do not come into play to duplicate this problem. The problem could be duplicated before number of request reach these numbers. I will try to explain the detail using just the standard extension (php_date). 1. Setup PHP FactCGI in IIS. Everything default. 2. Try to run a test.php with this code 3. Attach the debugger to php_cgi.exe and make sure it loaded the debug symbol of php_date. 4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c 5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click "Recycle..." on the right hand pane. 6. Notice that the php_cgi.exe will exit but your breakpoint in php_date.c is not triggered. [2010-01-04 14:00:54] paj...@php.net It is called as expected (tested on vista/iis and in the console). If you still experiece this problem, then please provide a detailed way to reproduce: - what are you doing exactly in IIS - values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting) [2009-12-23 02:27:19] paj...@php.net Will verify this issue once I'm back from vacation. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47412 -- Edit this bug report at http://bugs.php.net/bug.php?id=47412&edit=1
Bug #47412 [NoF->Fbk]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Edit report at http://bugs.php.net/bug.php?id=47412&edit=1 ID: 47412 Updated by: paj...@php.net Reported by: tser at deltacontrols dot com Summary: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI -Status: No Feedback +Status: Feedback Type: Bug Package: CGI related Operating System: win32 only - Vista PHP Version: 5.2.9RC2 Assigned To: pajoye New Comment: Please post the relevant information here ( > feedback again). Previous Comments: [2010-05-13 20:27:26] tser at deltacontrols dot com I cannot re-open the bug. There are more info on handling of SignalBeforeTerminateSeconds Please refer to http://forums.iis.net/t/1167753.aspx [2010-05-12 02:12:15] tser at deltacontrols dot com More information. Using the latest FastCGI update on IIS7 (KB980363) which support SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being called. Look into the code in sapi/cgi/fastcgi.c A thread fcgi_shutdown_thread has been created to trap the "_FCGI_SHUTDOWN_EVENT_" event but the code simply set in_shutdown to 1. After that, PHP_MSHUTDOWN_FUNCTION in the extension code is still not being called. [2010-01-12 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-01-04 18:52:37] tser at deltacontrols dot com To answer the question, the values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests ar eboth 1. But they do not come into play to duplicate this problem. The problem could be duplicated before number of request reach these numbers. I will try to explain the detail using just the standard extension (php_date). 1. Setup PHP FactCGI in IIS. Everything default. 2. Try to run a test.php with this code 3. Attach the debugger to php_cgi.exe and make sure it loaded the debug symbol of php_date. 4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c 5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click "Recycle..." on the right hand pane. 6. Notice that the php_cgi.exe will exit but your breakpoint in php_date.c is not triggered. [2010-01-04 14:00:54] paj...@php.net It is called as expected (tested on vista/iis and in the console). If you still experiece this problem, then please provide a detailed way to reproduce: - what are you doing exactly in IIS - values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47412 -- Edit this bug report at http://bugs.php.net/bug.php?id=47412&edit=1
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Comment by: derek dot ethier at humber dot ca Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) Status: Assigned Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 Assigned To: pajoye New Comment: I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem. It seems to happen so randomly, but the only consistent element is that the numbers all have 9 in them. There is an existing bug opened for float that was closed as bogus: http://bugs.php.net/bug.php?id=47716 Previous Comments: [2010-04-16 11:15:26] paj...@php.net I will ask our test team to try to reproduce it. [2010-04-15 20:24:54] derek dot ethier at humber dot ca I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. [2009-12-21 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49764 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1
Bug #47716 [Com]: Invalid/Corrupt Math Convert string to float
Edit report at http://bugs.php.net/bug.php?id=47716&edit=1
ID: 47716
Comment by: derek dot ethier at humber dot ca
Reported by: codeslinger at compsalot dot com
Summary: Invalid/Corrupt Math Convert string to float
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: windows 2000
PHP Version: 5.2.9
New Comment:
Cross-posting this with: http://bugs.php.net/bug.php?id=49764
It appears to happen randomly with either the number_format function or
with converting str to float. The only consistent element is that the
converted/formatted number contains a 9.
At least in my experience.
Previous Comments:
[2009-04-22 17:22:22] codeslinger at compsalot dot com
This is a copy of the comment that I put into Bug #47304 That bug has
now been closed due to lack of activity. So, we now have multiple
closed bugs, no fixes in sight, no further dev activity expected, and a
very serious problem remains.
---
Hi pajoye,
thank you for the response to bug #47716
you requested that future replies be here.
The interesting thing is that when you did a setlocale you got a result
back... but when I did it all I get is an empty string, I wondered
about this at the time that I entered the bug but did not mention it
because I figured the 18:0 vs 19.00 was sufficient.
and yes, as it states in that bug, the problem only occurs when a large
complex program using lots of memory is running and then within that
context you run the repro. if you just do the repro script by itself
with nothing else going on then it works just fine.
$arrMsgs[] = "Locale = ".setlocale(LC_ALL, "english-usa");
[0] => Locale =
I will give 5.3 a try and see what happens.
Environment: For the testing, I am actually running windows 2000 in a
vmware box under Ubuntu on a Pentium M.
-
P.S. my program has some dependencies on PECL libs, it turns out not to
be possible for me to run 5.3 at this time.
[2009-03-20 16:04:34] paj...@php.net
Please reply in #47304 (duplicated).
[2009-03-20 15:57:31] paj...@php.net
I'm not sure what's wrong.
Here is what I get:
Windows 2008 (latest SP):
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 58240
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 57240
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
Windows 2003 (latest SP):
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 56152
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 56024
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
Windows XP sp2:
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 57112
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 56112
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
[2009-03-20 15:40:32] codeslinger at compsalot dot com
in case it wasn't clear from the description above, this is using the
CLI version of php.
also unlike a number of other bugs that I have read. Adding and
removing various lines of code -- which I did quite a bit of while
isolating this problem, plus adding a planned revision to the code --
had no effect on the result, the bug was totally repeatable.
This was using the official php windows binary, not one that I compiled.
The only difference between the working and not working versions of the
program are the php version.
How is it possible to convert a string to a float and have the result
contain a colon character???
[2009-03-19 12:11:23] codeslinger at compsalot dot com
Description:
It is with great hesitancy that I enter this bug, because I am not able
to produce a simple test case for it. But the bug is very serious.
I have a program that calculates and sends out customer statements.
Without making any changes to the php program itself which has been
running fine, I upgraded to PHP 5.2.9 and also tested with 5.2.9-1
both with and without xdebug enabled.
The math is bad, the calculations are incorrect. Below is a program
that displays this problem, but it do
Bug #47412 [Fbk->Opn]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Edit report at http://bugs.php.net/bug.php?id=47412&edit=1
ID: 47412
User updated by: tser at deltacontrols dot com
Reported by: tser at deltacontrols dot com
Summary: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
-Status: Feedback
+Status: Open
Type: Bug
Package: CGI related
Operating System: win32 only - Vista
PHP Version: 5.2.9RC2
Assigned To: pajoye
New Comment:
Using Vista64 IIS7 with the update (KB980363).
1. Setup PHP FactCGI in IIS. Everything default.
2. Open C:\Windows\System32\inetsrv\config\applicationHost.config
Edit the section and add signalBeforeTerminateSeconds="30"
3. Create a test.php with . Browse it.
4. Attach debugger to php-cgi.exe process (with debug symbol).
5. Put a breakpoint in sapi/cgi/fastcgi.c (after WaitForSingleObject)
static DWORD WINAPI fcgi_shutdown_thread(LPVOID arg)
{
HANDLE shutdown_event = (HANDLE) arg;
WaitForSingleObject(shutdown_event, INFINITE);
in_shutdown = 1; <--breakpoint here
return 0;
}
6. Put a break point in ext/date/php_date.c
PHP_MSHUTDOWN_FUNCTION(date)
{
UNREGISTER_INI_ENTRIES();
return SUCCESS; feedback again).
[2010-05-13 20:27:26] tser at deltacontrols dot com
I cannot re-open the bug.
There are more info on handling of SignalBeforeTerminateSeconds
Please refer to http://forums.iis.net/t/1167753.aspx
[2010-05-12 02:12:15] tser at deltacontrols dot com
More information.
Using the latest FastCGI update on IIS7 (KB980363) which support
SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being
called.
Look into the code in sapi/cgi/fastcgi.c
A thread fcgi_shutdown_thread has been created to trap the
"_FCGI_SHUTDOWN_EVENT_"
event but the code simply set in_shutdown to 1. After that,
PHP_MSHUTDOWN_FUNCTION
in the extension code is still not being called.
[2010-01-12 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2010-01-04 18:52:37] tser at deltacontrols dot com
To answer the question, the values of PHP_FCGI_MAX_REQUESTS and
instanceMaxRequests ar eboth 1. But they do not come into play to
duplicate this problem. The problem could be duplicated before number of
request reach these numbers.
I will try to explain the detail using just the standard extension
(php_date).
1. Setup PHP FactCGI in IIS. Everything default.
2. Try to run a test.php with this code
3. Attach the debugger to php_cgi.exe and make sure it loaded the debug
symbol of php_date.
4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c
5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click
"Recycle..." on the right hand pane.
6. Notice that the php_cgi.exe will exit but your breakpoint in
php_date.c is not triggered.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47412
--
Edit this bug report at http://bugs.php.net/bug.php?id=47412&edit=1
Bug #36355 [Com]: OCIEnvNlsCreate() failed.
Edit report at http://bugs.php.net/bug.php?id=36355&edit=1 ID: 36355 Comment by: ailton at aramorais dot com dot br Reported by: jnavratil at houston dot rr dot com Summary: OCIEnvNlsCreate() failed. Status: Bogus Type: Bug Package: OCI8 related Operating System: Fedora Core 4.2 PHP Version: 6CVS-2006-02-10 (snap) New Comment: The solution is configure envars the apache. path: /usr/local/apache2/bin/envvars: View example: ORACLE_HOME=/usr/lib/oracle/10.1.0.3/client;export ORACLE_HOME NLS_LANG=AMERICAN;export NLS_LANG LD_LIBRARY_PATH=/usr/lib/oracle/10.1.0.3/client/lib;export LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/local/apache2/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH Previous Comments: [2006-02-10 21:28:02] tony2...@php.net >It didn't seem to be necessary with PHP5.0.4 and 10g Release 2. Yes, it's funny and everybody is laughing. Because _it is_ necessary for all versions of OCI libraries, except for the Instant Client. >You said that "OCI8 extension itself doesn't require any >variables, access privileges etc.". ext/oci8 - PHP extension. OCI - Oracle Call Interface libraries. See the difference? >Something that doesn't permit >the execution of dbshut, for example. JFYI: to run dbshut you need to do `su - oracle` first. >I need to provide access to for the "world", don't I? No? And even if you would need it, what secrets are you trying to hide in your tnsnames.ora, huh? >But if you have Oracle Client installed you really don't > need instant client, do you? Except for security reasons. Well, _now_ it's funny. I thought you were so worried exactly because of security reasons. And now you're saying you don't need it. But why do I care? [2006-02-10 20:58:14] jnavratil at houston dot rr dot com > It doesn't matter what I think about it, this > is *required* by oracle client libraries. Funny. It didn't seem to be necessary with PHP5.0.4 and 10g Release 2. But what do I know? > Why do you tell me this? Just to piss you off! Maybe a couple of deep breaths next time. > If you know how to avoid it (and still provide a way > for OCI to read tnsnames.ora and other files) - > tell it to Oracle people. But wait! You said that "OCI8 extension itself doesn't require any variables, access privileges etc.". Are you telling me that you need access to tsnames.ora or other resources? If so, please elaborate and perhaps a more limited relaxation of security can be arranged. Something that doesn't permit the execution of dbshut, for example. > Also I think it would be worth to read about unix > privileges. You don't have to grant to the user both > execute and read privileges in the same time. Really? I wonder why I didn't know that :P However, I still need to know what I need to provide access to for the "world", don't I? >Wrong. It doesn't matter whether the server is local or not. Of course! But if you have Oracle Client installed you really don't need instant client, do you? Except for security reasons. >>I don't know but now will have to learn it to find out. >Yes, do it please. And when you know everything we will all sing your praises, Hallelujah! >Please direct your complaints to Oracle, it has nothing >to do with PHP or ext/oci8. Nothing, indeed! But I believe I have beat my head against this enough for the time being. [2006-02-10 20:05:45] tony2...@php.net >Do you really think that apache should be a member of >the oracle group to run php5_module with OCI8? It doesn't matter what I think about it, this is *required* by oracle client libraries. >A friend, who has been a consultant with Oracle for the > last 10 years doesn't consider it kosher. Why do you tell me this? If you know how to avoid it (and still provide a way for OCI to read tnsnames.ora and other files) - tell it to Oracle people. > My client for whom I am developing a PHP/Oracle > application doesn't particularly like the idea of a PHP > script being able execute any Oracle binary it likes. Tell your client about open_basedir directive. Also I think it would be worth to read about unix privileges. You don't have to grant to the user both execute and read privileges in the same time. >Instant client is designed for accessing remote database servers. Wrong. It doesn't matter whether the server is local or not. >I don't know but now will have to learn it to find out. Yes, do it please. >Clearly OCI8 as currently written is pretty useless for a >production environment, at least if Oracle and Apache are >on the same server. Please direct your complaints to Oracle, it has nothing to do with PHP or ext/oci8. -
Bug #51813 [Opn->Bgs]: Cannot declare a class property with a closure value
Edit report at http://bugs.php.net/bug.php?id=51813&edit=1 ID: 51813 Updated by: johan...@php.net Reported by: richard at rjharrison dot org Summary: Cannot declare a class property with a closure value -Status: Open +Status: Bogus Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.3.2 New Comment: This was reported in other reports, and follows the current specification of the feature. There were discussions about this. This might be re-evaluated but would require a good RFC (incl. discussion of cases where methods and properties with the same name or a __call method exist) not a bug report. Previous Comments: [2010-05-13 20:04:11] richard at rjharrison dot org Description: When declaring a class one cannot use a closure as the value of a class property. Test script: --- http://pastie.org/958947 Expected result: I expect closures to be allowed when defining a class's properties; it seems inconsistent that one can assign a closure to a property dynamically at run time, but not when defining a class. -- Edit this bug report at http://bugs.php.net/bug.php?id=51813&edit=1
[PHP-BUG] Req #51815 [NEW]: Add support for cURL option CURLOPT_MAX_RECV_SPEED_LARGE
From: Operating system: all PHP version: 5.2SVN-2010-05-13 (snap) Package: cURL related Bug Type: Feature/Change Request Bug description:Add support for cURL option CURLOPT_MAX_RECV_SPEED_LARGE Description: cURL has supported download an upload rate limiting via CURLOPT_MAX_RECV_SPEED_LARGE and CURLOPT_MAX_SEND_SPEED_LARGE for some time. Support for these options needs to be added to ext/curl/interface.c (they are simple integer values so no special support is needed, they just need to be added to the constant definitions and switch statement). Test script: --- http://bitcast-a.bitgravity.com/bitgravity/1MB";); curl_setopt($ch, CURLOPT_FILE, $fh); curl_setopt($ch, CURLOPT_HEADER, 0); // grab URL curl_exec($ch); // close cURL resource, and free up system resources curl_close($ch); fclose($fh); ?> Expected result: Script should take at least 100 seconds to run (no matter the speed of the local internet connection). Actual result: -- Currently, because CURLOPT_MAX_RECV_SPEED_LARGE is not implemented in the cURL extension, the script takes as long as downloading the file over the local internet connection takes, i.e. there is no rate limiting. -- Edit bug report at http://bugs.php.net/bug.php?id=51815&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51815&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51815&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51815&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51815&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51815&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51815&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51815&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51815&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51815&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51815&r=support Expected behavior: http://bugs.php.net/fix.php?id=51815&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51815&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51815&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51815&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51815&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51815&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51815&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51815&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51815&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51815&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51815&r=mysqlcfg
[PHP-BUG] Bug #51817 [NEW]: php .ini file parser does not allow ! in ini values
From: Operating system: windows7 PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Bug Bug description:php .ini file parser does not allow ! in ini values Description: if in .ini file values has '!',parse_ini_file will failed. Test script: --- this is en_GB.ini file code: SOFT_DESCRIPTION=create the Joomla! templateDetails.xml file this is php file code: $language = parse_ini_file($language_file); -- Edit bug report at http://bugs.php.net/bug.php?id=51817&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51817&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51817&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51817&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51817&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51817&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51817&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51817&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51817&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51817&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51817&r=support Expected behavior: http://bugs.php.net/fix.php?id=51817&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51817&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51817&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51817&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51817&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51817&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51817&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51817&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51817&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51817&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51817&r=mysqlcfg
[PHP-BUG] Bug #51818 [NEW]: var_dump(): Couldn't fetch mysqli
From:
Operating system: Linux
PHP version: 5.3.2
Package: MySQLi related
Bug Type: Bug
Bug description:var_dump(): Couldn't fetch mysqli
Description:
E_WARNING when accessing properties or methods of MySQLi object if
connection fails
I know other people already reported this kind of issue:
http://bugs.php.net/bug.php?id=33635
http://bugs.php.net/bug.php?id=34828
http://bugs.php.net/bug.php?id=36949
http://bugs.php.net/bug.php?id=45935
http://bugs.php.net/bug.php?id=45940
http://bugs.php.net/bug.php?id=50772
though I think telling the user "couldn't fetch *mysqli*" is just wrong
because PHP is able to use the MySQLi object and even some of its
properties or methods (e.g. MySQLi::$client_version or
MySQLi::$connect_errno)
i am not sure if this is a real bug report or may be a feature request. but
I think it would help other people if the warning says something like
"mysqli is not connected" or may be E_WARNING should not be raised at all.
--
PHP 5.3.2 (cli) (built: May 14 2010 03:25:13)
MySQLi Client API library version 5.1.45
Test script:
---
Expected result:
object(mysqli)#1 (17) {
/* ... */
}
Actual result:
--
Lots of "Warning: var_dump(): Couldn't fetch mysqli in [...]" (for nearly
every single key in mysqli)
object(mysqli)#1 (17) {
/* content as expected */
}
--
Edit bug report at http://bugs.php.net/bug.php?id=51818&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51818&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51818&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51818&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51818&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51818&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51818&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51818&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51818&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51818&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51818&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51818&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51818&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51818&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51818&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51818&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51818&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51818&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51818&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51818&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51818&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51818&r=mysqlcfg
Bug #51817 [Opn->Bgs]: php .ini file parser does not allow ! in ini values
Edit report at http://bugs.php.net/bug.php?id=51817&edit=1 ID: 51817 Updated by: dtajchre...@php.net Reported by: 5superbsd at gmail dot com Summary: php .ini file parser does not allow ! in ini values -Status: Open +Status: Bogus Type: Bug Package: Unknown/Other Function Operating System: windows7 PHP Version: Irrelevant 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 SOFT_DESCRIPTION = "create the Joomla! templateDetails.xml file" . Previous Comments: [2010-05-14 03:00:44] 5superbsd at gmail dot com Description: if in .ini file values has '!',parse_ini_file will failed. Test script: --- this is en_GB.ini file code: SOFT_DESCRIPTION=create the Joomla! templateDetails.xml file this is php file code: $language = parse_ini_file($language_file); -- Edit this bug report at http://bugs.php.net/bug.php?id=51817&edit=1
Req #51815 [Opn->Csd]: Add support for cURL option CURLOPT_MAX_RECV_SPEED_LARGE
Edit report at http://bugs.php.net/bug.php?id=51815&edit=1 ID: 51815 Updated by: pierr...@php.net Reported by: perryc at gmail dot com Summary: Add support for cURL option CURLOPT_MAX_RECV_SPEED_LARGE -Status: Open +Status: Closed Type: Feature/Change Request Package: cURL related Operating System: all PHP Version: 5.2SVN-2010-05-13 (snap) -Assigned To: +Assigned To: pierrick New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-05-13 23:13:48] perryc at gmail dot com Description: cURL has supported download an upload rate limiting via CURLOPT_MAX_RECV_SPEED_LARGE and CURLOPT_MAX_SEND_SPEED_LARGE for some time. Support for these options needs to be added to ext/curl/interface.c (they are simple integer values so no special support is needed, they just need to be added to the constant definitions and switch statement). Test script: --- http://bitcast-a.bitgravity.com/bitgravity/1MB";); curl_setopt($ch, CURLOPT_FILE, $fh); curl_setopt($ch, CURLOPT_HEADER, 0); // grab URL curl_exec($ch); // close cURL resource, and free up system resources curl_close($ch); fclose($fh); ?> Expected result: Script should take at least 100 seconds to run (no matter the speed of the local internet connection). Actual result: -- Currently, because CURLOPT_MAX_RECV_SPEED_LARGE is not implemented in the cURL extension, the script takes as long as downloading the file over the local internet connection takes, i.e. there is no rate limiting. -- Edit this bug report at http://bugs.php.net/bug.php?id=51815&edit=1
