#49482 [Opn-Asn]: SOAP encoding although WSDL requires use='LITERAL'
ID: 49482
Updated by: dmi...@php.net
Reported By: joep at clickhere dot nl
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Ubuntu
PHP Version: 5.2.10
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2009-09-06 10:29:52] joep at clickhere dot nl
Description:
I was hunting a bug in our soap-client. 'xsi:type' appears in the xml,
even when the WSDL states 'use=literal'.
Our client works fine with 5.2.4, but since 5.2.7/5.2.8 its broken
(Also tested 5.2.9)
Came across this fix in ext/soap/php_encoding.c
+if (encode != enc style == SOAP_LITERAL) {
add_type = 1;
-}
Shouldn't that be:
if (encode != enc style == SOAP_ENCODED) {
add_type = 1;
}
--
Edit this bug report at http://bugs.php.net/?id=49482edit=1
#49362 [Csd-Opn]: Deprecated php.ini options warnings output even with display_errors=off
ID: 49362 User updated by: tomas dot hlavacek at firma dot volny dot cz Reported By: tomas dot hlavacek at firma dot volny dot cz -Status: Closed +Status: Open Bug Type: PHP options/info functions Operating System: * PHP Version: 5.3, 6 Assigned To: kalle New Comment: php.ini: error_reporting = E_ALL ~E_DEPRECATED display_errors = On php -i output: ~~ D:\php5php -i Warning: Directive 'register_long_arrays' is deprecated in PHP 5.3 and greater in Unknown on line 0 phpinfo() PHP Version = 5.3.2-dev System = Windows NT W2K8-TEST 6.0 build 6002 (Windows Server 2008 Web Server Edition Service Pack 2) i586 ... ~~ Is this desired manner? Previous Comments: [2009-09-04 11:03:07] j...@php.net Fixed. [2009-09-03 21:26:00] j...@php.net For 6: change the error reporting to E_ERROR For 5.3: change them to E_DEPRECATED (and only really shown when that is set) [2009-09-02 16:25:22] romanf at trash dot net Will this be fixed in 5.3? Or only in 6? -Roman [2009-08-26 11:08:41] j...@php.net Correction: E_ERROR of course. :) [2009-08-26 11:08:07] j...@php.net And in HEAD these should be E_FATAL errors. 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/49362 -- Edit this bug report at http://bugs.php.net/?id=49362edit=1
#49488 [NEW]: Problem in pathinfo
From: rasviar at gmail dot com Operating system: Windows Xp PHP version: 5.3.0 PHP Bug Type: URL related Bug description: Problem in pathinfo Description: Try to use pathinfo function for retrieving filename from URL with only a base URL. For example 'http://www.abc.com/'. It must return a null value, but returning 'www.abc' which is wrong not a file. Reproduce code: --- ?php $url=http://www.abc.com/;; echo pathinfo($url,PATHINFO_FILENAME); ? Expected result: null Actual result: -- www.abc -- Edit bug report at http://bugs.php.net/?id=49488edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49488r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49488r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49488r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49488r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49488r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49488r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49488r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49488r=needscript Try newer version: http://bugs.php.net/fix.php?id=49488r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49488r=support Expected behavior: http://bugs.php.net/fix.php?id=49488r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49488r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49488r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49488r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49488r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49488r=dst IIS Stability: http://bugs.php.net/fix.php?id=49488r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49488r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49488r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49488r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49488r=mysqlcfg
#49489 [NEW]: strftime('%P') generates nvalid CRT parameters detected.
From: RQuadling at GMail dot com
Operating system: Windows XP SP3
PHP version: 5.3SVN-2009-09-07 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: strftime('%P') generates nvalid CRT parameters detected.
Description:
Hi.
I was looking at the bug http://bugs.php.net/?id=49481 and saw
Derick's example at the bottom.
Tried running in and got some errors.
Retrieved latest Win32 VC9 x86 nts snapshot (PHP 5.3.2-dev (cli)
(built: Sep 7 2009 07:57:33))
Using %P causes the problem below. %p outputs AM (or PM if it is PM)
as expected.
Previous reports of this error (http://bugs.php.net/bug.php?id=48652)
says Error in a dependency.
Not sure when this issue arose.
Reproduce code:
---
php -n -d date.timezone=Europe/London -r echo strftime('%P');
Expected result:
am
Actual result:
--
Warning: Invalid CRT parameters detected in Command line code on line 1
Warning: Invalid CRT parameters detected in Command line code on line 1
Warning: Invalid CRT parameters detected in Command line code on line 1
Warning: Invalid CRT parameters detected in Command line code on line 1
Warning: Invalid CRT parameters detected in Command line code on line 1
--
Edit bug report at http://bugs.php.net/?id=49489edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49489r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49489r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49489r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49489r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49489r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49489r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49489r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49489r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49489r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49489r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49489r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49489r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49489r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49489r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49489r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49489r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49489r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49489r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49489r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49489r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49489r=mysqlcfg
#49489 [Opn]: strftime('%P') generates Invalid CRT parameters detected.
ID: 49489
Updated by: rquadl...@php.net
-Summary: strftime('%P') generates nvalid CRT parameters
detected.
Reported By: RQuadling at GMail dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-07 (snap)
New Comment:
Typo
Previous Comments:
[2009-09-07 07:49:31] RQuadling at GMail dot com
Description:
Hi.
I was looking at the bug http://bugs.php.net/?id=49481 and saw
Derick's example at the bottom.
Tried running in and got some errors.
Retrieved latest Win32 VC9 x86 nts snapshot (PHP 5.3.2-dev (cli)
(built: Sep 7 2009 07:57:33))
Using %P causes the problem below. %p outputs AM (or PM if it is PM)
as expected.
Previous reports of this error (http://bugs.php.net/bug.php?id=48652)
says Error in a dependency.
Not sure when this issue arose.
Reproduce code:
---
php -n -d date.timezone=Europe/London -r echo strftime('%P');
Expected result:
am
Actual result:
--
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
--
Edit this bug report at http://bugs.php.net/?id=49489edit=1
#45918 [Com]: Mssql_init randomly returns a warning or a resource
ID: 45918 Comment by: igor dot kalashnikov at gmail dot com Reported By: dennis at pascolo dot nl Status: Open Bug Type: MSSQL related Operating System: Fedora Core 8 PHP Version: 5.2.6 New Comment: Just reproduced a problem. I found that error is returned when the procedure is initialized second time without execution of first (in my case). In other cases all is normal. Previous Comments: [2008-08-26 09:19:59] dennis at pascolo dot nl Description: When i try to connect to Mssql I randomly encounter warnings with unable to init stored procedure. Whenever i try to run the query seperatly in Microsoft SQL Server Management Studio Express the query never fails, so i don't think this is an SQL-server problem. When i refresh the website often i can see one time it returns a resource (which is good) 'resource(92, mssql statement)' or a warning 'Warning: mssql_init() [function.mssql-init]: unable to init stored procedure in /var/www/html/test/app/controllers/TestController.php on line 40' That TestController sets up a persistent connection and initializes a stored procedure. That's it, nothing more nothing less. The expected result en the actual result keep randomly appearing Reproduce code: --- $a = mssql_pconnect($server, $username, $password); var_dump($a); var_dump(is_resource($a)); $b = mssql_init(dbo.$procedure) or die(mssql_get_last_message()); var_dump($b); Expected result: resource(91, mssql link persistent) boolean true resource(92, mssql statement) Actual result: -- resource(91, mssql link persistent) boolean true Warning: mssql_init() [function.mssql-init]: unable to init stored procedure in /var/www/html/test/app/controllers/TestController.php on line 40 -- Edit this bug report at http://bugs.php.net/?id=45918edit=1
#49488 [Opn-Bgs]: Problem in pathinfo
ID: 49488 Updated by: j...@php.net Reported By: rasviar at gmail dot com -Status: Open +Status: Bogus Bug Type: URL related Operating System: Windows Xp PHP Version: 5.3.0 New Comment: pathinfo() is filesystem function. It's not meant for URLs. RTFM.. Previous Comments: [2009-09-07 07:24:12] rasviar at gmail dot com Description: Try to use pathinfo function for retrieving filename from URL with only a base URL. For example 'http://www.abc.com/'. It must return a null value, but returning 'www.abc' which is wrong not a file. Reproduce code: --- ?php $url=http://www.abc.com/;; echo pathinfo($url,PATHINFO_FILENAME); ? Expected result: null Actual result: -- www.abc -- Edit this bug report at http://bugs.php.net/?id=49488edit=1
#49490 [NEW]: XPath namespace prefix conflict
From: olav dot morken at uninett dot no
Operating system: Linux (Debian)
PHP version: 5.3.0
PHP Bug Type: DOM XML related
Bug description: XPath namespace prefix conflict
Description:
When processing an XML document with namespaces, an XPath query for a node
with a different namespace but the same namespace prefix fails.
This appears to be a conflict between the XPath namespaces and the
document namespaces. It works if either:
- The prefix in the query is replaced with a prefix that doesn't
exist in the document.
- If the prefix in the query matches the prefix in the document.
This was tested with:
- PHP 5.3 from debian experimental: 5.3.0-3
- libxml2 2.7.3.dfsg-2.1
Reproduce code:
---
$doc = new DOMDocument();
$doc-loadXML('prefix:root xmlns:prefix=urn:a /');
$xp = new DOMXPath($doc);
$xp-registerNamespace('prefix', 'urn:b');
echo($xp-query('//prefix:root')-length . \n);
Expected result:
It should not find the root node, since we ask for a node in a different
prefix. I.e. it should print '0'.
Actual result:
--
It finds the root node, i.e. it prints '1'.
--
Edit bug report at http://bugs.php.net/?id=49490edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49490r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49490r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49490r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49490r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49490r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49490r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49490r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49490r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49490r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49490r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49490r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49490r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49490r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49490r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49490r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49490r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49490r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49490r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49490r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49490r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49490r=mysqlcfg
#49362 [Opn-Csd]: Deprecated php.ini options warnings output even with display_errors=off
ID: 49362 Updated by: j...@php.net Reported By: tomas dot hlavacek at firma dot volny dot cz -Status: Open +Status: Closed Bug Type: PHP options/info functions Operating System: * PHP Version: 5.3, 6 Assigned To: kalle New Comment: Yes. It's not E_DEPRECATED, it's E_WARNING and that's not gonna change. Previous Comments: [2009-09-07 07:20:13] tomas dot hlavacek at firma dot volny dot cz php.ini: error_reporting = E_ALL ~E_DEPRECATED display_errors = On php -i output: ~~ D:\php5php -i Warning: Directive 'register_long_arrays' is deprecated in PHP 5.3 and greater in Unknown on line 0 phpinfo() PHP Version = 5.3.2-dev System = Windows NT W2K8-TEST 6.0 build 6002 (Windows Server 2008 Web Server Edition Service Pack 2) i586 ... ~~ Is this desired manner? [2009-09-04 11:03:07] j...@php.net Fixed. [2009-09-03 21:26:00] j...@php.net For 6: change the error reporting to E_ERROR For 5.3: change them to E_DEPRECATED (and only really shown when that is set) [2009-09-02 16:25:22] romanf at trash dot net Will this be fixed in 5.3? Or only in 6? -Roman [2009-08-26 11:08:41] j...@php.net Correction: E_ERROR of course. :) 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/49362 -- Edit this bug report at http://bugs.php.net/?id=49362edit=1
#49362 [Csd]: Deprecated php.ini options warnings output even with display_errors=off
ID: 49362 User updated by: tomas dot hlavacek at firma dot volny dot cz Reported By: tomas dot hlavacek at firma dot volny dot cz Status: Closed Bug Type: PHP options/info functions Operating System: * PHP Version: 5.3, 6 Assigned To: kalle New Comment: Check what you wrote: [3 Sep 9:26pm UTC] j...@php.net For 6: change the error reporting to E_ERROR For 5.3: change them to E_DEPRECATED (and only really shown when that is set) That's confusing then... Previous Comments: [2009-09-07 08:42:19] j...@php.net Yes. It's not E_DEPRECATED, it's E_WARNING and that's not gonna change. [2009-09-07 07:20:13] tomas dot hlavacek at firma dot volny dot cz php.ini: error_reporting = E_ALL ~E_DEPRECATED display_errors = On php -i output: ~~ D:\php5php -i Warning: Directive 'register_long_arrays' is deprecated in PHP 5.3 and greater in Unknown on line 0 phpinfo() PHP Version = 5.3.2-dev System = Windows NT W2K8-TEST 6.0 build 6002 (Windows Server 2008 Web Server Edition Service Pack 2) i586 ... ~~ Is this desired manner? [2009-09-04 11:03:07] j...@php.net Fixed. [2009-09-03 21:26:00] j...@php.net For 6: change the error reporting to E_ERROR For 5.3: change them to E_DEPRECATED (and only really shown when that is set) [2009-09-02 16:25:22] romanf at trash dot net Will this be fixed in 5.3? Or only in 6? -Roman 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/49362 -- Edit this bug report at http://bugs.php.net/?id=49362edit=1
#42266 [Com]: BLOB functions do not work on 64bit systems
ID: 42266 Comment by: lester at lsces dot co dot uk Reported By: karasek at ceskyserver dot cz Status: Assigned Bug Type: InterBase related Operating System: Linux 64-bit PHP Version: 5.2.4 Assigned To: abies New Comment: Currently I have PHP5.2.9 and 10 running without any blob id problem on a number of 64 bit distributions. And 5.3 running on Vista64 as well again without displaying this bug. So I think we need a lot more information from people who DO have this problem still Previous Comments: [2009-07-23 09:30:41] andre at spiceware dot co dot za I can confirm that php 5.2.1 was the last working version for BLOBS on 64 bit operating system as I have downloaded all the versions since then to check each one. I have recently compiled 5.3.0 with no joy too! [2009-06-08 10:10:57] lester at lsces dot co dot uk I think we needs some proper feedback on this problem. There WAS a problem with some builds of PHP from 5.2.0 to 5.2.5 relating to how the blob ID was handled after some re-engineering of the core PHP code. This resulted in a problem which was clearly visible when running ADOdb, since it could not access the BLOB_ID. Since 5.2.6 that problem has been fixed, and I'm currently running both windows and linux x64 machineswithout the back to get around the problem. So as far as I am concerned this bug has been cleared. So where are people still seeing it and how can we recreate that view of the problem? [2009-05-21 20:35:59] mkoeditz at gmx dot de Well, i've just installed openSUSE 10.3 with php 25.2.9 and Firebird 2.1. 32 bit system. Same error. So I think there is no focus on the platform but the php version. Regards Martin [2008-09-08 14:24:17] andre at spiceware dot co dot za I compiled PHP 5.2.6 from source tar ball for Linux this last weekend and also ended up with the BLOB error. This is still a problem. [2008-08-06 17:31:41] hasul at etoscomp dot eu Hi, is this bug still open? Because BLOB is working on my system (Centos 5.2 64bit). I used php 5.2.6 from Jason Litka repo (http://www.jasonlitka.com/yum-repository/) and FirebirdSS-2.1.0.17798-0.amd64.rpm from official firebird site. 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/42266 -- Edit this bug report at http://bugs.php.net/?id=42266edit=1
#49487 [Opn-Bgs]: addslashes � Quote string with slashes
ID: 49487 Updated by: scott...@php.net Reported By: shefik at allknightaccess dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Mac 10.5.8 PHP Version: 5.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. We have this with addcslashes where you can provide a character list to escape. Previous Comments: [2009-09-06 19:44:49] shefik at allknightaccess dot com Description: Please add a new parameter for the function addslashes, where it flags what type of character to quote string with slashes. Such as: SINGLE DOUBLE BACKSLASH NULL ALL All would remain the default, as it is right now. Example use with the new parameter: ?php $str = He asked, \Is your name O'reilly?\; // Outputs: He asked, Is your name O\'reilly? echo addslashes($str, SINGLE); ? ?php $str = He asked, \Is your name O'reilly?\; // Outputs: He asked, \Is your name O'reilly?\ echo addslashes($str, DOUBLE); ? ?php $str = He asked, \Is your name O'reilly?\; // Outputs: He asked, \Is your name O\'reilly?\ echo addslashes($str, ALL); ? -- Edit this bug report at http://bugs.php.net/?id=49487edit=1
#49489 [Opn-Bgs]: strftime('%P') generates Invalid CRT parameters detected.
ID: 49489
Updated by: der...@php.net
Reported By: RQuadling at GMail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-09-07 (snap)
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
Windows doesn't support all modifiers, see
http://msdn.microsoft.com/en-us/library/az4se3k1(VS.71).aspx for the
supported ones (and that link is in the manual at
http://uk3.php.net/strftime .
Previous Comments:
[2009-09-07 07:49:31] RQuadling at GMail dot com
Description:
Hi.
I was looking at the bug http://bugs.php.net/?id=49481 and saw
Derick's example at the bottom.
Tried running in and got some errors.
Retrieved latest Win32 VC9 x86 nts snapshot (PHP 5.3.2-dev (cli)
(built: Sep 7 2009 07:57:33))
Using %P causes the problem below. %p outputs AM (or PM if it is PM)
as expected.
Previous reports of this error (http://bugs.php.net/bug.php?id=48652)
says Error in a dependency.
Not sure when this issue arose.
Reproduce code:
---
php -n -d date.timezone=Europe/London -r echo strftime('%P');
Expected result:
am
Actual result:
--
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
--
Edit this bug report at http://bugs.php.net/?id=49489edit=1
#49491 [NEW]: [apc-warning] Unable to allocate memory for pool.
From: gudaykanth at sapplica dot com
Operating system: centOS
PHP version: 5.3.0
PHP Bug Type: Unknown/Other Function
Bug description: [apc-warning] Unable to allocate memory for pool.
Description:
[Sat Sep 5 00:45:22 2009] [apc-warning] Unable to allocate memory for
pool. in /var/www/html/voxbox/php/getHub.php on line 2.
[Sat Sep 5 00:45:22 2009] [apc-warning] Unable to allocate memory for
pool. in /var/www/html/voxbox/php/getHub.php on line 11.
Reproduce code:
---
?
include_once(cert_file_accessor.php);
$response='';
if($Auth_Result == Failed)
{
$response='{status:Unauthorized Access...}';
echo $response;
}
else
{
include_once(connect_hub.php);
Expected result:
Execution is working fine. except that whenever the files is called there
is a new line in error_log.
Its just increasing the size of the log file.
Actual result:
--
Execution is working fine. except that whenever the files is called there
is a new line in error_log.
Its just increasing the size of the log file.
--
Edit bug report at http://bugs.php.net/?id=49491edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49491r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49491r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49491r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49491r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49491r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49491r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49491r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49491r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49491r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49491r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49491r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49491r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49491r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49491r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49491r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49491r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49491r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49491r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49491r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49491r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49491r=mysqlcfg
#27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Comment by: benadler at gmx dot net Reported By: ghoffer at globalscape dot com Status: Feedback Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: Ok, it works on the commandline but not using IIS6 and fastcgi with fastcgi.impersonate = 1;. This is test.php: ?php $out = array(); echo exec(echo %USERNAME%, $out); print_r($out); $out = array(); echo exec(echo %USERPROFILE%, $out); print_r($out); ? and this results in: %USERNAME%Array ( [0] = %USERNAME% ) C:\Documents and Settings\Default UserArray ( [0] = C:\Documents and Settings\Default User ) So it seems the user's profile/environment is not correctly set up. I think username should be either domain\deabjs1 or just deabjs1, because this is what I use to log on to IIS using NTLM. I'm still using the same snapshot I was using at [6 Sep 6:13pm UTC]. Thanks for your help! ben Previous Comments: [2009-09-06 18:13:09] benadler at gmx dot net I tried the newest snapshot and it seems to work - thank you! But, could it be that the environment is not set up correctly? Suddenly I start getting all those imagemagick-temp files in the script's directory. I imagine the reason may be that the %TEMP% or %TMP% system/user variables are not set correctly. [2009-09-03 21:17:45] paj...@php.net Please (all :) try a snapshot, php 5.3 or 6 (5.3 recommended anyway :). [2009-09-03 19:16:50] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288004 Log: - #27051, improve fix on xp/2k3 [2009-09-03 19:16:17] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288003 Log: - #27051, improve fix on xp/2k3 [2009-09-03 15:52:24] benadler at gmx dot net I updated to php-5.3-nts-win32-VC9-x86-latest.zip yesterday night. The impersonation problem with iis6 and fastcgi was fixed, but when starting a php-script from the command line/dosbox, I get: Warning: exec(): Unable to fork [imconvert.exe ...] in scriptname.php on line X Using exec() works fine when the scripts are called from IIS, though. The failing scripts have worked fine before updating php. I traced the execution using sysinternals process monitor, and Process Create C:\WINDOWS\system32\cmd.exe cmd.exe /c imconvert tif:D:/data/foo.tif[0] D:/data/bar.jpg shows SUCCESS, but it seems imconvert.exe is never started, as it doesn't show up in the trace. Process Monitor shows that the php script is running as the user who's currently logged in, but I cannot see which user is trying to start convert.exe Can I help with more info? ben. 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051edit=1
#27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Comment by: benadler at gmx dot net Reported By: ghoffer at globalscape dot com Status: Feedback Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: Hope I'm not too verbose. Maybe it helps to see that calling this exec(d:/programme/imagemagick/convert.exe -density $density $baseDirectory/$bookId/document.pdf -quality 95 $baseDirectory/$bookId/$version/page_%04d.jpg, $output); print_r($output); in a script run by the webserver (as above) causes this: Array ( [0] = Error: /invalidfileaccess in --showpage-- [1] = Operand stack: [2] =--nostringval-- 1 true [3] = Execution stack: [4] =%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 4 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1777 1 9 %oparray_pop --nostringval-- --nostringval-- [5] = Dictionary stack: [6] =--dict:1155/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:275/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:22/40(L)-- [7] = Current allocation mode is local [8] = Last OS error: Bad file descriptor ) Previous Comments: [2009-09-07 11:11:06] benadler at gmx dot net Ok, it works on the commandline but not using IIS6 and fastcgi with fastcgi.impersonate = 1;. This is test.php: ?php $out = array(); echo exec(echo %USERNAME%, $out); print_r($out); $out = array(); echo exec(echo %USERPROFILE%, $out); print_r($out); ? and this results in: %USERNAME%Array ( [0] = %USERNAME% ) C:\Documents and Settings\Default UserArray ( [0] = C:\Documents and Settings\Default User ) So it seems the user's profile/environment is not correctly set up. I think username should be either domain\deabjs1 or just deabjs1, because this is what I use to log on to IIS using NTLM. I'm still using the same snapshot I was using at [6 Sep 6:13pm UTC]. Thanks for your help! ben [2009-09-06 18:13:09] benadler at gmx dot net I tried the newest snapshot and it seems to work - thank you! But, could it be that the environment is not set up correctly? Suddenly I start getting all those imagemagick-temp files in the script's directory. I imagine the reason may be that the %TEMP% or %TMP% system/user variables are not set correctly. [2009-09-03 21:17:45] paj...@php.net Please (all :) try a snapshot, php 5.3 or 6 (5.3 recommended anyway :). [2009-09-03 19:16:50] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288004 Log: - #27051, improve fix on xp/2k3 [2009-09-03 19:16:17] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288003 Log: - #27051, improve fix on xp/2k3 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051edit=1
#27051 [Fbk]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Updated by: paj...@php.net Reported By: ghoffer at globalscape dot com Status: Feedback Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: I'm not sure the users environment is set, that's a different thing. But is it the correct user? Previous Comments: [2009-09-07 11:17:13] benadler at gmx dot net Hope I'm not too verbose. Maybe it helps to see that calling this exec(d:/programme/imagemagick/convert.exe -density $density $baseDirectory/$bookId/document.pdf -quality 95 $baseDirectory/$bookId/$version/page_%04d.jpg, $output); print_r($output); in a script run by the webserver (as above) causes this: Array ( [0] = Error: /invalidfileaccess in --showpage-- [1] = Operand stack: [2] =--nostringval-- 1 true [3] = Execution stack: [4] =%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 4 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1777 1 9 %oparray_pop --nostringval-- --nostringval-- [5] = Dictionary stack: [6] =--dict:1155/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:275/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:22/40(L)-- [7] = Current allocation mode is local [8] = Last OS error: Bad file descriptor ) [2009-09-07 11:11:06] benadler at gmx dot net Ok, it works on the commandline but not using IIS6 and fastcgi with fastcgi.impersonate = 1;. This is test.php: ?php $out = array(); echo exec(echo %USERNAME%, $out); print_r($out); $out = array(); echo exec(echo %USERPROFILE%, $out); print_r($out); ? and this results in: %USERNAME%Array ( [0] = %USERNAME% ) C:\Documents and Settings\Default UserArray ( [0] = C:\Documents and Settings\Default User ) So it seems the user's profile/environment is not correctly set up. I think username should be either domain\deabjs1 or just deabjs1, because this is what I use to log on to IIS using NTLM. I'm still using the same snapshot I was using at [6 Sep 6:13pm UTC]. Thanks for your help! ben [2009-09-06 18:13:09] benadler at gmx dot net I tried the newest snapshot and it seems to work - thank you! But, could it be that the environment is not set up correctly? Suddenly I start getting all those imagemagick-temp files in the script's directory. I imagine the reason may be that the %TEMP% or %TMP% system/user variables are not set correctly. [2009-09-03 21:17:45] paj...@php.net Please (all :) try a snapshot, php 5.3 or 6 (5.3 recommended anyway :). [2009-09-03 19:16:50] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=288004 Log: - #27051, improve fix on xp/2k3 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051edit=1
#49489 [Bgs]: strftime('%P') generates Invalid CRT parameters detected.
ID: 49489
Updated by: rquadl...@php.net
Reported By: RQuadling at GMail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-09-07 (snap)
New Comment:
Doh.
Seems that even the most recent MSDN docs
(http://msdn.microsoft.com/en-us/library/az4se3k1(VS.100).aspx and
http://msdn.microsoft.com/en-us/library/8kb3ddd4(VS.100).aspx) is out
of date.
No mention of %p, yet it works.
?php
error_reporting(0);
$a_Remaining = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
$a_Formats = array(
'Day' = 'aAdejuw',
'Week'= 'UVW',
'Month' = 'bBhm',
'Year'= 'CgGyY',
'Time'= 'HIlMpPrRSTXzZ',
'Time and Date Stamps'= 'cDFsx',
'Miscellaneous' = 'nt%',
'Unknown' = $a_Remaining
);
foreach($a_Formats as $s_Group = $s_GroupFormats) {
echo $s_Group, PHP_EOL;
foreach(range(0, strlen($s_GroupFormats) - 1) as $i_Format) {
echo
\t{$s_GroupFormats[$i_Format]} : ,
(!($s_Output = strftime('%' . $s_GroupFormats[$i_Format]))
? \t\t\t[Unknown]
: $s_Output),
PHP_EOL;
$a_Remaining = str_replace($s_GroupFormats[$i_Format], '',
$a_Remaining);
}
}
outputs ...
Day
a : Mon
A : Monday
d : 07
e : [Unknown]
j : 250
u : [Unknown]
w : 1
Week
U : 36
V : [Unknown]
W : 36
Month
b : Sep
B : September
h : [Unknown]
m : 09
Year
C : [Unknown]
g : [Unknown]
G : [Unknown]
y : 09
Y : 2009
Time
H : 12
I : 12
l : [Unknown]
M : 35
p : PM
P : [Unknown]
r : [Unknown]
R : [Unknown]
S : 03
T : [Unknown]
X : 12:35:03
z : GMT Standard Time
Z : GMT Standard Time
Time and Date Stamps
c : 09/07/09 12:35:03
D : [Unknown]
F : [Unknown]
s : [Unknown]
x : 09/07/09
Miscellaneous
n : [Unknown]
t : [Unknown]
% : %
Unknown
E : [Unknown]
J : [Unknown]
K : [Unknown]
L : [Unknown]
N : [Unknown]
O : [Unknown]
Q : [Unknown]
f : [Unknown]
i : [Unknown]
k : [Unknown]
o : [Unknown]
q : [Unknown]
v : [Unknown]
Thanks Derick. Next time I'll RTFM!
Previous Comments:
[2009-09-07 11:01:38] der...@php.net
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
Windows doesn\'t support all modifiers, see
http://msdn.microsoft.com/en-us/library/az4se3k1(VS.71).aspx for the
supported ones (and that link is in the manual at
http://uk3.php.net/strftime .
[2009-09-07 07:49:31] RQuadling at GMail dot com
Description:
Hi.
I was looking at the bug http://bugs.php.net/?id=49481 and saw
Derick's example at the bottom.
Tried running in and got some errors.
Retrieved latest Win32 VC9 x86 nts snapshot (PHP 5.3.2-dev (cli)
(built: Sep 7 2009 07:57:33))
Using %P causes the problem below. %p outputs AM (or PM if it is PM)
as expected.
Previous reports of this error (http://bugs.php.net/bug.php?id=48652)
says Error in a dependency.
Not sure when this issue arose.
Reproduce code:
---
php -n -d date.timezone=Europe/London -r echo strftime('%P');
Expected result:
am
Actual result:
--
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
Warning: Invalid CRT parameters detected in Command line code on line
1
--
Edit this bug report at http://bugs.php.net/?id=49489edit=1
#49420 [Com]: Uncatchable fatal error
ID: 49420
Comment by: tomseven at gmx dot de
Reported By: tomseven at gmx dot de
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
After reworking my code, I got it working. I cannot detect any
reasonable changes other than I use zend_try now instead of
zend_first_try.
Btw, I am using output buffering and zend_try together. Making sure,
the buffer will close in any cases is nessarry for correct output via
webservers.
Previous Comments:
[2009-09-07 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-08-30 21:22:06] tomseven at gmx dot de
Updated to the latest PHP release and source (5.3.1), but it still
crashes.
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: httpd.exe
Anwendungsversion:2.2.13.0
Anwendungszeitstempel:4a7b422b
Fehlermodulname: php5ts.dll
Fehlermodulversion: 5.3.1.0
Fehlermodulzeitstempel: 4a9ae59c
Ausnahmecode: c005
Ausnahmeoffset: 0008c767
Betriebsystemversion: 6.0.6001.2.1.0.768.3
Gebietsschema-ID: 1031
Zusatzinformation 1: f1e8
Zusatzinformation 2: d4eb7cf28a4f910486e91a11f70d294f
Zusatzinformation 3: 8d19
Zusatzinformation 4: c73248402f4105cfb47e294ad6946345
[2009-08-30 20:39:49] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-30 20:32:44] tomseven at gmx dot de
Description:
Uncatchable fatal error for function call on non-object
Reproduce code:
---
...
LPSTR eval_code = ? $NOVAR-ABC();;
...
zend_first_try {
if ( zend_eval_string(eval_code, NULL, eval_name TSRMLS_CC) ==
SUCCESS ) {
...
}
}
zend_catch
{
} zend_end_try();
Expected result:
zend_eval_string should throw a fatal error and jump to zend_catch.
Fatal error Call to a member function ABC() on a non-object is
expected to be catchable.
It is working in 5.2.1/Apache2 but no longer in 5.3/Apache2.2
Actual result:
--
zend_catch never reached
--
Edit this bug report at http://bugs.php.net/?id=49420edit=1
#49482 [Asn-Fbk]: SOAP encoding although WSDL requires use='LITERAL'
ID: 49482
Updated by: dmi...@php.net
Reported By: joep at clickhere dot nl
-Status: Assigned
+Status: Feedback
Bug Type: SOAP related
Operating System: Ubuntu
PHP Version: 5.2.10
Assigned To: dmitry
New Comment:
This is not a bug. In case of 'use'='ENCODED' ext/soap always adds type
information and this check would just useless. In this place, it adds
type name specidied in 'classmap' for LITERAL encoding because without
it receiver won't be able to determine the real input type. Correct me
if I'm wrong (I can't be 100% sure as I don't see your code) and
demonstrate it with a small example.
BTW the 'classmap' concept is very limited. It was extended with
'typemap' concept which may give user the full control over generated
XML. Probably you need to use it.
Previous Comments:
[2009-09-06 10:29:52] joep at clickhere dot nl
Description:
I was hunting a bug in our soap-client. 'xsi:type' appears in the xml,
even when the WSDL states 'use=literal'.
Our client works fine with 5.2.4, but since 5.2.7/5.2.8 its broken
(Also tested 5.2.9)
Came across this fix in ext/soap/php_encoding.c
+if (encode != enc style == SOAP_LITERAL) {
add_type = 1;
-}
Shouldn't that be:
if (encode != enc style == SOAP_ENCODED) {
add_type = 1;
}
--
Edit this bug report at http://bugs.php.net/?id=49482edit=1
#49491 [Opn-Bgs]: [apc-warning] Unable to allocate memory for pool.
ID: 49491
Updated by: j...@php.net
Reported By: gudaykanth at sapplica dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: centOS
PHP Version: 5.3.0
New Comment:
Wrong place to report bugs in APC. Do it here:
http://pecl.php.net/bugs/report.php?package=APC
Previous Comments:
[2009-09-07 11:07:47] gudaykanth at sapplica dot com
Description:
[Sat Sep 5 00:45:22 2009] [apc-warning] Unable to allocate memory for
pool. in /var/www/html/voxbox/php/getHub.php on line 2.
[Sat Sep 5 00:45:22 2009] [apc-warning] Unable to allocate memory for
pool. in /var/www/html/voxbox/php/getHub.php on line 11.
Reproduce code:
---
?
include_once(cert_file_accessor.php);
$response='';
if($Auth_Result == Failed)
{
$response='{status:Unauthorized Access...}';
echo $response;
}
else
{
include_once(connect_hub.php);
Expected result:
Execution is working fine. except that whenever the files is called
there is a new line in error_log.
Its just increasing the size of the log file.
Actual result:
--
Execution is working fine. except that whenever the files is called
there is a new line in error_log.
Its just increasing the size of the log file.
--
Edit this bug report at http://bugs.php.net/?id=49491edit=1
#49486 [Opn-Bgs]: socket_read couldn't detect the end of data
ID: 49486
Updated by: sjo...@php.net
Reported By: kernins at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Sockets related
Operating System: Debian 4.0, WinXP SP3
PHP Version: 5.2.9, 5.3.0
New Comment:
Thank you for your report.
Socket_read only returns false when the remote end has closed the
connection. It will not return false when the remote side has not closed
the connection but does not send data anymore. This is expected
behavior. Socket_read can not detect the end of data, other than the
other side closing the connection.
Previous Comments:
[2009-09-06 13:34:50] kernins at gmail dot com
Description:
App description: Script should connect to socks4/5 or CONNECT proxy and
establish a tunnel to some host, google.com:80, for example.
Problem: socket_read() couldn't detect the end of data while reading
response from socks4/5 server (response to initial hello msg or connect
command) or from connect-proxy (response to connect command).
Reproduce code:
---
$host=gethostbyname(google.com); $port=80;
$proxy_ip=212.27.33.4; $proxy_port=8118;
if(!preg_match('/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/',$host,$ip)) die();
$s5_init=\x05\x01\x00;
$s5_connect=\x05\x01\x00\x01.chr($ip[1]).chr($ip[2]).chr($ip[3]).chr($ip[4]).pack('n',$port);
$s4=\x04\x01.pack('n',$port).chr($ip[1]).chr($ip[2]).chr($ip[3]).chr($ip[4]).\x00;
$connect=CONNECT google.com:80 HTTP/1.1\r\nProxy-Connection:
keep-alive\r\n\r\n;
$sock=socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_set_option($sock,SOL_SOCKET,SO_SNDTIMEO,array('sec'=5,'usec'=0));
socket_set_option($sock,SOL_SOCKET,SO_RCVTIMEO,array('sec'=15,'usec'=0));
socket_connect($sock,$proxy_ip,$proxy_port);
echo written: .socket_write($sock,$connect).PHP_EOL;
//$data=socket_read($sock,1024,PHP_BINARY_READ);
while($data=socket_read($sock,1024,PHP_BINARY_READ)) var_dump($data);
$err=socket_last_error($sock);
$e=socket_get_option($sock,SOL_SOCKET,SO_ERROR);
var_dump($data,$err,socket_strerror($err),$e,socket_strerror($e));
Expected result:
In blocking mode:
while($data=socket_read($sock,1024,PHP_BINARY_READ))
will make two or more iterations, at last iteration socket_read will
return emty string indicating end of data.
In non-blocking mode:
socket_select will return socket two or more times as ready for
reading. Last time socket_read will return emty string indicating end of
data.
Actual result:
--
In blocking mode:
if I use a single socket_read($sock,1024,PHP_BINARY_READ) call, it
returns data without any significant delay or error. In that case there
are no problems.
But
while($data=socket_read($sock,1024,PHP_BINARY_READ))
will return all response in first iteration and then blocks until
timeout was reached (if I set it via socket_set_option) and return false
with EAGAIN error. If timeout is not set it will return epmty string and
no errors as expected, but before this block for couple of minutes.
In non-blocking:
Whole response was also successfully recieved after first socket_select
return, and then this socket has no more returned by socket_select as
ready for reading.
I've tested this on debian PHP 5.2.9-0.dotdeb.1 with Suhosin-Patch
0.9.7 and WinXP php 5.3.0 (binary from php.net) with some public socks
and connect proxies and with SHHTunnel 4.3.0.0 for Win which has built
in socks 4/5 proxy.
--
Edit this bug report at http://bugs.php.net/?id=49486edit=1
#49492 [NEW]: I need 64bit package
From: davija at cshp dot info Operating system: Windows 2003 x64 PHP version: 5.3.0 PHP Bug Type: IIS related Bug description: I need 64bit package Description: Not having a x64 official release build at this point is laughable. While you can run the x86 version by tweaking a configuration setting, this breaks the ability for IIS to run other .net applications that require x64 support. Expecting that you can just run them on another server isn't really acceptable either. Please provide an official release for x64. Many of us aren't really all that concerned that there may not be a performance increase at this point, we just need a version that is compatible with our server requirements. Reproduce code: --- Install php alongside something like cc.net on a x64 box Expected result: you should be able to have x64 .net apps run in the same server as php. Actual result: -- I have to setup a whole new server to run php apps. This is a very expensive waste of machine equipment. -- Edit bug report at http://bugs.php.net/?id=49492edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49492r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49492r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49492r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49492r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49492r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49492r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49492r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49492r=needscript Try newer version: http://bugs.php.net/fix.php?id=49492r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49492r=support Expected behavior: http://bugs.php.net/fix.php?id=49492r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49492r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49492r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49492r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49492r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49492r=dst IIS Stability: http://bugs.php.net/fix.php?id=49492r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49492r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49492r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49492r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49492r=mysqlcfg
#29460 [Com]: memory usage (leak?) on session
ID: 29460
Comment by: cq92 at hotmail dot com
Reported By: kylewong at southa dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux kernel 2.6.1
PHP Version: 4.3.8
New Comment:
Probably the easiest way to fix this problem is to create a batch file
to empty the sessions folder (*.*) regularily and run it using task
scheduler (windows servers). That way it will automatically dump cache
folders or session folders at regular intervals, say 4-8 hours daily.
Previous Comments:
[2005-02-11 01:00:26] 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.
[2005-02-03 04:56:58] sni...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-07-31 08:34:59] kylewong at southa dot com
30 minutes after delete all session data files while apache running.
5500 sessions online, 22M disk space taken by session files. average
session file size around 1.5kb.
http://www2.southa.com/~kylewong/top-8.gif
[2004-07-31 08:14:22] kylewong at southa dot com
httpd grow back to 10-12MB
http://www2.southa.com/~kylewong/top-6.gif
2 minutes later after delete all session data while apache running:
http://www2.southa.com/~kylewong/top-7.gif
session.php:
class GallerySession {}
if (session_id()) {
$useStdClass = 1;
}
/* Start a new session, or resume our current one */
@session_start();
$sessionVar = fsess;
session_register($sessionVar);
if (isset($$sessionVar)) {
$gallery-session = $$sessionVar;
} else {
/* Register the session variable */
session_register($sessionVar);
/* Create a new session container */
if ($useStdClass) {
$$sessionVar = new stdClass();
} else {
$$sessionVar = new GallerySession();
}
$gallery-session = $$sessionVar;
}
[2004-07-31 06:53:02] kylewong at southa dot com
more informations:
apache fresh start without any session data:
http://www2.southa.com/~kylewong/top-1.gif
about 30 minutes later, httpd size grow around 1.5M
http://www2.southa.com/~kylewong/top-2.gif
1 hour later from beginning, httpd size reach 10M, total session data
size around 16M, average session file size around 2kb, around 4k
sessions online.
http://www2.southa.com/~kylewong/top-3.gif
stop and restart apache without delete session data, most httpd size
reach 10M immediately after apache start.
http://www2.southa.com/~kylewong/top-4.gif
stop, delete all session data, and restart apache.
http://www2.southa.com/~kylewong/top-5.gif
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/29460
--
Edit this bug report at http://bugs.php.net/?id=29460edit=1
#49492 [Opn-Bgs]: I need 64bit package
ID: 49492 Updated by: paj...@php.net Reported By: davija at cshp dot info -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows 2003 x64 PHP Version: 5.3.0 New Comment: Not having a x64 official release build at this point is laughable. What is laughable is the fact that I never heard of you before so I won't bother to much about your sense of humour. You can laugh at us if you help :) x64 support is experimental and as such it is available in our QA downloads: http://windows.php.net/qa/ Previous Comments: [2009-09-07 17:39:00] davija at cshp dot info Description: Not having a x64 official release build at this point is laughable. While you can run the x86 version by tweaking a configuration setting, this breaks the ability for IIS to run other .net applications that require x64 support. Expecting that you can just run them on another server isn't really acceptable either. Please provide an official release for x64. Many of us aren't really all that concerned that there may not be a performance increase at this point, we just need a version that is compatible with our server requirements. Reproduce code: --- Install php alongside something like cc.net on a x64 box Expected result: you should be able to have x64 .net apps run in the same server as php. Actual result: -- I have to setup a whole new server to run php apps. This is a very expensive waste of machine equipment. -- Edit this bug report at http://bugs.php.net/?id=49492edit=1
#49492 [Bgs]: I need 64bit package
ID: 49492 User updated by: davija at cshp dot info Reported By: davija at cshp dot info Status: Bogus Bug Type: IIS related Operating System: Windows 2003 x64 PHP Version: 5.3.0 New Comment: I looked at the ones on the QA site, but they didn't have any of the IIS isapi dll's built in. Previous Comments: [2009-09-07 18:15:20] paj...@php.net Not having a x64 official release build at this point is laughable. What is laughable is the fact that I never heard of you before so I won't bother to much about your sense of humour. You can laugh at us if you help :) x64 support is experimental and as such it is available in our QA downloads: http://windows.php.net/qa/ [2009-09-07 17:39:00] davija at cshp dot info Description: Not having a x64 official release build at this point is laughable. While you can run the x86 version by tweaking a configuration setting, this breaks the ability for IIS to run other .net applications that require x64 support. Expecting that you can just run them on another server isn't really acceptable either. Please provide an official release for x64. Many of us aren't really all that concerned that there may not be a performance increase at this point, we just need a version that is compatible with our server requirements. Reproduce code: --- Install php alongside something like cc.net on a x64 box Expected result: you should be able to have x64 .net apps run in the same server as php. Actual result: -- I have to setup a whole new server to run php apps. This is a very expensive waste of machine equipment. -- Edit this bug report at http://bugs.php.net/?id=49492edit=1
#49492 [Bgs]: I need 64bit package
ID: 49492 Updated by: paj...@php.net Reported By: davija at cshp dot info Status: Bogus Bug Type: IIS related Operating System: Windows 2003 x64 PHP Version: 5.3.0 New Comment: And that's laughable. ISAPI is deprecated and the FCGI SAPI is recommended instead (by php.net and the IIS team). As such it has been removed from our releases, in 5.3.0 and later. more infos on www.iis.net. Previous Comments: [2009-09-07 18:26:03] davija at cshp dot info I looked at the ones on the QA site, but they didn't have any of the IIS isapi dll's built in. [2009-09-07 18:15:20] paj...@php.net Not having a x64 official release build at this point is laughable. What is laughable is the fact that I never heard of you before so I won't bother to much about your sense of humour. You can laugh at us if you help :) x64 support is experimental and as such it is available in our QA downloads: http://windows.php.net/qa/ [2009-09-07 17:39:00] davija at cshp dot info Description: Not having a x64 official release build at this point is laughable. While you can run the x86 version by tweaking a configuration setting, this breaks the ability for IIS to run other .net applications that require x64 support. Expecting that you can just run them on another server isn't really acceptable either. Please provide an official release for x64. Many of us aren't really all that concerned that there may not be a performance increase at this point, we just need a version that is compatible with our server requirements. Reproduce code: --- Install php alongside something like cc.net on a x64 box Expected result: you should be able to have x64 .net apps run in the same server as php. Actual result: -- I have to setup a whole new server to run php apps. This is a very expensive waste of machine equipment. -- Edit this bug report at http://bugs.php.net/?id=49492edit=1
#49492 [Bgs]: I need 64bit package
ID: 49492 Updated by: paj...@php.net Reported By: davija at cshp dot info Status: Bogus Bug Type: IIS related Operating System: Windows 2003 x64 PHP Version: 5.3.0 New Comment: Btw, you can run 32bit versions smoothly in a 64bit server :) Previous Comments: [2009-09-07 18:29:14] paj...@php.net And that's laughable. ISAPI is deprecated and the FCGI SAPI is recommended instead (by php.net and the IIS team). As such it has been removed from our releases, in 5.3.0 and later. more infos on www.iis.net. [2009-09-07 18:26:03] davija at cshp dot info I looked at the ones on the QA site, but they didn't have any of the IIS isapi dll's built in. [2009-09-07 18:15:20] paj...@php.net Not having a x64 official release build at this point is laughable. What is laughable is the fact that I never heard of you before so I won't bother to much about your sense of humour. You can laugh at us if you help :) x64 support is experimental and as such it is available in our QA downloads: http://windows.php.net/qa/ [2009-09-07 17:39:00] davija at cshp dot info Description: Not having a x64 official release build at this point is laughable. While you can run the x86 version by tweaking a configuration setting, this breaks the ability for IIS to run other .net applications that require x64 support. Expecting that you can just run them on another server isn't really acceptable either. Please provide an official release for x64. Many of us aren't really all that concerned that there may not be a performance increase at this point, we just need a version that is compatible with our server requirements. Reproduce code: --- Install php alongside something like cc.net on a x64 box Expected result: you should be able to have x64 .net apps run in the same server as php. Actual result: -- I have to setup a whole new server to run php apps. This is a very expensive waste of machine equipment. -- Edit this bug report at http://bugs.php.net/?id=49492edit=1
#49492 [Bgs]: I need 64bit package
ID: 49492 User updated by: davija at cshp dot info Reported By: davija at cshp dot info Status: Bogus Bug Type: IIS related Operating System: Windows 2003 x64 PHP Version: 5.3.0 New Comment: As I stated above, you cannot run 32 bit stuff smoothly in a x64 environment when you have stuff that requires .net x64. In the distribution on the QA for x64, there were no server based extenstions, apache or IIS. Previous Comments: [2009-09-07 18:36:10] paj...@php.net Btw, you can run 32bit versions smoothly in a 64bit server :) [2009-09-07 18:29:14] paj...@php.net And that's laughable. ISAPI is deprecated and the FCGI SAPI is recommended instead (by php.net and the IIS team). As such it has been removed from our releases, in 5.3.0 and later. more infos on www.iis.net. [2009-09-07 18:26:03] davija at cshp dot info I looked at the ones on the QA site, but they didn't have any of the IIS isapi dll's built in. [2009-09-07 18:15:20] paj...@php.net Not having a x64 official release build at this point is laughable. What is laughable is the fact that I never heard of you before so I won't bother to much about your sense of humour. You can laugh at us if you help :) x64 support is experimental and as such it is available in our QA downloads: http://windows.php.net/qa/ [2009-09-07 17:39:00] davija at cshp dot info Description: Not having a x64 official release build at this point is laughable. While you can run the x86 version by tweaking a configuration setting, this breaks the ability for IIS to run other .net applications that require x64 support. Expecting that you can just run them on another server isn't really acceptable either. Please provide an official release for x64. Many of us aren't really all that concerned that there may not be a performance increase at this point, we just need a version that is compatible with our server requirements. Reproduce code: --- Install php alongside something like cc.net on a x64 box Expected result: you should be able to have x64 .net apps run in the same server as php. Actual result: -- I have to setup a whole new server to run php apps. This is a very expensive waste of machine equipment. -- Edit this bug report at http://bugs.php.net/?id=49492edit=1
#49492 [Bgs]: I need 64bit package
ID: 49492 Updated by: paj...@php.net Reported By: davija at cshp dot info Status: Bogus Bug Type: IIS related Operating System: Windows 2003 x64 PHP Version: 5.3.0 New Comment: Please ask support questions either in the IIS forums, the php-install mailing list or whatever is your favorite support channel. But let me tell you a last time some facts: - You can run x86 PHP on x64 servers. - You should run FCGI and not ISAPI - Apache does not provide nor support windows x64 yet Have a nice day :) Previous Comments: [2009-09-07 19:35:57] davija at cshp dot info As I stated above, you cannot run 32 bit stuff smoothly in a x64 environment when you have stuff that requires .net x64. In the distribution on the QA for x64, there were no server based extenstions, apache or IIS. [2009-09-07 18:36:10] paj...@php.net Btw, you can run 32bit versions smoothly in a 64bit server :) [2009-09-07 18:29:14] paj...@php.net And that's laughable. ISAPI is deprecated and the FCGI SAPI is recommended instead (by php.net and the IIS team). As such it has been removed from our releases, in 5.3.0 and later. more infos on www.iis.net. [2009-09-07 18:26:03] davija at cshp dot info I looked at the ones on the QA site, but they didn't have any of the IIS isapi dll's built in. [2009-09-07 18:15:20] paj...@php.net Not having a x64 official release build at this point is laughable. What is laughable is the fact that I never heard of you before so I won't bother to much about your sense of humour. You can laugh at us if you help :) x64 support is experimental and as such it is available in our QA downloads: http://windows.php.net/qa/ 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/49492 -- Edit this bug report at http://bugs.php.net/?id=49492edit=1
#48216 [Opn]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
ID: 48216
Updated by: sjo...@php.net
Reported By: mark at everytruckjob dot com
Status: Open
Bug Type: SOAP related
Operating System: CentOs 5.3
PHP Version: 5.3.0RC2
New Comment:
Thank you for your feedback.
It would be most helpful to us if you could supply us with the HTTP
transaction of the retrieval of the WSDL. You may use a sniffer like
Wireshark to obtain this information, or use this script I wrote
http://www.gissen.nl/files/sniff.php.
Previous Comments:
[2009-09-07 00:43:35] michael dot tibben at gmail dot com
We are experiencing a similar issue. However, the HTTP reply is using
chunked transfer encoding (Content-Length is NOT required when using
chunked)
HTTP/1.1 200 OK
Date: Sun, 06 Sep 2009 23:25:16 GMT
Server: Apache
X-Powered-By: Servlet/2.4 JSP/2.0
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
[2009-06-24 10:23:47] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
The WSDL URL you supply does not send a Content-Length or
Transfer-Encoding header in some cases, which is mandatory in a response
with a body. In other words, it does not follow the HTTP protocol. You
should contact the provider of the WSDL about this.
GET /url HTTP/1.0
Host: example.com
HTTP/1.1 200 OK
Date: Wed, 24 Jun 2009 10:18:10 GMT
Server: Apache
Connection: close
Content-Type: text/xml
?xml version=1.0 encoding=UTF-8?...
[2009-05-09 23:12:48] mark at everytruckjob dot com
Description:
Trying to set up a soapClient using the wsdl from the location found in
http://www.everytruckjob.com/php53-url.txt (this contains the url and is
not the wsdl file itself so I can remove the location once this report
is closed as it is not my soap server).
Copying the wsdl from the referenced location to my own
(http://www.everytruckjob.com/wsdl.php) or saving it to a local file
allows parsing to succeed, but while the file sizes seem to be the same,
I can't figure out what headers or content causes the Extra content at
the end of the document error.
This works as expected on php 5.2.9 compiled and in use on the same
client server with Centos 5.3 libxml2.x86_64 2.6.26-2.1.2.7.
Reproduce code:
---
?php
$wsdl =
trim(file_get_contents('http://www.everytruckjob.com/php53-url.txt'));
try {
$a = new SoapClient($wsdl);
} catch (SoapFault $e) {
var_dump(libxml_get_last_error());
var_dump($e);
}
?
Expected result:
No SoapFault
Actual result:
--
object(LibXMLError)#1 (6) { [level]= int(3) [code]= int(5)
[column]= int(4) [message]= string(41) Extra content at the end
of the document [file]= string(55) http://; [line]=
int(488) }
object(SoapFault)#2 (9) {
[message:protected]= string(146) SOAP-ERROR: Parsing WSDL:
Couldn't load from 'X' : Extra content at the end of the document
--
Edit this bug report at http://bugs.php.net/?id=48216edit=1
#47624 [Opn-Fbk]: SOAP response has int type for a key value that is out of range
ID: 47624 Updated by: sjo...@php.net Reported By: akshah123 at hotmail dot com -Status: Open +Status: Feedback Bug Type: SOAP related Operating System: Linux PHP Version: 5.3.0 New Comment: Thank you for your bug report. Could you please supply us with a piece of WSDL describing the array? Also, which client are you using which gives this error? If I understand correctly, the problem occurs with the soapenc:array type and the Axis 1 SOAP library. Previous Comments: [2009-09-01 21:26:28] akshah123 at hotmail dot com Hello, I have confirmed that this issue is in 5.3.0 and 5.2.10. [2009-03-20 15:06:49] akshah123 at hotmail dot com Is there any additional information that I can provide to perhaps speed up the process to resolve this ticket? [2009-03-11 14:49:18] akshah123 at hotmail dot com Description: It seems that instead of string, new version of PHP (5.2.9) has key xsi:type=xsd:int884385070380/key as opposed to for old version of PHP (5.2.2) returning key xsi:type=xsd:string884385070380/key for arrays in SOAP services. This causes the client to throw a soap fault error with SOAP-ERROR: Encoding: Can't decode apache map, only Strings or Longs are allowd as keys. -- Edit this bug report at http://bugs.php.net/?id=47624edit=1
#27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Comment by: benadler at gmx dot net Reported By: ghoffer at globalscape dot com Status: Feedback Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: I checked using Process Monitor - convert.exe is NOT started by the correct user: User: NT AUTHORITY\NETWORK SERVICE Auth ID: :03e4 Previous Comments: [2009-09-07 11:34:10] paj...@php.net I'm not sure the users environment is set, that's a different thing. But is it the correct user? [2009-09-07 11:17:13] benadler at gmx dot net Hope I'm not too verbose. Maybe it helps to see that calling this exec(d:/programme/imagemagick/convert.exe -density $density $baseDirectory/$bookId/document.pdf -quality 95 $baseDirectory/$bookId/$version/page_%04d.jpg, $output); print_r($output); in a script run by the webserver (as above) causes this: Array ( [0] = Error: /invalidfileaccess in --showpage-- [1] = Operand stack: [2] =--nostringval-- 1 true [3] = Execution stack: [4] =%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 4 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1777 1 9 %oparray_pop --nostringval-- --nostringval-- [5] = Dictionary stack: [6] =--dict:1155/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:275/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:22/40(L)-- [7] = Current allocation mode is local [8] = Last OS error: Bad file descriptor ) [2009-09-07 11:11:06] benadler at gmx dot net Ok, it works on the commandline but not using IIS6 and fastcgi with fastcgi.impersonate = 1;. This is test.php: ?php $out = array(); echo exec(echo %USERNAME%, $out); print_r($out); $out = array(); echo exec(echo %USERPROFILE%, $out); print_r($out); ? and this results in: %USERNAME%Array ( [0] = %USERNAME% ) C:\Documents and Settings\Default UserArray ( [0] = C:\Documents and Settings\Default User ) So it seems the user's profile/environment is not correctly set up. I think username should be either domain\deabjs1 or just deabjs1, because this is what I use to log on to IIS using NTLM. I'm still using the same snapshot I was using at [6 Sep 6:13pm UTC]. Thanks for your help! ben [2009-09-06 18:13:09] benadler at gmx dot net I tried the newest snapshot and it seems to work - thank you! But, could it be that the environment is not set up correctly? Suddenly I start getting all those imagemagick-temp files in the script's directory. I imagine the reason may be that the %TEMP% or %TMP% system/user variables are not set correctly. [2009-09-03 21:17:45] paj...@php.net Please (all :) try a snapshot, php 5.3 or 6 (5.3 recommended anyway :). 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051edit=1
#29085 [Com]: bad default include_path on Windows
ID: 29085 Comment by: php dot netsm at majorsite dot com Reported By: christian at wenz dot org Status: Open Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.0.0RC3 New Comment: I, too, find this VERY confusing, and I can't seem to get around it. Running Win2K Server (was to upgrade this year - market stopped that...) and have had PHP running on 5.0.3 for awhile (in C:\Program Files\PHP - the 'default' from the install). Went to upgrade and found latest versions need Win2003 Server or better, so I had to take 5.2.10, but I cannot get the .ini to read. Install.txt file says to avoid \program files\ so I deleted that and went for a 'clean' install to \php\ phpinfo() says I'm looking at loaded .ini from C:\PHP\php.ini I've tried setting the php.ini include_path = .;c:\php;c:\php\ext, yet phpinfo() says include_path is .;C:\php5\pear The comments on this page were from 2004 - and the 'fix' was that people want to run php4 and php5, though, how long has php4 been gone, and this issue is still relevant 5 years on. this IS (IMHO) a BAD thing and very confusing. I look forward to some reply as I now have php running again, but none of my databases run, none of my 'include' files work, etc. And, please do not tell me to save my .ini file in some other location - I've tried \winnt\system32, \winnt, c:\ and certainly c:\php - nothing has worked. I am almost frustrated enough to try c:\php5 and even c:\php5\pear, but I am trying to use the install instructions! I think this php5 error is a bug and should be fixed - even in other versions of php (for those of us that can't afford the upgrade). Previous Comments: [2005-02-15 01:08:11] tony2...@php.net This is not a bug, but change request. Reclassifying. [2005-01-05 21:34:30] justin at telepop dot net This setting just caused me some problems. Somehow my php.ini had a bad path in its include_path setting. Rather than spit out an error, it assumed that c:\php4\pear was my default include directory, and gave me little information to figure out why. Once I fixed the path, my declared settings took effect and everything worked fine, but it wasn't a very intuitive leap to see why that include path was showing up. [2004-08-06 08:54:57] christian at wenz dot org sorry, here I completely disagree. Of course it _is_ possible to change the include_path manually or within the script, however there is a divergence between the installation section of the manual (where it says C:\php) and this built-in behavior of PHP (C:\php5). Also, I know of only very few people who actually use both versions on one machine (only few now of the possibility to store php.ini in the PHP directory and not in the Windows directory; furthermore you have to use PHP as CGI). This bug appears again and again; I am getting 2-3 reader mails about this per month; and it is (IMO) just annoying. Therefore, one thing has to change IMO: either the installation recommends installing PHP into C:\php5, or the include_path is set to something that includes C:\php. Of course, the latter is preferable. So I dare to reopen this one :) [2004-08-05 23:33:44] ed...@php.net Well this is a matter of opinion :) Most people prefer to be able to run php4 and php5 on the same box right now. This might change in the future. Anyway setting include_path in php.ini isn't that difficult, is it :) [2004-07-10 13:50:01] christian at wenz dot org Description: the default include_path on Windows systems is .;c:\php5\pear. IMO that's a bad idea (TM) because most installation tutorials recommend c:\php and the PEAR installer defaults to that directory, too. Looks like a port of bug #21609 :-) Reproduce code: --- call phpinfo(), look at output for include_path Expected result: Directive Local Value Master Value include_path .;C:\php\pear .;C:\php\pear Actual result: -- Directive Local Value Master Value include_path .;C:\php5\pear .;C:\php5\pear -- Edit this bug report at http://bugs.php.net/?id=29085edit=1
#49267 [Com]: Linking fails for iconv: Undefined symbols: _libiconv
ID: 49267 Comment by: notfornoone at gmail dot com Reported By: s dot rost at ewerk dot com Status: Assigned Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: The instructions in the first comment worked for me, here is what I did to successfully install php-5.3.1RC1 on Snow Leopard. This also worked for php-5.2.11RC1 on Snow Leopard. 1. I changed ext/iconv/iconv.c as per the first comment on this bug. On line 185 change #ifdef HAVE_LIBICONV #define iconv libiconv #endif to #ifdef HAVE_LIBICONV #define iconv iconv #endif 2. Run configure ./configure --prefix=/usr/local/php/5.3.1RC1 --with-apxs2=/usr/sbin/apxs I found that after changing the iconv.c file I did not need to add -lsresolv to EXTRA_LIBS Previous Comments: [2009-09-06 03:47:43] me at sleepycode dot com I have the same issue as well with Snow Leopard and any version of PHP I try. I have built my own libiconv and this made little difference. My configure line: ./configure --prefix=/home/software/php/v5 \ --sysconfdir=/etc \ --localstatedir=/var \ --mandir=/usr/share/man \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-apxs2=/home/software/apache/bin/apxs \ --enable-maintainer-zts \ --with-zlib-dir=/home/software/zlib \ --with-pgsql=/home/software/postgresql \ --enable-mbstring \ --with-gd \ --with-png-dir=/home/software/libpng \ --with-iconv=/home/software/iconv The build error during make: Undefined symbols: _libiconv_open, referenced from: _do_convert in gdkanji.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_substr in iconv.o __php_iconv_substr in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _php_iconv_stream_filter_ctor in iconv.o _libiconv, referenced from: _do_convert in gdkanji.o _libiconv_close, referenced from: _do_convert in gdkanji.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_substr in iconv.o __php_iconv_substr in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _php_iconv_stream_filter_dtor in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 [2009-09-06 00:04:17] aoyagi dot kouhei at gmail dot com Snow Leopard PHP5.3.1RC1 ./configure --prefix=/opt/php-5.3.1RC1 --enable-zip --with-apxs2=/opt/httpd/bin/apxs --with-bz2 --enable-calendar --with-curl --with-gd --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --with-pdo-pgsql=/opt/postgresql --with-pgsql=/opt/postgresql --enable-soap --enable-sockets --with-jpeg-dir=/opt/jpeg --with-png-dir=/opt/libpng --with-freetype-dir=/opt/freetype --with-zlib --with-libxml-dir=/opt/libxml2 --with-xsl=/opt/libxslt --with-readline=/opt/readline --with-gettext=/opt/gettext --with-iconv-dir=/opt/libiconv make Undefined symbols: _libiconv_open, referenced from: _do_convert in gdkanji.o _libiconv, referenced from: _do_convert in gdkanji.o __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _libiconv_close, referenced from: _do_convert in gdkanji.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 [2009-09-04 05:34:43] jay3ld at yahoo dot com Has any progress been made towards this with Snow Leopard? I am receiving the same issue with both PHP 5.3 and PHP 6. I don't get the above error. My error occurs during the configure stage. checking for iconv support... yes checking for iconv... no checking for libiconv... no checking for libiconv in -liconv... no checking for iconv in -liconv... no configure: error: Please reinstall the iconv library. I even tried to download and build a
#49493 [NEW]: gethostbyname IPv6
From: tim987 at email dot com Operating system: Windows/Linux PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: gethostbyname IPv6 Description: The php function gethostbyname currently only returns IPv4 addresses as stated here: http://us2.php.net/manual/en/function.gethostbyname.php My feature request is, it should be able to return IPv6 addresses too. -- Edit bug report at http://bugs.php.net/?id=49493edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49493r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49493r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49493r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49493r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49493r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49493r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49493r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49493r=needscript Try newer version: http://bugs.php.net/fix.php?id=49493r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49493r=support Expected behavior: http://bugs.php.net/fix.php?id=49493r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49493r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49493r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49493r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49493r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49493r=dst IIS Stability: http://bugs.php.net/fix.php?id=49493r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49493r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49493r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49493r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49493r=mysqlcfg
#49494 [NEW]: php5apache2.dll not present in zip or msi
From: webmaster at pnmx dot com Operating system: Vista PHP version: 5.3.0 PHP Bug Type: Apache2 related Bug description: php5apache2.dll not present in zip or msi Description: php5papache2.dll mentioned in install.txt is not part of distributions on php.net. A couple of third party sources offer the dll, but their trustworthiness in unknown. Would prefer to download the file from php.net, the apache project, or at worst from sourceforge. Please don't say this doesn't indicate a bug in PHP. Duh! It's a bug in the distribution of PHP. That should matter too. This problem has been in every Windows version of PHP that I've ever installed. Why does it keep recurring? Reproduce code: --- Download and install php5.3 using either the Windows msi installer or by unpacking the 5.3 zip archive. In both cases, there is no php5papache2.dll or similar in the install directory. Expected result: php5papache2.dll available from php.net, ideally installed along with other elements of the configuration. Actual result: -- php5papache2.dll is not available from a trustworthy site. -- Edit bug report at http://bugs.php.net/?id=49494edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49494r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49494r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49494r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49494r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49494r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49494r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49494r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49494r=needscript Try newer version: http://bugs.php.net/fix.php?id=49494r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49494r=support Expected behavior: http://bugs.php.net/fix.php?id=49494r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49494r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49494r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49494r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49494r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49494r=dst IIS Stability: http://bugs.php.net/fix.php?id=49494r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49494r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49494r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49494r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49494r=mysqlcfg
#49494 [Com]: php5apache2.dll not present in zip or msi
ID: 49494 Comment by: webmaster at pnmx dot com Reported By: webmaster at pnmx dot com Status: Open Bug Type: Apache2 related Operating System: Vista PHP Version: 5.3.0 New Comment: FYI, there's no php5apache2_2.dll present either. There is a php5.dll but if you change httpd.conf to load that file, you get: Can't locate API module structure `php5_module' in file D:/Programs/PHP5.3/php5.dll So it's clearly not just misnamed. Previous Comments: [2009-09-08 04:26:44] webmaster at pnmx dot com Description: php5papache2.dll mentioned in install.txt is not part of distributions on php.net. A couple of third party sources offer the dll, but their trustworthiness in unknown. Would prefer to download the file from php.net, the apache project, or at worst from sourceforge. Please don't say this doesn't indicate a bug in PHP. Duh! It's a bug in the distribution of PHP. That should matter too. This problem has been in every Windows version of PHP that I've ever installed. Why does it keep recurring? Reproduce code: --- Download and install php5.3 using either the Windows msi installer or by unpacking the 5.3 zip archive. In both cases, there is no php5papache2.dll or similar in the install directory. Expected result: php5papache2.dll available from php.net, ideally installed along with other elements of the configuration. Actual result: -- php5papache2.dll is not available from a trustworthy site. -- Edit this bug report at http://bugs.php.net/?id=49494edit=1
