Bug #29100 [Com]: fread ignores memory_limit
Edit report at http://bugs.php.net/bug.php?id=29100edit=1 ID: 29100 Comment by: nasretdinov at gmail dot com Reported by: pickleman78 at sbcglobal dot net Summary: fread ignores memory_limit Status: Bogus Type: Bug Package: Reproducible crash Operating System: WIndows XP PHP Version: 4.3.6 New Comment: The this is that this does not lead to normal Fatal error, but to a web server/PHP uncatchable and undebuggable crash. Previous Comments: [2004-07-12 19:20:10] poll...@php.net emalloc() deosn't *actually* try to allocate the memory. It checks your requested amount against the php.ini setting and if it's too high, throws a fatal error. It has to be a fatal error because your script has outrun its resources, and it's impossible to predict whether or not it can safely continue operations in that condition. [2004-07-11 22:40:59] pickleman78 at sbcglobal dot net Description: I am getting a crash from PHP when I mistakenly attempt to read 1,761,607,681 bytes from an incoming socket. Now I would reasonably assume that since this is far above the memory limit set in my PHP.ini file memory_limit = 8M I would expect it to stop before even attempting to allocate such a rediculous ammount of memory for the script. In this case it fails with a FATAL: emalloc() unable to allocate 1761607681 bytes. Should this be what it does? I would expect it to issue an ERROR as opposed to crashing. Reproduce code: --- ?php $fp=fsockopen(http://php.net;); $data=fread($fp,1761607681); ? Expected result: It would be expected to receive an error as opposed to PHP trying to allocate this memory Actual result: -- Stated above, causes FATAL: emalloc() could not.. -- Edit this bug report at http://bugs.php.net/bug.php?id=29100edit=1
[PHP-BUG] Bug #51319 [NEW]: apache process sigsegv (double free or corruption (fasttop))
From:
Operating system: Redhat 4U4
PHP version: 5.2.13
Package: Apache related
Bug Type: Bug
Bug description:apache process sigsegv (double free or corruption (fasttop))
Description:
Hello.
We have this problem with 5.2.12 and still with 5.2.13.
In very random situation apache process sigsegv with
this in error log:
*** glibc detected *** double free or corruption (fasttop): 0x88aa9300 ***
[Thu Mar 18 06:22:06 2010] [notice] seg fault or similar nasty error
detected in the parent process
[Thu Mar 18 06:22:07 2010] [notice] child pid 1107 exit signal Segmentation
fault (11), possible coredump in /tmp
gdb shows this:
(gdb) backtrace
#0 0x0013a2c2 in abort () from /lib/tls/libc.so.6
#1 0x0016c4ea in __libc_message () from /lib/tls/libc.so.6
#2 0x00172c6f in _int_free () from /lib/tls/libc.so.6
#3 0x00172fea in free () from /lib/tls/libc.so.6
#4 0x01287c44 in php_error_cb (type=1, error_filename=0xc36f894
theme.php(10) : eval()'d code,
error_lineno=9, format=0x1570b84 Maximum execution time of %d second%s
exceeded,
args=0xa0f6195c \036) at /tmp/php-5.2.13/main/main.c:836
#5 0x012c8b2a in zend_error (type=1,
format=0x1570b84 Maximum execution time of %d second%s exceeded)
at /tmp/php-5.2.13/Zend/zend.c:976
#6 0x012bd76d in zend_timeout (dummy=27) at
/tmp/php-5.2.13/Zend/zend_execute_API.c:1347
#7 signal handler called
#8 0x00175030 in malloc () from /lib/tls/libc.so.6
#9 0x00179cd0 in strdup () from /lib/tls/libc.so.6
#10 0x012879e7 in php_error_cb (type=2, error_filename=0xc36f894
theme.php(10) : eval()'d code,
error_lineno=9, format=0x15723f4 %s%s%s(): supplied argument is not a
valid %s resource,
args=0xa0f61d48 ÅKT\001ÅKT\001OjT\001FŽU\001x\035ö \001) at
/tmp/php-5.2.13/main/main.c:845
Lines of code from backtrace are:
833 /* store the error if it has changed */
834 if (display) {
835 if (PG(last_error_message)) {
836 free(PG(last_error_message));
837 }
838 if (PG(last_error_file)) {
839 free(PG(last_error_file));
840 }
841 if (!error_filename) {
842 error_filename = Unknown;
843 }
844 PG(last_error_type) = type;
845 PG(last_error_message) = strdup(buffer);
846 PG(last_error_file) = strdup(error_filename);
847 PG(last_error_lineno) = error_lineno;
Test script:
---
It's independent from scripts.
For last 12h on over 3mln requests we have only 15 such errors.
Expected result:
We expected not to receive sigsegv's for apache.
--
Edit bug report at http://bugs.php.net/bug.php?id=51319edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51319r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51319r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51319r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51319r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51319r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51319r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51319r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51319r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51319r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51319r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51319r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51319r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51319r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51319r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51319r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51319r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51319r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51319r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51319r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51319r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51319r=mysqlcfg
Bug #50918 [Com]: Access violation in php.exe (Bug #49626 redux)
Edit report at http://bugs.php.net/bug.php?id=50918edit=1 ID: 50918 Comment by: progunster at gmail dot com Reported by: hardon at online dot no Summary: Access violation in php.exe (Bug #49626 redux) Status: Feedback Type: Bug Package: Reproducible crash Operating System: win32 only - Windows PHP Version: 5.3.1 Assigned To: pajoye New Comment: Well, after reboot I can't reproduce it anymore. So, what i did: 1.) Installed httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi It Works! 2.) Changed httpd.conf, to disable http and enable https (also created self-signed certificates) 3.) Installed PHP from php-5.3.2-Win32-VC6-x86.msi Right after that httpd.exe was crashing on start. After reboot it all went gone. On another computer it was the same. Previous Comments: [2010-03-17 16:05:53] paj...@php.net When does this crash happen exactly? As you seem to be able to reproduce it, always, I would like to know how :) [2010-03-17 15:43:30] progunster at gmail dot com Added date.timezone = Europe/Kiev to [Date] section of php.ini, it didn't helped. Same error, same place. [2010-03-17 15:01:48] paj...@php.net btw, it is not windows specific, crashes occur on other platform as well. [2010-03-17 14:52:42] paj...@php.net Yes, current work around is to actually set the timezone in php.ini [2010-03-17 14:48:14] progunster at gmail dot com Looks like it's the same bug. Function Arg 1 Arg 2 Arg 3 Source php5ts!guess_timezone+1c 00b2c5c8 00e4b670 0001 php5ts!get_timezone_info+1b 00e4b670 00e531b0 0003 php5ts!php_format_date+1b 00ad5aa4 000b 4ba0da0c php5ts!php_log_err+de 010d2128 00e4b670 0006fb80 php5ts!php_error_cb+385 0020 00abf924 php5ts!zend_error+498 0020 00abf8d4 010e46b8 php5ts!php_verror+554 00abf7f8 0020 php5ts!php_error_docref0+23 00e4b670 0020 php5ts!php_load_extension+146 010e40d8 0001 php5ts!php_load_php_extension_cb+15 00e58828 00e4b670 00267d78 php5ts!zend_llist_apply+1c 00cb3bf4 0083afd0 00e4b670 php5ts!php_ini_register_extensions+25 00e4b670 0006fea8 0001 php5ts!php_module_startup+87c 007760a8 00776048 0001 php5apache2_2!php_apache2_startup+12 007760a8 007760a8 0001 php5apache2_2!php_apache_server_startup+7b 0026de18 00632140 005f2068 libhttpd!ap_run_post_config+33 0026de18 00632140 005f2068 httpd+176f 0003 00267a80 00262868 httpd+1fb2 00720065 004e 7ffdc000 kernel32!BaseProcessStart+23 00401ecf 78746341 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=50918 -- Edit this bug report at http://bugs.php.net/bug.php?id=50918edit=1
[PHP-BUG] Bug #51320 [NEW]: Modulus Fails with the number 2.32
From: Operating system: OSX, Linux PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:Modulus Fails with the number 2.32 Description: Tested on the following PHP versions: 5.3.2 (OSX) 5.2.5 (Linux, Codepad.org) 5.2.4 (Ubuntu) The following script improperly reports the modulus as 31 instead of 32, but doesn't seem to happen with any other numbers. Test script: --- ?php $number = 3.32; echo ($number * 100) % 100; Expected result: 32 Actual result: -- 31 -- Edit bug report at http://bugs.php.net/bug.php?id=51320edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51320r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51320r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51320r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51320r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51320r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51320r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51320r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51320r=needscript Try newer version: http://bugs.php.net/fix.php?id=51320r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51320r=support Expected behavior: http://bugs.php.net/fix.php?id=51320r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51320r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51320r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51320r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51320r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51320r=dst IIS Stability: http://bugs.php.net/fix.php?id=51320r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51320r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51320r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51320r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51320r=mysqlcfg
Bug #51320 [Opn]: Modulus Fails with the number 2.32
Edit report at http://bugs.php.net/bug.php?id=51320edit=1 ID: 51320 User updated by: woody dot gilk at gmail dot com Reported by: woody dot gilk at gmail dot com Summary: Modulus Fails with the number 2.32 Status: Open Type: Bug Package: *General Issues Operating System: OSX, Linux PHP Version: Irrelevant New Comment: Sorry, the test script $number value should be 2.32 not 3.32, the improper value of 31 is only reported for 2.32, no other numbers. Previous Comments: [2010-03-18 10:53:26] woody dot gilk at gmail dot com Description: Tested on the following PHP versions: 5.3.2 (OSX) 5.2.5 (Linux, Codepad.org) 5.2.4 (Ubuntu) The following script improperly reports the modulus as 31 instead of 32, but doesn't seem to happen with any other numbers. Test script: --- ?php $number = 3.32; echo ($number * 100) % 100; Expected result: 32 Actual result: -- 31 -- Edit this bug report at http://bugs.php.net/bug.php?id=51320edit=1
[PHP-BUG] Bug #51321 [NEW]: shows same ascii for two diferent french characters
From: Operating system: windows xp PHP version: 5.3.2 Package: *General Issues Bug Type: Bug Bug description:shows same ascii for two diferent french characters Description: shows same ascii for two different french characters Test script: --- ?php $char1=Ã ; $chart2=Ã; echo Ascii for char1 is =.ord($char1); echo br/; echo Ascii for char2 is =.ord($char2); ? Expected result: Ascii for char1 is = 224 Ascii for char1 is = 195 Actual result: -- Ascii for char1 is = 195 Ascii for char1 is = 195 -- Edit bug report at http://bugs.php.net/bug.php?id=51321edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51321r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51321r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51321r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51321r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51321r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51321r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51321r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51321r=needscript Try newer version: http://bugs.php.net/fix.php?id=51321r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51321r=support Expected behavior: http://bugs.php.net/fix.php?id=51321r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51321r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51321r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51321r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51321r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51321r=dst IIS Stability: http://bugs.php.net/fix.php?id=51321r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51321r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51321r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51321r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51321r=mysqlcfg
Bug #51321 [Opn]: shows same ascii for two diferent french characters
Edit report at http://bugs.php.net/bug.php?id=51321edit=1 ID: 51321 User updated by: sharad dot tale at gmail dot com Reported by: sharad dot tale at gmail dot com Summary: shows same ascii for two diferent french characters Status: Open Type: Bug Package: *General Issues Operating System: windows xp PHP Version: 5.3.2 New Comment: Expected result: Ascii for char1 is = 224 Ascii for char2 is = 195 Actual result: -- Ascii for char1 is = 195 Ascii for char2 is = 195 Previous Comments: [2010-03-18 12:12:11] sharad dot tale at gmail dot com Description: shows same ascii for two different french characters Test script: --- ?php $char1=Ã ; $chart2=Ã; echo Ascii for char1 is =.ord($char1); echo br/; echo Ascii for char2 is =.ord($char2); ? Expected result: Ascii for char1 is = 224 Ascii for char1 is = 195 Actual result: -- Ascii for char1 is = 195 Ascii for char1 is = 195 -- Edit this bug report at http://bugs.php.net/bug.php?id=51321edit=1
Req #5311 [Tbd-Csd]: implement checkdnsrr() and getmxrr() on windows
Edit report at http://bugs.php.net/bug.php?id=5311edit=1 ID: 5311 Updated by: ka...@php.net Reported by: steve at tradinglinx dot com Summary: implement checkdnsrr() and getmxrr() on windows -Status: To be documented +Status: Closed Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: W2000 PHP Version: 4.0.1 Assigned To: kalle New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Already fixed Previous Comments: [2009-01-06 22:31:15] php at hm2k dot org I love the fact that I was just writing about this as it was updated: http://www.hm2k.com/posts/php-getmxrr-support-for-windows *grin* [2009-01-06 21:50:30] paj...@php.net tbd [2009-01-06 20:52:36] paj...@php.net As a new year present, all DNS functions are now available on windows, 5.3 and 6 (head). Waiting my extra slice of cakes. [2003-01-28 18:28:49] poll...@php.net Windows users can get this functionality from the PEAR class Net_DNS. http://pear.php.net/net_dns [2001-02-24 13:47:02] jmo...@php.net Both of these are #Defined out in the source code.. someone needs too look for a win32 implmentation of these at some point (dns.c:170 #if HAVE_BINDLIB !(defined(__BEOS__)||defined(PHP_WIN32))). Changing to Feature Change Request. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5311 -- Edit this bug report at http://bugs.php.net/bug.php?id=5311edit=1
Bug #50811 [Opn-Fbk]: mssql_bind fails to bind parameters greater than 256 characters long
Edit report at http://bugs.php.net/bug.php?id=50811edit=1 ID: 50811 Updated by: ka...@php.net Reported by: paul at dezinnia dot com Summary: mssql_bind fails to bind parameters greater than 256 characters long -Status: Open +Status: Feedback Type: Bug Package: MSSQL related Operating System: Windows Vista PHP Version: 5.2.12 New Comment: Does mssql_bind() issue any warning or return false? Previous Comments: [2010-01-20 23:05:38] paul at dezinnia dot com Description: using the mssql database extension, i am attempting to bind a parameter of type nvarchar(1999) to a stored procedure. Everything works as expected except when the length of the parameter exceeds 256 chracters. In the case of a parameter length in excess of 256 characters the following message is returned by the DB server. Procedure or function 'FunctionName' expects parameter '@ParameterName', which was not supplied. Reproduce code: --- --- From manual page: function.mssql-bind --- this code won't reproduce the bug since you don't have access to my database...but i'm including it here so you you can be sure i'm not just getting a syntax error... $sp = mssql_init(dbo.AddSnippet, $db); $b = mssql_bind($sp, @SnippetName, $snippetName, SQLVARCHAR, false, false, 120); $b = mssql_bind($sp, @SnippetDescription, $snippetDescription, SQLVARCHAR, false, false, 480); $b = mssql_bind($sp, @SnippetContent, $snippetContent, SQLVARCHAR, false, false, 1999); $b = mssql_bind($sp, @tagstring, $tagstring, SQLVARCHAR, false, false, 1999); $b = mssql_bind($sp, @TagUserID, $tagUserID, SQLINT4); mssql_execute($sp); Expected result: The stored procedure should add a record to the database and is designed to store nvarchar values of lengths up to 1999 characters. Actual result: -- When the parameter length exceeds 256 characters, an error occurs. When the parameter length is =256 characters, no error occurs. -- Edit this bug report at http://bugs.php.net/bug.php?id=50811edit=1
Bug #49825 [Opn]: PHP_SELF duplicate path
Edit report at http://bugs.php.net/bug.php?id=49825edit=1 ID: 49825 Updated by: ka...@php.net Reported by: michaels at sc dot edu Summary: PHP_SELF duplicate path Status: Open Type: Bug Package: IIS related Operating System: Windows Server 2000 PHP Version: 5.3.0 New Comment: What SAPI module have you installed PHP as in IIS? FastCGI or ISAPI? Previous Comments: [2009-10-13 15:50:13] michaels at sc dot edu No, the full path does not contain non-ASCII chars, as in bug report 49840. [2009-10-12 11:09:54] sjo...@php.net See also Bug #49840 PHP_SELF returns incorrect value. Does the full path of index.php contains non-ASCII characters? [2009-10-09 21:02:31] michaels at sc dot edu Description: This issue is the same as reported in Bug #45637 but is happening with IIS5 running on Server 2000. The variable: _SERVER[PHP_SELF] /forums/adm/index.php/forums/adm/index.php should be _SERVER[PHP_SELF] /forums/adm/index.php This is causing phpBB version 3 to operate incorrectly, by providing an incorrect connection string. Reproduce code: --- These are vars from the info page - please note _SERVER[PHP_SELF]: _SERVER[SERVER_PORT] 80 _SERVER[SERVER_PORT_SECURE] 0 _SERVER[SERVER_PROTOCOL] HTTP/1.1 _SERVER[SERVER_SOFTWARE] Microsoft-IIS/5.0 _SERVER[SystemDrive] C: _SERVER[SystemRoot] C:\WINNT _SERVER[TEMP] C:\WINNT\TEMP _SERVER[TMP] C:\WINNT\TEMP _SERVER[USERPROFILE] C:\Documents and Settings\WWW\ASPNET _SERVER[windir] C:\WINNT _SERVER[SCRIPT_FILENAME] D:\Inetpub\phpBB3\adm\index.php _SERVER[PHP_SELF] /forums/adm/index.php/forums/adm/index.php _SERVER[REQUEST_TIME] 1255105911 Expected result: _SERVER[PHP_SELF] /forums/adm/index.php Actual result: -- _SERVER[PHP_SELF] /forums/adm/index.php/forums/adm/index.php -- Edit this bug report at http://bugs.php.net/bug.php?id=49825edit=1
Bug #49825 [Opn-Fbk]: PHP_SELF duplicate path
Edit report at http://bugs.php.net/bug.php?id=49825edit=1 ID: 49825 Updated by: ka...@php.net Reported by: michaels at sc dot edu Summary: PHP_SELF duplicate path -Status: Open +Status: Feedback Type: Bug Package: IIS related Operating System: Windows Server 2000 PHP Version: 5.3.0 Previous Comments: [2010-03-18 16:43:15] ka...@php.net What SAPI module have you installed PHP as in IIS? FastCGI or ISAPI? [2009-10-13 15:50:13] michaels at sc dot edu No, the full path does not contain non-ASCII chars, as in bug report 49840. [2009-10-12 11:09:54] sjo...@php.net See also Bug #49840 PHP_SELF returns incorrect value. Does the full path of index.php contains non-ASCII characters? [2009-10-09 21:02:31] michaels at sc dot edu Description: This issue is the same as reported in Bug #45637 but is happening with IIS5 running on Server 2000. The variable: _SERVER[PHP_SELF] /forums/adm/index.php/forums/adm/index.php should be _SERVER[PHP_SELF] /forums/adm/index.php This is causing phpBB version 3 to operate incorrectly, by providing an incorrect connection string. Reproduce code: --- These are vars from the info page - please note _SERVER[PHP_SELF]: _SERVER[SERVER_PORT] 80 _SERVER[SERVER_PORT_SECURE] 0 _SERVER[SERVER_PROTOCOL] HTTP/1.1 _SERVER[SERVER_SOFTWARE] Microsoft-IIS/5.0 _SERVER[SystemDrive] C: _SERVER[SystemRoot] C:\WINNT _SERVER[TEMP] C:\WINNT\TEMP _SERVER[TMP] C:\WINNT\TEMP _SERVER[USERPROFILE] C:\Documents and Settings\WWW\ASPNET _SERVER[windir] C:\WINNT _SERVER[SCRIPT_FILENAME] D:\Inetpub\phpBB3\adm\index.php _SERVER[PHP_SELF] /forums/adm/index.php/forums/adm/index.php _SERVER[REQUEST_TIME] 1255105911 Expected result: _SERVER[PHP_SELF] /forums/adm/index.php Actual result: -- _SERVER[PHP_SELF] /forums/adm/index.php/forums/adm/index.php -- Edit this bug report at http://bugs.php.net/bug.php?id=49825edit=1
Bug #48852 [Opn-Fbk]: php windows save file to remote share strange access denied
Edit report at http://bugs.php.net/bug.php?id=48852edit=1 ID: 48852 Updated by: ka...@php.net Reported by: trutas dot ctx at gmail dot com Summary: php windows save file to remote share strange access denied -Status: Open +Status: Feedback Type: Bug Package: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: Is this also reproducable on PHP 5.3.2? Previous Comments: [2009-07-17 10:06:52] trutas dot ctx at gmail dot com don't know if it helps, but here are some example details from phpinfo(); _SERVER[APPL_MD_PATH] /LM/W3SVC/1897346991/Root/webservices/Cacher _SERVER[APPL_PHYSICAL_PATH] \\ptlisi020dat\intraroot$\CIO\Webservices\Cacher\ I haven't tried using APPL_MD_PATH, but with APPL_PHYSICAL_PATH it doesn't work. [2009-07-08 15:56:48] trutas dot ctx at gmail dot com i have installed and configured as recommended at http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/ can i further configure the FastCGI/PHP user anywhere else? IIS user is configured correctly (- home directory with Run as trustedDomain\iisuser) and the destination folder has trustedDomain\iisuser modify and everyone modify . Regards, [2009-07-08 15:18:27] paj...@php.net Be sure that you configured the user correctly or that the user has the correct access. [2009-07-08 15:15:19] trutas dot ctx at gmail dot com FastCGI [2009-07-08 15:13:50] trutas dot ctx at gmail dot com Note: test.php is located at \\share\intraroot$\site\ i've just tested it further and tryed a few workarounds: - it doesn't work with relative path (since both files are within the same share) ..\\folder\\file.txt; - it doesn't work with dirname(__FILE__).\\..\\folder\\file.txt; - does not work with forward slashes //share/... - the error is permission denied even if the destination folder doesn't exist - i've found this because at a time i had wrongly typed share\\intraroot$folder\\file.txt - that does not exist; I'm guessing it has something to do with the home directory in IIS being on a remote share - the production servers are clustered... Every other technology (vbscript, .NET) on IIS accesses the shares normally. 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=48852 -- Edit this bug report at http://bugs.php.net/bug.php?id=48852edit=1
Bug #48852 [Fbk-Opn]: php windows save file to remote share strange access denied
Edit report at http://bugs.php.net/bug.php?id=48852edit=1 ID: 48852 User updated by: trutas dot ctx at gmail dot com Reported by: trutas dot ctx at gmail dot com Summary: php windows save file to remote share strange access denied -Status: Feedback +Status: Open Type: Bug Package: IIS related Operating System: Windows Server 2003 x64 IIS6.0 -PHP Version: 5.3.0 +PHP Version: 5.3.2 New Comment: Apparently it's ok now. I have no idea what solved it and whether it was the administration team changed something on permissions/users or the PHP Version update :/ Thanks Previous Comments: [2010-03-18 16:44:38] ka...@php.net Is this also reproducable on PHP 5.3.2? [2009-07-17 10:06:52] trutas dot ctx at gmail dot com don't know if it helps, but here are some example details from phpinfo(); _SERVER[APPL_MD_PATH] /LM/W3SVC/1897346991/Root/webservices/Cacher _SERVER[APPL_PHYSICAL_PATH] \\ptlisi020dat\intraroot$\CIO\Webservices\Cacher\ I haven't tried using APPL_MD_PATH, but with APPL_PHYSICAL_PATH it doesn't work. [2009-07-08 15:56:48] trutas dot ctx at gmail dot com i have installed and configured as recommended at http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/ can i further configure the FastCGI/PHP user anywhere else? IIS user is configured correctly (- home directory with Run as trustedDomain\iisuser) and the destination folder has trustedDomain\iisuser modify and everyone modify . Regards, [2009-07-08 15:18:27] paj...@php.net Be sure that you configured the user correctly or that the user has the correct access. [2009-07-08 15:15:19] trutas dot ctx at gmail dot com FastCGI 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=48852 -- Edit this bug report at http://bugs.php.net/bug.php?id=48852edit=1
Bug #48852 [Opn-Bgs]: php windows save file to remote share strange access denied
Edit report at http://bugs.php.net/bug.php?id=48852edit=1 ID: 48852 Updated by: paj...@php.net Reported by: trutas dot ctx at gmail dot com Summary: php windows save file to remote share strange access denied -Status: Open +Status: Bogus Type: Bug Package: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.2 New Comment: not a bug bogus :) Previous Comments: [2010-03-18 17:14:02] trutas dot ctx at gmail dot com Apparently it's ok now. I have no idea what solved it and whether it was the administration team changed something on permissions/users or the PHP Version update :/ Thanks [2010-03-18 16:44:38] ka...@php.net Is this also reproducable on PHP 5.3.2? [2009-07-17 10:06:52] trutas dot ctx at gmail dot com don't know if it helps, but here are some example details from phpinfo(); _SERVER[APPL_MD_PATH] /LM/W3SVC/1897346991/Root/webservices/Cacher _SERVER[APPL_PHYSICAL_PATH] \\ptlisi020dat\intraroot$\CIO\Webservices\Cacher\ I haven't tried using APPL_MD_PATH, but with APPL_PHYSICAL_PATH it doesn't work. [2009-07-08 15:56:48] trutas dot ctx at gmail dot com i have installed and configured as recommended at http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/ can i further configure the FastCGI/PHP user anywhere else? IIS user is configured correctly (- home directory with Run as trustedDomain\iisuser) and the destination folder has trustedDomain\iisuser modify and everyone modify . Regards, [2009-07-08 15:18:27] paj...@php.net Be sure that you configured the user correctly or that the user has the correct access. 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=48852 -- Edit this bug report at http://bugs.php.net/bug.php?id=48852edit=1
[PHP-BUG] Bug #51325 [NEW]: DOMDocument::load() UTF-8 limitation
From:
Operating system: Windows WAMP + LAMP(?)
PHP version: 5.3.2
Package: DOM XML related
Bug Type: Bug
Bug description:DOMDocument::load() UTF-8 limitation
Description:
The DOMDocument::load() function ONLY loads UTF-8 encoded files.
Ex: 'article.php' contains :
$xmlDoc = new DOMDocument();
$page = 'article.xsl';
$xmlDoc-load($page);
$xmlDoc-load('cours.xml');
Let's consider 'article.xsl' contains '... Précédent ...' (not pure ASCII
chars)
If the content of 'article.xsl' is iso-8859-1 encoded, the subsequent
error
appears (same if 'cours.xml' is iso-8859-1 encoded):
DOMDocument::load() [domdocument.load]: Input is not proper UTF-8,
indicate encoding ! Bytes: 0xE9 0x62 0x75 0x74 in
file:///C:/wamp/www/xsl2/article.xsl, line: 71 in
C:\wamp\www\xsl2\article.php on line 13
So, it's imperative to UTF-8 encode 'cours.xml' and 'article.xsl'.
Of course $page = utf8_encode($page); ... is of no use,
because the 'utf8_encode' only operates on the string 'article.xsl', and
not on the file content !.
CONCLUSION : It's not really a BUG in the -load() function.
But it would be really important to have a supplementary optional
parameter,
indicating the encoding of the incoming file:
-Desired improvment ---
Add an optional parameter describing the $file actual encoding:
$xmlDoc-load($page, 'iso-8859-1');
DOMDocument::load( string $file [, string $encoding])
The $encoding optional parameter thus would be useful to describe the
actual $file encoding (if not UTF-8).
--- END --
Test script:
---
[test.php]
?php
$xmlDoc = new DOMDocument();
$xmlDoc-load(cours.xml);
?
[cours.xml] (no matter the line encoding...
The problem is caused by the 'é' from 'éclair'...)
?xml version=1.0 encoding=UTF-8?
root
chapitre titre=Titre du chapitre 1
partie titre=Titre de la partie 1
Texte éclair
/partie
/chapitre
/root
(displays):
Warning: DOMDocument::load() [domdocument.load]: Input is not proper UTF-8,
indicate encoding ! Bytes: 0xE9 0x63 0x6C 0x61 in
file:///C:/wamp/www/xsl2/cours.xml, line: 5 in C:\wamp\www\xsl2\test.php on
line 3
--
Edit bug report at http://bugs.php.net/bug.php?id=51325edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51325r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51325r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51325r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51325r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51325r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51325r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51325r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51325r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51325r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51325r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51325r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51325r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51325r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51325r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51325r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51325r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51325r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51325r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51325r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51325r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51325r=mysqlcfg
Doc #51112 [Opn]: list() misbehaviour
Edit report at http://bugs.php.net/bug.php?id=51112edit=1
ID: 51112
Updated by: ka...@php.net
Reported by: post at oliver-schieche dot de
Summary: list() misbehaviour
Status: Open
Type: Documentation Problem
-Package: Documentation problem
+Package: Scripting Engine problem
Operating System: Debian (etch)
PHP Version: 5.2.12
New Comment:
Can this either be classfied as a scripting engine bug. If it indeed is
a documentation issue then re-classify this as a To be Documented
documentation issue for the developer that picks this one up.
Previous Comments:
[2010-02-22 12:58:56] post at oliver-schieche dot de
Why document an obvious bug instead of fixing it? How would you
document/explain this?
If this works:
function ret($array) {return $array;}
$b = array('foo','bar');
list($a,$b) = ret($b);
But this doesn't:
function ret($array) {return $array;}
$b = array('foo','bar');
list($a,$b) = ret($b);
Then there's a referencing error hidden somewhere...
[2010-02-22 12:42:52] paj...@php.net
That's pretty much the same thing you can see with foreach, the array
should not be altered while looping (the array itself, the data of a
given element can be altered). No bug here, but should be documented.
[2010-02-22 12:38:52] post at oliver-schieche dot de
Description:
When assigning an array to a list() of variables and using the input
array as a member of that list(), unexpected results are returned.
Reproduce code:
---
$b = array('foo','bar');
list($a,$b) = $b;
$c = array('foo','bar');
list($c,$d) = $c;
Expected result:
$a == $c == 'foo'
$b == $d == 'bar'
Actual result:
--
$a == 'b'
$b == 'bar'
$c == 'foo'
$d == 'bar'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51112edit=1
Doc-Bug #36663 [Ver]: unexpected difference between zlib.output_compression and ob_gzhandler
Edit report at http://bugs.php.net/bug.php?id=36663edit=1 ID: 36663 Updated by: ka...@php.net Reported by: atom at smasher dot org Summary: unexpected difference between zlib.output_compression and ob_gzhandler Status: Verified -Type: Documentation Problem +Type: Bug -Package: Documentation problem +Package: Output Control Operating System: FreeBSD PHP Version: 4.4.2 New Comment: Re-classified for it to be confirmed behavoir, please change back to a documentation issue and as To be documented if this indeed is expected behavoir. Previous Comments: [2009-11-23 13:34:05] vr...@php.net I can confirm the behavior but could not find any place in the sources which explains it. [2006-03-09 16:46:57] atom at smasher dot org If nothing else, this would at least be a documentation bug. [2006-03-09 09:15:26] atom at smasher dot org Description: if php.ini has: output_handler = ob_gzhandler dynamically generated JPGs are output with gzip (Content-Encoding: gzip). if php.ini has (instead): zlib.output_compression = on dynamically generated JPGs are output without gzip. In both cases the HTTP request includes Accept-Encoding: gzip. It does seem stupid to attempt to compress a compressed image file, but I can't find any documentation that explains which way is the right way to do it, or how to override the default behavior. -- Edit this bug report at http://bugs.php.net/bug.php?id=36663edit=1
Bug #51325 [Opn-Bgs]: DOMDocument::load() UTF-8 limitation
Edit report at http://bugs.php.net/bug.php?id=51325edit=1
ID: 51325
Updated by: rricha...@php.net
Reported by: jean dot tiberghien at quetzalx dot fr
Summary: DOMDocument::load() UTF-8 limitation
-Status: Open
+Status: Bogus
Type: Bug
Package: DOM XML related
Operating System: Windows WAMP + LAMP(?)
PHP Version: 5.3.2
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 are passing an XML document which clearly states it is UTF-8 via the
xml
declaration ?xml version=1.0 encoding=UTF-8? so DOM expects UTF-8.
Set it to
the proper encoding. Already a feature request to pass an encoding when
*not*
specified by encoding param in xml declaration.
Previous Comments:
[2010-03-18 18:09:31] jean dot tiberghien at quetzalx dot fr
Description:
The DOMDocument::load() function ONLY loads UTF-8 encoded files.
Ex: 'article.php' contains :
$xmlDoc = new DOMDocument();
$page = 'article.xsl';
$xmlDoc-load($page);
$xmlDoc-load('cours.xml');
Let's consider 'article.xsl' contains '... Précédent ...' (not pure
ASCII chars)
If the content of 'article.xsl' is iso-8859-1 encoded, the subsequent
error
appears (same if 'cours.xml' is iso-8859-1 encoded):
DOMDocument::load() [domdocument.load]: Input is not proper UTF-8,
indicate encoding ! Bytes: 0xE9 0x62 0x75 0x74 in
file:///C:/wamp/www/xsl2/article.xsl, line: 71 in
C:\wamp\www\xsl2\article.php on line 13
So, it's imperative to UTF-8 encode 'cours.xml' and 'article.xsl'.
Of course $page = utf8_encode($page); ... is of no use,
because the 'utf8_encode' only operates on the string 'article.xsl', and
not on the file content !.
CONCLUSION : It's not really a BUG in the -load() function.
But it would be really important to have a supplementary optional
parameter,
indicating the encoding of the incoming file:
-Desired improvment ---
Add an optional parameter describing the $file actual encoding:
$xmlDoc-load($page, 'iso-8859-1');
DOMDocument::load( string $file [, string $encoding])
The $encoding optional parameter thus would be useful to describe the
actual $file encoding (if not UTF-8).
--- END --
Test script:
---
[test.php]
?php
$xmlDoc = new DOMDocument();
$xmlDoc-load(cours.xml);
?
[cours.xml] (no matter the line encoding...
The problem is caused by the 'é' from 'éclair'...)
?xml version=1.0 encoding=UTF-8?
root
chapitre titre=Titre du chapitre 1
partie titre=Titre de la partie 1
Texte éclair
/partie
/chapitre
/root
(displays):
Warning: DOMDocument::load() [domdocument.load]: Input is not proper
UTF-8, indicate encoding ! Bytes: 0xE9 0x63 0x6C 0x61 in
file:///C:/wamp/www/xsl2/cours.xml, line: 5 in C:\wamp\www\xsl2\test.php
on line 3
--
Edit this bug report at http://bugs.php.net/bug.php?id=51325edit=1
[PHP-BUG] Bug #51326 [NEW]: Closure must be used as object property
From:
Operating system: FreeBSD 7.1
PHP version: 5.3.2
Package: *General Issues
Bug Type: Bug
Bug description:Closure must be used as object property
Description:
If a class instance has a closure as property, PHP must call
$this-closure-__invoke() instead of say that method class::closure() does
not exist.
Test script:
---
?php
class foo
{
protected $closure = null;
function __construct(\closure $closure)
{
$this-closure = $closure;
}
function callClosure()
{
return $this-closure('Closure::__invoke() was called');
}
}
$foo = new foo(function($string) { echo $string; });
$foo-callClosure();
?
Expected result:
Closure::__invoke() was called
Actual result:
--
Call to undefined method foo::closure() in /path/to/script.php on line 14
--
Edit bug report at http://bugs.php.net/bug.php?id=51326edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51326r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51326r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51326r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51326r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51326r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51326r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51326r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51326r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51326r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51326r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51326r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51326r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51326r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51326r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51326r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51326r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51326r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51326r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51326r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51326r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51326r=mysqlcfg
Bug #49521 [Csd-ReO]: PDO fetchObject sets values before calling constructor
Edit report at http://bugs.php.net/bug.php?id=49521edit=1 ID: 49521 Updated by: da...@php.net Reported by: waps at pisem dot net Summary: PDO fetchObject sets values before calling constructor -Status: Closed +Status: Re-Opened Type: Bug Package: PDO related Operating System: Ubuntu 8.10 x64 PHP Version: 5.2.10 Assigned To: pierrick New Comment: According to the ML [1], Johannes, Felipe and Derick all agreed that this fix should be reverted, and instead the current behavior (values then constructor) should be properly documented. The desired behavior can be accomplished using the PDO::FETCH_PROPS_LATE option since 5.2.0. This means commit #290786 must be reverted in 5_2. It was already reverted in 5_3. (Commit #294903 [2]) [1] http://marc.info/?l=php-internalsm=126451457205904w=2 [2] http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/pdo/pdo_stmt.c? r1=293036r2=294903 Previous Comments: [2010-02-12 00:19:11] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294942 Log: merge 290786: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2010-02-11 22:14:06] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294903 Log: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2009-11-15 16:23:41] fel...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks for the patch. [2009-11-15 16:20:37] s...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionrevision=290786 Log: - Fixed bug #49521 (PDO fetchObject sets values before calling constructor) (patch by Pierrick) [2009-11-12 05:00:55] pierr...@php.net Patch available at: http://www.adoy.net/php/49521.PHP_5_2.patch http://www.adoy.net/php/49521.PHP_5_3.patch http://www.adoy.net/php/49521.PHP_6_0.patch 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=49521 -- Edit this bug report at http://bugs.php.net/bug.php?id=49521edit=1
[PHP-BUG] Req #51327 [NEW]: Perhaps there should be a way to explicitly dereference in PHP
From: Operating system: Linux (though it doesnt matter) PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:Perhaps there should be a way to explicitly dereference in PHP Description: It seems that the part of PHP that is responsible for minimizing the footprint of passing around data, at least within an object, does too good of a job, and the lack of an explicit dereference or a forced, perhaps recursively-acting assign by value operator creates an issue where a programmer can not explicitly dereference the data behind that referenced value, that, for example, is being pushed into an array, would lead to an array of referenced values (with vales that would not be what you would predict them to be) So the code: MyResult is a class meant to unify access to mysqli result data access between query and prepared statement. SQL is just a couple of commands to set up the testing environment (test table). The MyTest opens a connection and tries to get the data. Query results, which are passes back the array returned from mysqli's result fetch_array function are properly dereferenced in getArray method. The prepared statement results that are passed back as $this-bind_arr are not properly dereferenced, and get added to $ret as references, resulting in the final array that is filled with both id and value filled with the latest data set in the $this-bind_arr, which leads me to believe that this is a dereferencing issue, in this case id=3 and value=val3. If you add a print_r line to the while loop, you will see that with stored procedure results, every new result is passed back, all the values are updated to that result set. Hopefully this is short enough to describe the issue, -- Alex Test script: --- MyResult.php http://pastebin.com/qJRWySks SQL: create table test_table (id int not null auto_increment primary key, value varchar(8)); insert into test_table (`value`) values (val1), (val2), (val3); MyTest.php http://pastebin.com/AV6B79Vk Expected result: Prepared statement Array ( [0] = Array ( [id] = 1 [value] = val1 ) [1] = Array ( [id] = 2 [value] = val2 ) [2] = Array ( [id] = 3 [value] = val3 ) [3] = Query Array ( [0] = Array ( [id] = 1 [value] = val1 ) [1] = Array ( [id] = 2 [value] = val2 ) [2] = Array ( [id] = 3 [value] = val3 ) [3] = Actual result: -- Prepared statement Array ( [0] = Array ( [id] = 3 [value] = val3 ) [1] = Array ( [id] = 3 [value] = val3 ) [2] = Array ( [id] = 3 [value] = val3 ) [3] = ) Query Array ( [0] = Array ( [id] = 1 [value] = val1 ) [1] = Array ( [id] = 2 [value] = val2 ) [2] = Array ( [id] = 3 [value] = val3 ) [3] = -- Edit bug report at http://bugs.php.net/bug.php?id=51327edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51327r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51327r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51327r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51327r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51327r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51327r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51327r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51327r=needscript Try newer version: http://bugs.php.net/fix.php?id=51327r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51327r=support Expected behavior: http://bugs.php.net/fix.php?id=51327r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51327r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51327r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51327r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51327r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51327r=dst IIS Stability: http://bugs.php.net/fix.php?id=51327r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51327r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51327r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51327r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51327r=mysqlcfg
Bug #51309 [Opn-Bgs]: Apache cannot start
Edit report at http://bugs.php.net/bug.php?id=51309edit=1 ID: 51309 Updated by: ka...@php.net Reported by: jamone_95134 at yahoo dot com Summary: Apache cannot start -Status: Open +Status: Bogus Type: Bug Package: Apache2 related Operating System: win32 only - Windows XP SP3 PHP Version: 5.3.2 New Comment: I tried on various setups with both Apache 2.2.15 and 2.2.16 using VC6 x86 versions of both PHP 5.2.13 and 5.3.2 and I cannot reproduce the issue. Adding the PHP installation to the %PATH% fixes all the loading issues (deps). Previous Comments: [2010-03-17 02:07:36] jamone_95134 at yahoo dot com Yes the PHP directory is in my path, just check the output sent earlier, yes the C:\Program Files\PHP\ext directory exists. C:\Program Files\PHP\extdir Volume in drive C has no label. Volume Serial Number is 1747-5C20 Directory of C:\Program Files\PHP\ext 03/10/2010 09:44 AMDIR . 03/10/2010 09:44 AMDIR .. 03/03/2010 08:46 PM 102,471 php_bz2.dll 03/03/2010 08:46 PM 274,504 php_curl.dll 03/03/2010 08:46 PM53,320 php_exif.dll 03/03/2010 08:46 PM 1,839,180 php_fileinfo.dll 03/03/2010 08:46 PM 831,559 php_gd2.dll 03/03/2010 08:46 PM45,131 php_gettext.dll 03/03/2010 08:46 PM 819,272 php_imap.dll 03/03/2010 08:46 PM 122,952 php_intl.dll 03/03/2010 08:46 PM 151,624 php_ldap.dll 03/03/2010 08:46 PM 1,876,044 php_mbstring.dll 03/03/2010 08:46 PM45,129 php_mysql.dll 03/03/2010 08:46 PM90,186 php_mysqli.dll 03/03/2010 08:46 PM81,995 php_openssl.dll 03/03/2010 08:46 PM32,845 php_pdo_mysql.dll 03/03/2010 08:46 PM32,844 php_pdo_odbc.dll 03/03/2010 08:46 PM32,845 php_pdo_pgsql.dll 03/03/2010 08:46 PM 507,982 php_pdo_sqlite.dll 03/03/2010 08:46 PM 102,473 php_pgsql.dll 03/03/2010 08:46 PM24,649 php_shmop.dll 03/03/2010 08:46 PM 254,024 php_soap.dll 03/03/2010 08:46 PM49,227 php_sockets.dll 03/03/2010 08:46 PM 516,171 php_sqlite3.dll 03/03/2010 08:46 PM 307,272 php_tidy.dll 03/03/2010 08:46 PM73,802 php_xmlrpc.dll 03/03/2010 08:46 PM 221,255 php_xsl.dll 25 File(s) 8,488,756 bytes 2 Dir(s) 69,509,390,336 bytes free C:\Program Files\PHP\ext I know you are trying to help, but I have looked at all these pedestrian issues such as missing dll's, path, etc., already and I still have this problem. This only began after upgrading both my Apache server and PHP. I have removed them and re-installed them several times, and I still have the same issue. [2010-03-16 21:05:44] paj...@php.net Are you sure about: extension_dir = C:\Program Files\PHP\ext = C:\Program Files\PHP\ext Also please be sure to fix these warnings, especially the timezone. are you sure that C:\Program Files\PHP is in your PATH? So that PHP can find the DLL it needs when it is loaded by apache? [2010-03-16 20:14:02] jamone_95134 at yahoo dot com Description: Sorry I had to begin a new thread, but I could not login to my previous report #51270, as it was saying my saved password was no longer valid, and #51270 seems to have been declared bogus. To continue #51270: php -m produces the following: C:\Documents and Settings\foophp -m Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone _set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ' America/Los_Angeles' for '-7.0/DST' instead in Unknown on line 0 Warning: Directive 'register_globals' is deprecated in PHP 5.3 and greater in Un known on line 0 Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone _set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ' America/Los_Angeles' for '-7.0/DST' instead in Unknown on line 0 Warning: Directive 'magic_quotes_runtime' is deprecated in PHP 5.3 and greater i n Unknown on line 0 [PHP Modules] bcmath bz2 calendar com_dotnet Core ctype curl date dom ereg exif fileinfo filter ftp gd gettext hash iconv imap intl json ldap libxml mbstring mcrypt mhash mysql mysqli mysqlnd odbc
Bug #49521 [ReO-Csd]: PDO fetchObject sets values before calling constructor
Edit report at http://bugs.php.net/bug.php?id=49521edit=1 ID: 49521 Updated by: fel...@php.net Reported by: waps at pisem dot net Summary: PDO fetchObject sets values before calling constructor -Status: Re-Opened +Status: Closed Type: Bug Package: PDO related Operating System: Ubuntu 8.10 x64 PHP Version: 5.2.10 Assigned To: pierrick New Comment: Reverted in 5_2 branch. Previous Comments: [2010-03-18 23:07:52] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=296361 Log: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2010-03-18 21:44:10] da...@php.net According to the ML [1], Johannes, Felipe and Derick all agreed that this fix should be reverted, and instead the current behavior (values then constructor) should be properly documented. The desired behavior can be accomplished using the PDO::FETCH_PROPS_LATE option since 5.2.0. This means commit #290786 must be reverted in 5_2. It was already reverted in 5_3. (Commit #294903 [2]) [1] http://marc.info/?l=php-internalsm=126451457205904w=2 [2] http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/pdo/pdo_stmt.c? r1=293036r2=294903 [2010-02-12 00:19:11] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294942 Log: merge 290786: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2010-02-11 22:14:06] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=294903 Log: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2009-11-15 16:23:41] fel...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks for the patch. 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=49521 -- Edit this bug report at http://bugs.php.net/bug.php?id=49521edit=1
Bug #42849 [Com]: Configuration File (php.ini) Path incorrect
Edit report at http://bugs.php.net/bug.php?id=42849edit=1 ID: 42849 Comment by: rsberger1 at hotmail dot com Reported by: inglis-php at yahoo dot com dot au Summary: Configuration File (php.ini) Path incorrect Status: No Feedback Type: Bug Package: *General Issues Operating System: win xp pro PHP Version: 5.2.4 New Comment: Since this bug was suspended due to no feedback, I thought I'd supply the requested feedback and hope that someone would fix this annoyance. The two places in my phpinfo output regarding php.ini are: Configuration File (php.ini) Path C:\Windows Loaded Configuration File D:\Apps\MyFolder\php-5.3.2\php.ini Apparently my php.ini is being loaded from my php-5.3.2 folder, but phpinfo erroneously reports php.ini's path as C:\Windows. Previous Comments: [2009-12-28 05:33:09] u2gohome at gmail dot com Hi. For me this problem was only occurring when php was executed via apache. Executing php -i from the command line listed the mysql extension whereas a phpinfo() request via the browser did not. Try adding the following line to your apache httpd.conf file (to point to the directory containing php.ini) eg. PHPIniDir 'C:\php' Adding this line changed phpinfo()'s reported 'Loaded Configuration File' from (none) to C:\php\php.ini, and mysql started talking. However, phpinfo() still reports c:\windows as the php.ini directory. Cheers, Matt [2009-10-12 11:48:21] alim at fourplusadvertising dot com I am quite confused with this whole thing on my mac (leopard).. i thought my PHP was the perfect installation..;-).. till i realised that my PHP.ini setting of upload_max_filesize was still 2 MB inspite of me having changed it to 32 MB!!.. how do i get php to use the php.ini values and not the default.. I am facing the same issue on my imac.. there's some loaded configuration file which shows /private/etc while the Configuration File (php.ini) Path is /etc But they are I think symlinked.. but whatever I edit in the php.ini does not reflect in the phpinfo().. please help.. [2009-09-16 18:41:00] misc at imerk dot net I've just run into this problem. Using win2k8 r2 x64. And php 5.2.5 I copied the php installation that is working on a win2k3 server to this win2k8 box. I put the path to the ini file in both the system PATH variable as well as creating a reg key in local_machine/software/php5/iniFilePath = C:\php5 I still get (none) for the loaded config file. This is working fine on the win2k3 machine though. [2009-09-05 03:57:57] headnok at yahoo dot com I had the same damn problem and was pulling my hair out for a week. Please!!! Either instruct the users to move the php.ini file into the C:\windows directory your installation instructions or fix the problem! Please!!! [2008-12-11 06:22:55] yaddayadda at mailinator dot com I'm a new user of PHP/MySQL. I installed both and phpMyAdmin with no deviation from the instructions and could not get phpMyAdmin to work at all (it could not load the mysql extension). Despite reading numerous posts about what to uncomment in php.ini and what to add to the PATH, whatever I did did not seem to have any effect. Only after I ran phpinfo() did I find out that the path to php.ini was somehow pointing the Windows folder. I was editing php.ini in C:\PHP. There are many, many frustrated students and beginners out there having this exact issue. They don't know it is a bug. They are told to just copy php.ini to your Windows folder as a fix. I did not want to do this because I set the PATH to C:\PHP so I knew it should be looking there and NOT in C:\Windows (because there was no php.ini there, it should continue looking through the locations specified in PATH). I still do not know how to change this and ended up moving the file out of frustration and everything began to work. So many people are experiencing this frustration and wasting hours trying to fix it. Some are even giving up and moving to hosts that already have PHP installed rather than continue to learn on their own. If you install PHP to C:\PHP, the php.ini file it looks for should be there! 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=42849 -- Edit this bug report at http://bugs.php.net/bug.php?id=42849edit=1
Bug #50475 [Com]: DateTime::setISODate followed by DateTime::setTime
Edit report at http://bugs.php.net/bug.php?id=50475edit=1
ID: 50475
Comment by: Eric at Deplagne dot name
Reported by: nandobrt at gmail dot com
Summary: DateTime::setISODate followed by DateTime::setTime
Status: Open
Type: Bug
Package: Date/time related
Operating System: Windows XP
PHP Version: 5.3SVN-2009-12-15 (snap)
New Comment:
same with php 5.3.1 on debian squeeze
Previous Comments:
[2010-01-19 13:05:37] yoarvi at gmail dot com
date_isodate_set should reset the have_relative flag once it has updated
the date/time value.
The following patch (5.3 svn tree) includes a fix and a test case for
this bug:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -3033,6 +3033,8 @@
timelib_update_ts(dateobj-time, NULL);
+ dateobj-time-have_relative = 0;
+
RETURN_ZVAL(object, 1, 0);
}
/* }}} */
Index: ext/date/tests/bug50475.phpt
===
--- ext/date/tests/bug50475.phpt(revision 0)
+++ ext/date/tests/bug50475.phpt(revision 0)
@@ -0,0 +1,16 @@
+--TEST--
+Bug #50475 (DateTime::setISODate followed by DateTime::setTime)
+--FILE--
+?php
+date_default_timezone_set('Asia/Calcutta');
+
+$date = new DateTime('18-01-2009 00:00:00');
+$date-setISODate(2009, 6, 1);
+echo $date-format('Y-m-d H:i:s') . \n;
+$date-setTime(8, 0);
+echo $date-format('Y-m-d H:i:s') . \n;
+?
+--EXPECT--
+2009-02-02 00:00:00
+2009-02-02 08:00:00
+
[2009-12-15 03:23:53] nandobrt at gmail dot com
Description:
Calling setTime on a DateTime object after having called setISODate will
change its date.
Reproduce code:
---
$date = new DateTime();
$date-setISODate(2009, 6);
echo $date-format('Y-m-d H:i:s') . br /;
$date-setTime(8, 0);
echo $date-format('Y-m-d H:i:s');
Expected result:
2009-02-02 01:11:15
2009-02-02 08:00:00
Actual result:
--
2009-02-02 01:11:15
2009-03-06 08:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=50475edit=1
Bug #50475 [Opn-Asn]: DateTime::setISODate followed by DateTime::setTime
Edit report at http://bugs.php.net/bug.php?id=50475edit=1
ID: 50475
Updated by: fel...@php.net
Reported by: nandobrt at gmail dot com
Summary: DateTime::setISODate followed by DateTime::setTime
-Status: Open
+Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Windows XP
PHP Version: 5.3SVN-2009-12-15 (snap)
-Assigned To:
+Assigned To: derick
Previous Comments:
[2010-03-19 00:55:28] Eric at Deplagne dot name
same with php 5.3.1 on debian squeeze
[2010-01-19 13:05:37] yoarvi at gmail dot com
date_isodate_set should reset the have_relative flag once it has updated
the date/time value.
The following patch (5.3 svn tree) includes a fix and a test case for
this bug:
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 293574)
+++ ext/date/php_date.c (working copy)
@@ -3033,6 +3033,8 @@
timelib_update_ts(dateobj-time, NULL);
+ dateobj-time-have_relative = 0;
+
RETURN_ZVAL(object, 1, 0);
}
/* }}} */
Index: ext/date/tests/bug50475.phpt
===
--- ext/date/tests/bug50475.phpt(revision 0)
+++ ext/date/tests/bug50475.phpt(revision 0)
@@ -0,0 +1,16 @@
+--TEST--
+Bug #50475 (DateTime::setISODate followed by DateTime::setTime)
+--FILE--
+?php
+date_default_timezone_set('Asia/Calcutta');
+
+$date = new DateTime('18-01-2009 00:00:00');
+$date-setISODate(2009, 6, 1);
+echo $date-format('Y-m-d H:i:s') . \n;
+$date-setTime(8, 0);
+echo $date-format('Y-m-d H:i:s') . \n;
+?
+--EXPECT--
+2009-02-02 00:00:00
+2009-02-02 08:00:00
+
[2009-12-15 03:23:53] nandobrt at gmail dot com
Description:
Calling setTime on a DateTime object after having called setISODate will
change its date.
Reproduce code:
---
$date = new DateTime();
$date-setISODate(2009, 6);
echo $date-format('Y-m-d H:i:s') . br /;
$date-setTime(8, 0);
echo $date-format('Y-m-d H:i:s');
Expected result:
2009-02-02 01:11:15
2009-02-02 08:00:00
Actual result:
--
2009-02-02 01:11:15
2009-03-06 08:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=50475edit=1
Bug #51310 [Opn-Bgs]: Using namespaces breaks generic object type hinting
Edit report at http://bugs.php.net/bug.php?id=51310edit=1
ID: 51310
Updated by: fel...@php.net
Reported by: ddebernardy at yahoo dot com
Summary: Using namespaces breaks generic object type hinting
-Status: Open
+Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: MacOS X
PHP Version: 5.3.2
New Comment:
The 'object' word doesn't have an special meaning on PHP type hinting.
Previous Comments:
[2010-03-17 00:45:17] ddebernardy at yahoo dot com
Description:
Specifying object as the type hint seems to be broken when using
namespaces.
Test script:
---
namespace A;
class X {}
function foo(object $bar) {}
foo(new X);
foo(new \stdClass);
Expected result:
foo(new X); // works
foo(new \stdClass); // works
Actual result:
--
foo(new X); // fails
foo(new \stdClass); // fails
--
Edit this bug report at http://bugs.php.net/bug.php?id=51310edit=1
Bug #36629 [Com]: SoapServer::handle() exits on SOAP faults
Edit report at http://bugs.php.net/bug.php?id=36629edit=1
ID: 36629
Comment by: druidmatrix at yahoo dot com
Reported by: ilya at iponweb dot net
Summary: SoapServer::handle() exits on SOAP faults
Status: Closed
Type: Bug
Package: SOAP related
Operating System: Debian Linux (testing)
PHP Version: 5CVS-2006-03-06 (snap)
Assigned To: dmitry
New Comment:
I am still having this problem on Fedora Core 10. PHP is:
[c...@fc10-test webservices]$ php -v
PHP 5.2.11 (cli) (built: Jan 4 2010 23:45:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
I am not able to catch the SoapFault on the server side at all - not
even by using a try-catch around $server-handle(). It looks like the
server is immediately generating the SoapFault and returning it to the
client; control never advances beyond the handle() call on the server
side.
Previous Comments:
[2006-03-10 12:49:31] dmi...@php.net
Fixed in CVS HEAD and PHP_5_1.
[2006-03-06 13:50:13] ilya at iponweb dot net
Description:
When calling SoapServer::handle() it exits after processing the SOAP
request if request handler returns a SoapFault object. It makes
impossible to do any work on the SOAP server side after processing
requests if they result in SoapFault.
I belive exactly the same issue was reported in bug report #31993 but
for some reason it was closed without actually fixing the problem in the
soap extension. I could reproduce the problem with PHP 5.1.1 and with
PHP snapshot 5.1-200603061130.
The test code demostrates this problem. It is a simple soap server with
two remotly callable functions: test1 and test2. The first of them
simply returns a string, the second returns a soap fault object. The
server is supposed to write a string to a log file after processing a
request. If you call remotly test1 function then you can see the string
in the log, if you call remotly test2 function then the log file is
empty.
Reproduce code:
---
?php
$server = new SoapServer(null, array('uri' = http://test-uri/;));
$h = fopen(/tmp/soap.log, w);
$server-addFunction(array('test1', 'test2'));
$server-handle();
fputs($h, 'TEST');
fclose($h);
function test1() {
return test1;
}
function test2() {
return new SoapFault(test2, test2);
}
?
Expected result:
A log message in file /tmp/soap.log
Actual result:
--
Nothing when calling remotly 'test2' function.
--
Edit this bug report at http://bugs.php.net/bug.php?id=36629edit=1
Bug #51312 [Opn]: include_once/require_once are case sensitive on OS X
Edit report at http://bugs.php.net/bug.php?id=51312edit=1 ID: 51312 User updated by: whatthejeff at gmail dot com Reported by: whatthejeff at gmail dot com -Summary: Case-insensitive include_once/require_once includes file more than once +Summary: include_once/require_once are case sensitive on OS X Status: Open Type: Bug Package: Scripting Engine problem Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: Further testing indicates that this bug does not exist for all case sensitive file systems. I could not reproduce this error using Windows. Previous Comments: [2010-03-17 05:36:02] whatthejeff at gmail dot com Description: With PHP 5.3.2 on OS X 10.6 I am able to include the same file multiple times using include_once() and require_once() Configurations: -- $ /usr/local/php-test/bin/php -v PHP 5.3.2 (cli) (built: Mar 16 2010 21:48:40) $ /usr/local/php-test/bin/php -i | grep config Configure Command = './configure' '--prefix=/usr/local/php-test' Test script: --- $ echo '?php echo included\n; ?' test.php $ php -r 'require_once(test.php); require_once(Test.php);' or $ php -r 'include_once(test.php); include_once(Test.php);' Expected result: included Actual result: -- included included -- Edit this bug report at http://bugs.php.net/bug.php?id=51312edit=1
