[PHP-BUG] Bug #51185 [Com]: Apache won't start after PHP 5.3.1 is installed
Edit report at http://bugs.php.net/bug.php?id=51185&edit=1 ID: 51185 Comment by: Reported by: randy at thehiringsurvey dot com Summary: Apache won't start after PHP 5.3.1 is installed Status: Open Type: Bug Package: Windows Installer Operating System: Windows 7 (x64) PHP Version: 5.3.1 New Comment: I had the same problem with OE Windows Server 2003 ... I had to downgrade to previous release Previous Comments: [2010-03-02 23:17:31] j...@php.net -Package: Apache2 related +Package: Windows Installer [2010-03-02 22:41:08] randy at thehiringsurvey dot com Description: This is a development desktop computer, not a production server. Windows 7 Home Premium 64-bit, fully patched Avast Antivirus, Home edition, fully patched Apache 2.2 installed via the full installer (apache_2.2.14-win32-x86-openssl-0.9.8k.msi) PHP 5.3.1 installed via the full installer (php-5.3.1-Win32-VC6-x86.msi) MySQL 5.1 is also installed and the service started, but I have not even attempted to connect yet, because Apache can't run. (mysql-5.1.44-winx64.msi) I had never downloaded any other/previous versions of Apache or PHP. All of the files I am dealing with came from these installers. Apache starts and runs fine until I install PHP and reboot Windows (PHP doesn't seem to work after the install until I reboot.) After I install PHP and reboot, Apache refuses to start. The Windows event log describes the failure: Event 1000 Description: Faulting application name: httpd.exe, version: 2.2.14.0, time stamp: 0x4ac181d6 Faulting module name: php5ts.dll, version: 5.3.1.0, time stamp: 0x4b051b35 Exception code: 0xc005 Fault offset: 0x000e618c Faulting process id: 0x10f4 Faulting application start time: 0x01caba41084e6e4e Faulting application path: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin\httpd.exe Faulting module path: C:\Program Files (x86)\PHP\php5ts.dll Report Id: 46094170-2634-11df-80a6-00241d23de59 Apache's error log is not updated when this occurs. I'm guessing that is because the failure is before the logging is running. I found a few support threads here and elsewhere, where people cold generate similar problems by manually installing php5apache2_2.dll instead of php5apache2.dll (or vice versa). I'm on Apache 2.2 and using the correct php5apache2_2.dll, so that doesn't seem to be the problem. This is what was appended to the httpd.conf file by the PHP installer: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "C:/Program Files (x86)/PHP/" LoadModule php5_module "C:/Program Files (x86)/PHP/php5apache2_2.dll" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL The files php5apache2_2.dll and php5ts.dll are both present in the PHPIniDir, and seem to have completely normal security settings. Apache is running as System and System has full control of both files. I checked that the PHP Path entry and the PHPRC environment variable are set correctly. They are. Uninstalling, deleting, redownloading, and reinstalling the same version of PHP results in the same error. Uninstalling, deleting, downloading PHP 5.2.13 , and installing that version of PHP works just fine (php-5.2.13-win32-installer.msi). During the PHP 5.2.13 install I selected Apache 2.2 for the web server. I made no other configuration changes. It just worked. I'm running PHP 5.2.13 now. So I'll wait and retry 5.3.x later... Many thanks, Randy -- Edit this bug report at http://bugs.php.net/bug.php?id=51185&edit=1
[PHP-BUG] Bug #51192 [Opn]: FILTER_VALIDATE_URL will invalidate a hostname that includes '-'
Edit report at http://bugs.php.net/bug.php?id=51192&edit=1
ID: 51192
User updated by: solar at azrael dot ws
Reported by: solar at azrael dot ws
-Summary: FILTER_VALIDATE_URL will invalidate an url with a
hostname that includes
+Summary: FILTER_VALIDATE_URL will invalidate a hostname that
includes '-'
Status: Open
Type: Bug
Package: Filter related
Operating System: linux
PHP Version: 5.2.13
New Comment:
Changes summary. That was too long.
Previous Comments:
[2010-03-03 08:56:18] solar at azrael dot ws
Oops.
Test script:
var_dump(filter_var('http://example.com', FILTER_VALIDATE_URL));
var_dump(filter_var('http://exa-mple.com', FILTER_VALIDATE_URL));
var_dump(filter_var('http://exa_mple.com', FILTER_VALIDATE_URL));
[2010-03-03 08:49:39] solar at azrael dot ws
Description:
Hostname must contain only alpha-numeric letters and the hyphen(-).
Test script:
---
var_dump(filter_var(
Expected result:
string(18) "http://example.com";
string(19) "http://exa-mple.com";
bool(false)
Actual result:
--
string(18) "http://example.com";
bool(false)
string(19) "http://exa_mple.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=51192&edit=1
[PHP-BUG] Bug #18601 [Com]: Install Failed - stub.lo not found
Edit report at http://bugs.php.net/bug.php?id=18601&edit=1 ID: 18601 Comment by: Reported by: eric at webdevaz dot com Summary: Install Failed - stub.lo not found Status: Bogus Type: Bug Package: Compile Failure Operating System: RedHat 7.2 PHP Version: 4.2.2 New Comment: Good evening. Hello. This site is so full of information. Help me! Help to find sites on the: banks. I found only this - http://www.honbu.fi/Members/CreditChecks/motorcycle-loans";>motorcycle loans. Credit checks, matters likely tend that if you maintain your societies simply and approach within your issuers, you are more being to be instant and principal on the staff as well. Credit checks, american red cross bad account handyman and amount forms want car and term country to kinds of laws solely who think as a property of front and possible displays around the happiness. THX :rolleyes:, Lal from Burkina. Previous Comments: [2002-07-26 18:04:53] sni...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-07-26 13:13:17] eric at webdevaz dot com During a Clean install of php 4.2.2, the make process failed due to a file not found - stub.lo My linux boxes are bare bones - just server setups with apache and php. I can install 4.2.1 without the problem. Thanks in advance, Eric Zizzi webdevaz.com -- Edit this bug report at http://bugs.php.net/bug.php?id=18601&edit=1
[PHP-BUG] Bug #51192 [Opn->Asn]: FILTER_VALIDATE_URL will invalidate a hostname that includes '-'
Edit report at http://bugs.php.net/bug.php?id=51192&edit=1
ID: 51192
Updated by: ahar...@php.net
Reported by: solar at azrael dot ws
Summary: FILTER_VALIDATE_URL will invalidate a hostname that
includes '-'
-Status: Open
+Status: Assigned
Type: Bug
Package: Filter related
Operating System: linux
PHP Version: 5.2.13
Assigned To: aharvey
New Comment:
Yeah, that doesn't quite look right. :)
Cheers for the patch; I'll cook up a test script to go with it and
commit it.
Previous Comments:
[2010-03-03 09:50:24] ahar...@php.net
Yeah, that doesn't quite look right. :)
Cheers for the patch; I'll cook up a test script to go with it and
commit it.
[2010-03-03 09:41:07] solar at azrael dot ws
Changes summary. That was too long.
[2010-03-03 08:56:18] solar at azrael dot ws
Oops.
Test script:
var_dump(filter_var('http://example.com', FILTER_VALIDATE_URL));
var_dump(filter_var('http://exa-mple.com', FILTER_VALIDATE_URL));
var_dump(filter_var('http://exa_mple.com', FILTER_VALIDATE_URL));
[2010-03-03 08:49:39] solar at azrael dot ws
Description:
Hostname must contain only alpha-numeric letters and the hyphen(-).
Test script:
---
var_dump(filter_var(
Expected result:
string(18) "http://example.com";
string(19) "http://exa-mple.com";
bool(false)
Actual result:
--
string(18) "http://example.com";
bool(false)
string(19) "http://exa_mple.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=51192&edit=1
[PHP-BUG] Bug #37675 [Com]: OOP -> Maximum function nesting error
Edit report at http://bugs.php.net/bug.php?id=37675&edit=1
ID: 37675
Comment by:
Reported by: thomas at ecommerce dot com
Summary: OOP -> Maximum function nesting error
Status: Bogus
Type: Bug
Package: Unknown/Other Function
Operating System: SuSE Linux 10,0
PHP Version: 5.1.4
New Comment:
This arbitrary limit is set by xDebug. If you disable it you will find
out that PHP aborts when the stack is exhausted ("Segmentation fault"),
rather than after 100 function calls.
I reply to this old thread because I couldn't find this simple sollution
anywhere on the internets. Hopefully it helps someone.
Previous Comments:
[2006-06-02 11:00:48] 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
$this doesn\'t move to the static scope after calling it...
[2006-06-02 11:00:10] thomas at ecommerce dot com
You didn't test it at all. I have xDebug installed, yea, but also
without acitvated any special modul/extension i get:
php test.php
Fatal error: Allowed memory size of 62914560 bytes exhausted (tried to
allocate 12 bytes) in /home/Thomas/test.php on line 10
because of endless loop
[2006-06-02 10:55:30] tony2...@php.net
Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader. These extensions often modify engine
behavior which is not related to PHP itself.
There is no such error message in PHP itself.
[2006-06-02 10:46:40] thomas at ecommerce dot com
Description:
PHP 5.1.4 seams like running an endless loop here with this code. When
running the bottom code, i get following error message:
Fatal error: Maximum function nesting level of '100' reached, aborting!
in /home/Thomas/test.php on line 11
Its not possibe, that this cause an endless loop. $this is setted, when
created with 'new', so checkthis() should only be called 2 times.
Reproduce code:
---
anyVar)) {
$obj = new Test1();
return $obj->checkThis($var);
}
echo "$var\n";
}
}
$return = Test1::checkThis("Works!");
var_dump($return);
Expected result:
Output of script should be:
Works!
NULL
Actual result:
--
Fatal error: Maximum function nesting level of '100' reached, aborting!
in /home/Thomas/test.php on line 11
--
Edit this bug report at http://bugs.php.net/bug.php?id=37675&edit=1
[PHP-BUG] Bug #51192 [Asn->Csd]: FILTER_VALIDATE_URL will invalidate a hostname that includes '-'
Edit report at http://bugs.php.net/bug.php?id=51192&edit=1 ID: 51192 Updated by: ahar...@php.net Reported by: solar at azrael dot ws Summary: FILTER_VALIDATE_URL will invalidate a hostname that includes '-' -Status: Assigned +Status: Closed Type: Bug Package: Filter related Operating System: linux PHP Version: 5.2.13 Assigned To: aharvey New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-03-03 10:26:58] ahar...@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. [2010-03-03 10:25:52] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=295773 Log: Fix for bug #51192 (FILTER_VALIDATE_URL will invalidate a hostname that includes '-'). Original patch by so...@azrael.ws. [2010-03-03 09:50:24] ahar...@php.net -Status: Open +Status: Assigned [2010-03-03 09:50:24] ahar...@php.net Yeah, that doesn't quite look right. :) Cheers for the patch; I'll cook up a test script to go with it and commit it. [2010-03-03 09:41:07] solar at azrael dot ws Changes summary. That was too long. 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=51192 -- Edit this bug report at http://bugs.php.net/bug.php?id=51192&edit=1
Bug #1 [Com]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Comment by: j...@php.net Reported by: rasmus at lerdorf dot on dot ca Summary: Apache 1.3b3 + mod_php3 is slow Status: Closed Type: Bug Package: Performance problem Operating System: Solaris 2.5.1 PHP Version: 3.0b3 Assigned To: jani New Comment: testing "anonymous" commenting. :) Previous Comments: [2010-03-02 23:40:16] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=XXX Log: Test [2010-03-02 23:36:48] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=XXX Log: Test [2010-03-02 23:33:20] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=XXX Log: Test [2010-03-02 23:33:14] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=XXX Log: Test [2010-03-02 23:24:27] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=XXX Log: Test 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=1 -- Edit this bug report at http://bugs.php.net/bug.php?id=1&edit=1
Bug #47021 [Com]: SoapClient stumbles over WSDL delivered with "Transfer-Encoding: chunked"
Edit report at http://bugs.php.net/bug.php?id=47021&edit=1 ID: 47021 Comment by: Reported by: daniel dot gorski at develnet dot org Summary: SoapClient stumbles over WSDL delivered with "Transfer-Encoding: chunked" Status: To be documented Type: Bug Package: SOAP related Operating System: Linux PHP Version: 5.3CVS-2009-01-06 (CVS) New Comment: Have you tried to recompile PHP with --without-curlwrapper? I solved my case. Previous Comments: [2009-05-17 05:18:55] shadda at gmail dot com I ran into this bug today myself, and after having compiled the latest snapshot as of 8:00pm CST 2009-05-16 I am still experiencing this error. [2009-04-16 10:56:27] bj...@php.net This was fixed by introducing an 'dechunk' stream filter, see http://news.php.net/php.cvs/57042 [2009-04-16 10:34:48] dmi...@php.net This bug has been fixed in CVS. 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. [2009-01-26 10:54:53] giovanni at giacobbi dot net Please see related discussion: http://marc.info/?t=12329199332&r=1&w=2 See also bug report #43069 which actually caused this bug. [2009-01-22 15:35:02] ml at x-net dot be I can confirm this bug. I tried avoiding the chunking in Apache by using mod_deflate, but the PHP SOAP client probably doesn't send an Accept-Encoding header with gzip in it. 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=47021 -- Edit this bug report at http://bugs.php.net/bug.php?id=47021&edit=1
Bug #51187 [Com]: Segmentation fault with Zend_Form/Zend_View
Edit report at http://bugs.php.net/bug.php?id=51187&edit=1 ID: 51187 Comment by: weierophin...@php.net Reported by: bostjan at a2o dot si Summary: Segmentation fault with Zend_Form/Zend_View Status: Feedback Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: Irrelevant New Comment: I understand completely what's happening -- you set the value of the object to the object itself; when rendering, it then attempts to cast the value to a string, which means casting the object to a string... which means rendering the element, which will in turn need to cast the value to a string. It's indeed recursion. I can potentially put in some recursion detection in ZF; I'm not sure if the PHP team wants to investigate the segfault, however. Personally, though, I'd consider fixing the code instead, to ensure you're not overwriting the value passed to the function (which is the real error here). Previous Comments: [2010-03-03 04:54:53] ahar...@php.net You can find instructions on generating a backtrace at http://bugs.php.net/bugs- generating-backtrace.php. [2010-03-03 04:54:52] ahar...@php.net -Status: Open +Status: Feedback [2010-03-03 04:33:33] bostjan at a2o dot si It most certainly is an endless recursion, though it should only lead to memory limit error. How do I acquire a stack track? [2010-03-03 00:37:52] johan...@php.net I assume this is an endless recursion, can you please provide a stacktrack? [2010-03-03 00:37:51] johan...@php.net -Status: Open +Status: Feedback 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=51187 -- Edit this bug report at http://bugs.php.net/bug.php?id=51187&edit=1
[PHP-BUG] Bug #51196 [NEW]: SQLT_INT or OCI_B_INT not binding correctly
From: Operating system: linux 2.6.21.7-2.fc8xen PHP version: 5.3.1 Package: OCI8 related Bug Type: Bug Bug description:SQLT_INT or OCI_B_INT not binding correctly Description: When trying to bind the return value of a function as SQLT_INT or OCI_B_INT, the value that is bound upon return shows as int(-4294964414), where the expected is 2882, in our case. The oracle function returns NUMBER data type. Changing the bind type to SQLT_CHAR resolves the problem. This worked in php 5.2.11 -- Edit bug report at http://bugs.php.net/bug.php?id=51196&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51196&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51196&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51196&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51196&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51196&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51196&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51196&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51196&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51196&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51196&r=support Expected behavior: http://bugs.php.net/fix.php?id=51196&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51196&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51196&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51196&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51196&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51196&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51196&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51196&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51196&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51196&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51196&r=mysqlcfg
Bug #51187 [Fbk->Opn]: Segmentation fault with Zend_Form/Zend_View
Edit report at http://bugs.php.net/bug.php?id=51187&edit=1 ID: 51187 User updated by: bostjan at a2o dot si Reported by: bostjan at a2o dot si Summary: Segmentation fault with Zend_Form/Zend_View -Status: Feedback +Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: Irrelevant New Comment: :) Code was fixed imediately because segfaults were persistent and thus development stopped. It still is a PHP crashing bug though (and ZF inconvenience bug if there is such a thing). Previous Comments: [2010-03-03 13:32:06] weierophin...@php.net I understand completely what's happening -- you set the value of the object to the object itself; when rendering, it then attempts to cast the value to a string, which means casting the object to a string... which means rendering the element, which will in turn need to cast the value to a string. It's indeed recursion. I can potentially put in some recursion detection in ZF; I'm not sure if the PHP team wants to investigate the segfault, however. Personally, though, I'd consider fixing the code instead, to ensure you're not overwriting the value passed to the function (which is the real error here). [2010-03-03 04:54:53] ahar...@php.net You can find instructions on generating a backtrace at http://bugs.php.net/bugs- generating-backtrace.php. [2010-03-03 04:54:52] ahar...@php.net -Status: Open +Status: Feedback [2010-03-03 04:33:33] bostjan at a2o dot si It most certainly is an endless recursion, though it should only lead to memory limit error. How do I acquire a stack track? [2010-03-03 00:37:52] johan...@php.net I assume this is an endless recursion, can you please provide a stacktrack? 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=51187 -- Edit this bug report at http://bugs.php.net/bug.php?id=51187&edit=1
Bug #51196 [Com]: SQLT_INT or OCI_B_INT not binding correctly
Edit report at http://bugs.php.net/bug.php?id=51196&edit=1 ID: 51196 Comment by: Reported by: joel at layers dot com Summary: SQLT_INT or OCI_B_INT not binding correctly Status: Open Type: Bug Package: OCI8 related Operating System: linux 2.6.21.7-2.fc8xen PHP Version: 5.3.1 New Comment: As a test, try this PLSQL function with the SQLT_INT or OCI_B_INT bind types... CREATE OR REPLACE FUNCTION FUNCTION1 RETURN NUMBER AS BEGIN RETURN 234; END FUNCTION1; Previous Comments: [2010-03-03 13:53:51] joel at layers dot com Description: When trying to bind the return value of a function as SQLT_INT or OCI_B_INT, the value that is bound upon return shows as int(-4294964414), where the expected is 2882, in our case. The oracle function returns NUMBER data type. Changing the bind type to SQLT_CHAR resolves the problem. This worked in php 5.2.11 -- Edit this bug report at http://bugs.php.net/bug.php?id=51196&edit=1
[PHP-BUG] Req #51197 [NEW]: eadgermund
From: Operating system: eadgermund PHP version: 6SVN-2010-03-03 (SVN) Package: Output Control Bug Type: Feature/Change Request Bug description:eadgermund Description: uncertain related greenhouse companies -- Edit bug report at http://bugs.php.net/bug.php?id=51197&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51197&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51197&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51197&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51197&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51197&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51197&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51197&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51197&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51197&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51197&r=support Expected behavior: http://bugs.php.net/fix.php?id=51197&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51197&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51197&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51197&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51197&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51197&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51197&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51197&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51197&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51197&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51197&r=mysqlcfg
Req #51197 [Opn->Spm]: eadgermund
Edit report at http://bugs.php.net/bug.php?id=51197&edit=1 ID: 51197 Updated by: ahar...@php.net Reported by: eadgermunde at transy dot edu Summary: eadgermund -Status: Open +Status: Spam Type: Feature/Change Request Package: Output Control Operating System: eadgermund PHP Version: 6SVN-2010-03-03 (SVN) New Comment: I have a friend who needs a greenhouse, and is quite uncertain about how to build one. I don't think Phil's related to PHP any more than this bug report, though. Previous Comments: [2010-03-03 15:26:09] ahar...@php.net I have a friend who needs a greenhouse, and is quite uncertain about how to build one. I don't think Phil's related to PHP any more than this bug report, though. [2010-03-03 14:40:25] eadgermunde at transy dot edu Description: uncertain related greenhouse companies -- Edit this bug report at http://bugs.php.net/bug.php?id=51197&edit=1
Bug #51190 [Com]: ftp_put() returns false when transfer was successful
Edit report at http://bugs.php.net/bug.php?id=51190&edit=1 ID: 51190 Comment by: Reported by: alexclifford47 at gmail dot com Summary: ftp_put() returns false when transfer was successful Status: Open Type: Bug Package: FTP related Operating System: Windows Server 2003 R2 32-bit PHP Version: 5.3.1 New Comment: I'm having the exact same problem.. The upload is successful , however ftp_put returns false... Any info would be appreciated. Thanks Ameya Previous Comments: [2010-03-03 05:47:50] alexclifford47 at gmail dot com Description: Hi, I am getting the following warning message when trying to use ftp_put(): Warning: ftp_put(): Transfer OK This is causing the function to return false, when in fact the file is transferred successfully. I have Googled this warning message but no one else has ever received it. Where is this warning coming from and why is PHP reporting a "Transfer OK" as a warning? Destination server is Windows Server 2008 64-bit running FileZilla Server (latest version). Alex Test script: --- $conn_id = ftp_connect($ftp_server); ftp_login($conn_id, $ftp_user, $ftp_pass); if (ftp_put($conn_id, Expected result: 1 Actual result: -- Warning: ftp_put(): Transfer OK 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=51190&edit=1
Req #50815 [Com]: Implement 323 short password hash fallback in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=50815&edit=1 ID: 50815 Comment by: Reported by: jd at cpanel dot net Summary: Implement 323 short password hash fallback in mysqlnd Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: any PHP Version: 5.3.1 Assigned To: mysql New Comment: I am running into this issue with mysqlnd as well; at my work we must keep old passwords on a few daemons to ensure backwards compatibility with proprietary software. MySQL's website (checking the 5.1 & 5.5 documentation) doesn't have the old password format deprecated in the newer versions, it's merely discouraged. While I agree that it is an insecure format and deprecating/removing support of it would be ideal, but it seems like support for this password scheme will exist in (major) future versions. Previous Comments: [2010-01-21 19:17:49] jd at cpanel dot net I'd agree with you there. They should be using the long hashes. The problem is when you have a system that's been in place for a very long time and the passwords haven't ever changed. The short hashes are still in the user table and the existing libmysqlclient happily connects with them. For some users this makes switching to mysqlnd a very difficult process. You need to force all of these old account to reenter their passwords so they can be rehashed. The main point is that if it's insecure to the point where it's worth breaking backward compatability, why do the latest versions of libmysqlclient continue to provide this functionality? The short hashes in the user table are the security problem, not the ability to send them from the client side, right? [2010-01-21 19:07:00] johan...@php.net The old hashing algorithm was insecure, which means passwords could be guessed with little effort. Additionally the last MySQL Server version which depended on this format is 4.0, which is out-of-support by MySQL (see http://www.mysql.com/about/legal/lifecycle/ ) since 2006 (extended support for customers ended 2008-09). Why do you need an insecure auth mechanism? [2010-01-21 18:57:50] jd at cpanel dot net Description: This is a wishlist item. We've found it impossible to use the mysqlnd driver for the PHP MySQL extension since it does not support the 323 style short password hash fallback that the normal libmysqlclient handles during authentication. This means that any mysql users that were added while short password hashes were in use have to change their passwords to long hashes before connecting is possible. Most likely, this is what bug 44082 was encountering. There are several other reports of this problem outside the PHP BTS. The only reference to this limitation I see in the official description of mysqlnd is "The MySQL native driver for PHP does not support the MySQL Server 4.0 or earlier." ( http://dev.mysql.com/downloads/connector/php-mysqlnd/ ) This is misleading since the 323 short password hashes work fine using libmysqlclient with MySQL 4.1+. -- Edit this bug report at http://bugs.php.net/bug.php?id=50815&edit=1
Bug #51167 [Com]: crypt() hangs randomly when called with a salt
Edit report at http://bugs.php.net/bug.php?id=51167&edit=1 ID: 51167 Comment by: Reported by: david dot joffe at tshwanedje dot com Summary: crypt() hangs randomly when called with a salt Status: Feedback Type: Bug Package: *Encryption and hash functions Operating System: Windows PHP Version: 5.3.1 New Comment: seems to be fixed in 5.3.2RC3 - will update if anything happens. Previous Comments: [2010-02-28 12:48:14] paj...@php.net Please try using PHP 5.3.2RC3. http://windows.php.net/qa/ [2010-02-27 15:24:34] david dot joffe at tshwanedje dot com Description: crypt($username, "x8"); // HANGS (Sometimes e.g. 1 out of every 3 times or so) crypt($username); // NO HANG Reproduce code: --- $username = 'foo'; crypt($username, "x8"); Actual result: -- Hangs -- Edit this bug report at http://bugs.php.net/bug.php?id=51167&edit=1
[PHP-BUG] Bug #51198 [NEW]: POSTing performs a GET with option CURLOPT_NOBODY=0
From:
Operating system: Linux (ubuntu 9.10 FRA)
PHP version: 5.2.13
Package: cURL related
Bug Type: Bug
Bug description:POSTing performs a GET with option CURLOPT_NOBODY=0
Description:
POSTing performs a GET. Seems to be related to option CURLOPT_NOBODY=0 as
used in twitter's PHP clients like PHP_Twitter.
Removing this option corrects the issue. I'm not sure this is a bug, but I
think this still is an issue that needs (at least) to be documented.
Test script:
---
$headers=array('Expect:', 'X-Twitter-Client: ','X-Twitter-Client-Version:
','X-Twitter-Client-URL: ');
$ch = curl_init();
curl_setopt($ch,CURLOPT_URL,"http://twitter.com/statuses/update.json";);
curl_setopt ($ch, CURLOPT_POST, true);
//curl_setopt ($ch, CURLOPT_HTTPGET, false); - Does not affect behaviour
curl_setopt ($ch, CURLOPT_POSTFIELDS, array('status'=>'hello world');
curl_setopt($ch, CURLOPT_USERPWD, 'twitter_user:twitter_pass');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_NOBODY, 0);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION,1);
curl_setopt($ch, CURLINFO_HEADER_OUT,true);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
$response = curl_exec($ch);
$t=curl_getinfo($ch);
curl_close($ch);
echo $t;
Expected result:
HTTP/1.1 200 OK Date: Wed, 03 Mar 2010 16:10:15 GMT Server: hi Status: 200
OK X-Transaction: ... ETag: "..." Last-Modified: Wed, 03 Mar 2010 16:10:15
GMT X-Runtime: 0.08590 Content-Type: application/json; charset=utf-8
Content-Length: 1113 Pragma: no-cache X-Revision: DEV Expires: Tue, 31 Mar
1981 05:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate,
pre-check=0, post-check=0 Set-Cookie: guest_id= ... ; path=/ Set-Cookie:
lang=fr; path=/ Set-Cookie: _twitter_sess= ... ; domain=.twitter.com;
path=/ Vary: Accept-Encoding Connection: close
(HTTP response Body) ...
Actual result:
--
HTTP/1.1 400 Bad Request Date: Wed, 03 Mar 2010 15:57:37 GMT Server: hi
Status: 400 Bad Request X-Transaction: ... X-RateLimit-Limit: 150
Last-Modified: Wed, 03 Mar 2010 15:57:37 GMT X-RateLimit-Remaining: 149
X-Runtime: 0.10008 Content-Type: application/json; charset=utf-8
Content-Length: 82 Pragma: no-cache X-RateLimit-Class: api X-Revision: DEV
Expires: Tue, 31 Mar 1981 05:00:00 GMT Cache-Control: no-cache, no-store,
must-revalidate, pre-check=0, post-check=0 X-RateLimit-Reset: 1267635457
Set-Cookie: guest_id= ... ; path=/ Set-Cookie: lang=fr; path=/ Set-Cookie:
_twitter_sess= ... ; domain=.twitter.com; path=/ Vary: Accept-Encoding
Connection: close {"request":"/statuses/update.json","error":"Cette
m\u00e9thode requiert un POST."}
--
Edit bug report at http://bugs.php.net/bug.php?id=51198&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51198&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51198&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51198&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51198&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51198&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51198&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51198&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51198&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51198&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51198&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51198&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51198&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51198&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51198&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51198&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51198&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51198&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51198&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51198&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51198&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51198&r=mysqlcfg
Bug #51167 [Fbk->Csd]: crypt() hangs randomly when called with a salt
Edit report at http://bugs.php.net/bug.php?id=51167&edit=1 ID: 51167 Updated by: paj...@php.net Reported by: david dot joffe at tshwanedje dot com Summary: crypt() hangs randomly when called with a salt -Status: Feedback +Status: Closed Type: Bug Package: *Encryption and hash functions Operating System: Windows PHP Version: 5.3.1 Assigned To: pajoye New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-03-03 17:38:53] paj...@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. [2010-03-03 17:06:12] klaus at hax dot at seems to be fixed in 5.3.2RC3 - will update if anything happens. [2010-02-28 12:48:14] paj...@php.net Please try using PHP 5.3.2RC3. http://windows.php.net/qa/ [2010-02-27 15:24:34] david dot joffe at tshwanedje dot com Description: crypt($username, "x8"); // HANGS (Sometimes e.g. 1 out of every 3 times or so) crypt($username); // NO HANG Reproduce code: --- $username = 'foo'; crypt($username, "x8"); Actual result: -- Hangs -- Edit this bug report at http://bugs.php.net/bug.php?id=51167&edit=1
Bug #51167 [Csd]: crypt() hangs randomly when called with a salt
Edit report at http://bugs.php.net/bug.php?id=51167&edit=1 ID: 51167 Updated by: paj...@php.net Reported by: david dot joffe at tshwanedje dot com Summary: crypt() hangs randomly when called with a salt Status: Closed Type: Bug Package: *Encryption and hash functions Operating System: Windows PHP Version: 5.3.1 Assigned To: pajoye New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-03-03 17:38:53] paj...@php.net -Status: Feedback +Status: Closed [2010-03-03 17:38:53] paj...@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. [2010-03-03 17:06:12] klaus at hax dot at seems to be fixed in 5.3.2RC3 - will update if anything happens. [2010-02-28 12:48:14] paj...@php.net Please try using PHP 5.3.2RC3. http://windows.php.net/qa/ [2010-02-27 15:24:34] david dot joffe at tshwanedje dot com Description: crypt($username, "x8"); // HANGS (Sometimes e.g. 1 out of every 3 times or so) crypt($username); // NO HANG Reproduce code: --- $username = 'foo'; crypt($username, "x8"); Actual result: -- Hangs -- Edit this bug report at http://bugs.php.net/bug.php?id=51167&edit=1
Bug #51115 [Fbk->Bgs]: session_start() IE8 slow
Edit report at http://bugs.php.net/bug.php?id=51115&edit=1 ID: 51115 Updated by: j...@php.net Reported by: m dot keckeis at solarys dot com Summary: session_start() IE8 slow -Status: Feedback +Status: Bogus Type: Bug Package: Session related Operating System: Debian Linux PHP Version: 5.2.12 New Comment: IE8 bugs are not PHP bugs. Previous Comments: [2010-03-03 18:27:47] j...@php.net IE8 bugs are not PHP bugs. [2010-02-23 07:20:17] m dot keckeis at solarys dot com Yes, every other browser is fast! Nearly the same problem here: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/b171c33a-53e2-4174-a876-554fe0729208 The problem with the domain i tried to "solve" with setting the session cookie again with the setcookie() function and then it worked. As u can see in my post: http://social.msdn.microsoft.com/Forums/en/iewebdevelopment/thread/8263235f-4992-46d3-9d01-5a3566bd7119 I set the domain normally to both cookies, but the parameter in the sessioncookie get ignored. This is one problem. The second thing is: session_start() needs long, but why? The cookie parameter gets send to the server with every GET request (which is normal) so why PHP needs so long for getting the cookie parameter? I tried now every possibility out which u can do with sessions and cookie handling, but the only solution to get it fast is currently save it in the URL via GET. As soon as you use cookie for session -> session_start() needs long. For "normal" cookies the time is okay. F.x. i use a cookie for language and this don't need "extra" time [2010-02-22 17:25:08] sni...@php.net And with any other browser it's not slow? [2010-02-22 16:10:50] m dot keckeis at solarys dot com Description: session_start() in combination with IE8: When i get the SID over GET it's normal (fast). But when the SID come from a cookie it's slow. This method needs 0,5s to get done with Cookie handling from IE8. I don't know if it's an IE8 problem or a PHP problem, but it's very annoying. When i checked the cookie information which is saved, there only stands ".net" instead of the whole domain. More information are here available: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/b171c33a-53e2-4174-a876-554fe0729208 -- Edit this bug report at http://bugs.php.net/bug.php?id=51115&edit=1
Bug #51131 [Fbk->NoF]: ocifetchinto is not working
Edit report at http://bugs.php.net/bug.php?id=51131&edit=1 ID: 51131 Updated by: php-bugs@lists.php.net Reported by: ganesh dot rpr at gmail dot com Summary: ocifetchinto is not working -Status: Feedback +Status: No Feedback Type: Bug Package: OCI8 related Operating System: linux PHP Version: 5.3.1 Assigned To: sixd New Comment: 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". Previous Comments: [2010-02-24 08:24:21] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-02-24 08:19:05] ganesh dot rpr at gmail dot com ocifetchinto is not working, when using order by desc or asc in linux but work with windows [2010-02-24 08:17:37] ganesh dot rpr at gmail dot com Description: ocifetchinto is not working, when using order by desc or asc Reproduce code: --- ocifetchinto is not working, when using order by desc/asc Expected result: working / solution Actual result: -- 6 -- Edit this bug report at http://bugs.php.net/bug.php?id=51131&edit=1
Bug #51108 [Fbk->NoF]: Remainder operator (%) FAILS with two specific numbers
Edit report at http://bugs.php.net/bug.php?id=51108&edit=1
ID: 51108
Updated by: php-bugs@lists.php.net
Reported by: nonsqtr at hotmail dot com
Summary: Remainder operator (%) FAILS with two specific numbers
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Math related
Operating System: Linux 2.6.18-164.6.1.el5 #1 SMP
PHP Version: 5.2.12
New Comment:
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".
Previous Comments:
[2010-02-22 10:25:30] j...@php.net
Where's the real reproducing script? So far your examples are fail at
best..
[2010-02-22 03:04:20] nonsqtr at hotmail dot com
It gets even more interesting. The value passed into a function is
incorrect too.
So for instance, here's some test code:
$val = 3330;
$rc = foo($val);
function foo($amount)
{
if($amount == 3330 OR $amount == "3330")
{
// this line of code is never reached
// and it doesn't matter if you typecast $amount in the test
}
else if($amount > 3329 AND $amount < 3331)
{
// this line of code is reached
}
// ...
}
Again, this only happens with the two specific number 3330 and 6660, as
near as I can tell and according to my testing so far.
[2010-02-22 02:08:17] nonsqtr at hotmail dot com
Description:
This line of code
$tag = $amount % 100
gives an incorrect result when "amount" is set to one of two specific
numbers: 3330 and 6660
Any other number seems to work fine - for example, 60, 660, 0,
60, work fine. Only 6660 fails, it gives the incorrect result
59.
And, 3330 gives the incorrect result 29.
It doesn't matter if you typecast amount before calculating.
And it doesn't matter if it's a string or an int being passed in, the
result is still 29 or 59.
I ran a whole series of numbers against this, and 3330 and 6660 are the
only ones that fail (at least, that I found).
I'm on a hosted system, so I can't tell you how PHP was compiled. But
I've reproduced this on three hosted systems so far, with different PHP
versions, going all the way back to 5.2.5, so it looks like it's just a
hidden bug that's been lurking around for a while.
Once again, casting does not resolve this problem, and using the round()
function doesn't resolve it either. The operator % is what's failing
here.
Reproduce code:
---
---
>From manual page: http://www.php.net/function.round#Description
---
$tag = $amount % 100
When $amount is an int, a string, or a float
Expected result:
When $amount is set to 6660, I expect to see a 60 come back
Actual result:
--
I get a 59 instead of a 60
--
Edit this bug report at http://bugs.php.net/bug.php?id=51108&edit=1
Bug #50962 [Fbk->NoF]: Using a ftp stream to a windows ftp server to upload results in missing data
Edit report at http://bugs.php.net/bug.php?id=50962&edit=1
ID: 50962
Updated by: php-bugs@lists.php.net
Reported by: m dot ebbers at i-real dot nl
Summary: Using a ftp stream to a windows ftp server to upload
results in missing data
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.*, 6 (2010-02-23)
New Comment:
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".
Previous Comments:
[2010-02-23 13:08:45] j...@php.net
When you give feedback, use the correct tab (NOT the "Add Comment"
one!). And does this happen with any ftp server not under Windows? Any
firewalls or such between? Have you tried the PHP FTP extension instead?
(See more at: http://php.net/ftp )
[2010-02-23 08:10:24] m dot ebbers at i-real dot nl
I've tested it with the given snapshot:
PHP 5.3.3-dev (cli) (built: Feb 23 2010 08:21:46)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
With the same results. Files are not always complete. :(
[2010-02-13 21:49:40] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-02-08 09:29:16] m dot ebbers at i-real dot nl
Description:
When fopen/fwrite are used to upload a file, through ftp to a ftp server
running on windows, it is not always uploaded completely despite the
fact that fwrite returns that all bytes of the file are written.
I've testen the following scenarios with the attached code:
>From Ubuntu 9.10 to Bulletproof ftpd under windows xp (vmware).
(failed)
>From Ubuntu 9.10 to Serv-u ftpd under windows xp (vmware). (failed)
>From Ubuntu 9.10 to vsftpd on same machine. (ok)
Different hardware and network:
>From CentOS release 5 to Bulletproof ftpd on windows server (failed)
When using the ftp command it all works great.
Also tried the build-in ftp client from php and that works fine. It only
failed when using fopen/fwrite/file_put_contents.
Reproduce code:
---
$host = '192.168.1.34';
$user = 'marke';
$passwd = 'ebbers';
$path = '/';
$file = $argv[1];
$url='ftp://'.$user.':'.$passwd.'@'.$host.$path.$file;
$content = file_get_contents($file);
$handle = fopen($url, 'w');
$written = 0;
while ($written != strlen($content))
{
$write = fwrite($handle, substr($content, $written));
fflush($handle);
if($write){
$written .= $write;
echo "Written: ".$written.'\n';
}else{
break;
}
}
Expected result:
Output script: Written: 293346 (Test file is 293346 bytes.)
And a file on the ftp server of the same size.
Actual result:
--
Output script: Written: 293346 (Test file is 293346 bytes.)
A file on the server, but it is smaller. (and the sizes varies)
I've also a wireshark sniff available. The strange thing in the sniff is
that the every byte of the file is actually send, but by an unknown
reason there is tcp resend and the data in that resend is also the last
data in the file on the server.
Strace:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=6499, groups=}, [12])
= 0
sendto(3, "\24\0\0\0\26\0\1\3\220\321oK\0\0\0\0\0\0\0\0", 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{"0\0\0\0\24\0\2\0\220\321oKc\31\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 228
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{"@\0\0\0\24\0\2\0\220\321oKc\31\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 256
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{"\24\0\0\0\3\0\2\0\220\321oKc\31\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(21),
sin_addr=inet_addr("192.168.1.34")}, 16) = -1 EINPROGRESS (Operation now
in progress)
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
recv(3, "220 Serv-U FTP
[PHP-BUG] Bug #51199 [NEW]: pecl install dtrace fails
From: Operating system: opensolaris PHP version: 5.3.1 Package: Compile Failure Bug Type: Bug Bug description:pecl install dtrace fails Description: pecl install dtrace fails (release 1.0.3); also latest version from svn (1.0.4) svn.php.net dtrace script compile fails in Makefile fragment with output if test -f ./.libs/dtrace.o ; then \ dtrace -G -s /export/home/kim/Downloads/dtrace/dtrace-1.0.4/php.d ./.libs/dtrace.o ; \ else \ dtrace -G -s /export/home/kim/Downloads/dtrace/dtrace-1.0.4/php.d dtrace.lo ; \ fi dtrace: failed to compile script /export/home/kim/Downloads/dtrace/dtrace-1.0.4/php.d: "/usr/lib/dtrace/mpi.d", line 70: failed to resolve type genunix`kthread_t * for identifier curthread: Module and program data models do not match -- Edit bug report at http://bugs.php.net/bug.php?id=51199&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51199&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51199&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51199&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51199&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51199&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51199&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51199&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51199&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51199&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51199&r=support Expected behavior: http://bugs.php.net/fix.php?id=51199&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51199&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51199&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51199&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51199&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51199&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51199&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51199&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51199&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51199&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51199&r=mysqlcfg
Bug #51199 [Opn->Bgs]: pecl install dtrace fails
Edit report at http://bugs.php.net/bug.php?id=51199&edit=1 ID: 51199 Updated by: paj...@php.net Reported by: kwoodle at aya dot yale dot edu Summary: pecl install dtrace fails -Status: Open +Status: Bogus Type: Bug Package: Compile Failure Operating System: opensolaris PHP Version: 5.3.1 New Comment: Please report pecl's dtrace bug to pecl.php.net Previous Comments: [2010-03-03 19:04:12] paj...@php.net Please report pecl's dtrace bug to pecl.php.net [2010-03-03 18:47:30] kwoodle at aya dot yale dot edu Description: pecl install dtrace fails (release 1.0.3); also latest version from svn (1.0.4) svn.php.net dtrace script compile fails in Makefile fragment with output if test -f ./.libs/dtrace.o ; then \ dtrace -G -s /export/home/kim/Downloads/dtrace/dtrace-1.0.4/php.d ./.libs/dtrace.o ; \ else \ dtrace -G -s /export/home/kim/Downloads/dtrace/dtrace-1.0.4/php.d dtrace.lo ; \ fi dtrace: failed to compile script /export/home/kim/Downloads/dtrace/dtrace-1.0.4/php.d: "/usr/lib/dtrace/mpi.d", line 70: failed to resolve type genunix`kthread_t * for identifier curthread: Module and program data models do not match -- Edit this bug report at http://bugs.php.net/bug.php?id=51199&edit=1
Bug #46853 [Opn]: Compile failure using --with-ODBCRouter
Edit report at http://bugs.php.net/bug.php?id=46853&edit=1 ID: 46853 User updated by: bas at web4friends dot com Reported by: bas at web4friends dot com Summary: Compile failure using --with-ODBCRouter Status: Open Type: Bug Package: ODBC related Operating System: Linux -PHP Version: 5.2.10 +PHP Version: 5.2.13 New Comment: Bug is stil existing in 5.2.13 Previous Comments: [2009-11-18 10:06:23] mathieu dot bruere at gmail dot com I've got the same problem while compiling PHP with Adabas. Worked fine till 5.2.6. [2009-06-19 15:52:27] bas at web4friends dot com Bug is stil existing in 5.2.10 and 5.3RC builds [2009-03-05 13:12:28] j...@php.net Moved back to ODBC related where this belongs. [2008-12-12 18:45:32] bas at web4friends dot com Description: Building php 5.2.8 with ODBCRouter support fails. Builds fine till PHP 5.2.6. Reproduce code: --- ./configure --with-apxs2=/usr/local/apache22/bin/apxs --with-ODBCRouter Actual result: -- In file included from /temp/php-5.2.8/ext/odbc/php_odbc.c:37: /temp/php-5.2.8/ext/odbc/php_odbc_includes.h:237: error: expected specifier-qualifier-list before 'SQLLEN' /temp/php-5.2.8/ext/odbc/php_odbc.c: In function 'safe_odbc_disconnect': /temp/php-5.2.8/ext/odbc/php_odbc.c:203: warning: passing argument 1 of 'SQLDisconnect' makes integer from pointer without a cast /temp/php-5.2.8/ext/odbc/php_odbc.c:206: warning: passing argument 1 of 'SQLTransact' makes integer from pointer without a cast /temp/php-5.2.8/ext/odbc/php_odbc.c:206: warning: passing argument 2 of 'SQLTransact' makes integer from pointer without a cast /temp/php-5.2.8/ext/odbc/php_odbc.c:207: warning: passing argument 1 of 'SQLDisconnect' makes integer from pointer without a cast /temp/php-5.2.8/ext/odbc/php_odbc.c: In function '_close_odbc_conn': /temp/php-5.2.8/ext/odbc/php_odbc.c:233: warning: passing argument 1 of 'safe_odbc_disconnect' makes pointer from integer without a cast /temp/php-5.2.8/ext/odbc/php_odbc.c: In function '_close_odbc_pconn': /temp/php-5.2.8/ext/odbc/php_odbc.c:261: warning: passing argument 1 of 'safe_odbc_disconnect' makes pointer from integer without a cast /temp/php-5.2.8/ext/odbc/php_odbc.c: In function 'odbc_bindcols': /temp/php-5.2.8/ext/odbc/php_odbc.c:691: error: 'SQLLEN' undeclared (first use in this function) /temp/php-5.2.8/ext/odbc/php_odbc.c:691: error: (Each undeclared identifier is reported only once /temp/php-5.2.8/ext/odbc/php_odbc.c:691: error: for each function it appears in.) /temp/php-5.2.8/ext/odbc/php_odbc.c:691: error: expected ';' before 'displaysize' /temp/php-5.2.8/ext/odbc/php_odbc.c:702: error: 'odbc_result_value' has no member named 'coltype' /temp/php-5.2.8/ext/odbc/php_odbc.c:708: error: 'odbc_result_value' has no member named 'coltype' /temp/php-5.2.8/ext/odbc/php_odbc.c:725: error: 'displaysize' undeclared (first use in this function) /temp/php-5.2.8/ext/odbc/php_odbc.c:730: error: 'odbc_result_value' has no member named 'vallen' /temp/php-5.2.8/ext/odbc/php_odbc.c: In function 'odbc_column_lengths': /temp/php-5.2.8/ext/odbc/php_odbc.c:785: error: 'SQLLEN' undeclared (first use in this function) /temp/php-5.2.8/ext/odbc/php_odbc.c:785: error: expected ';' before 'len' /temp/php-5.2.8/ext/odbc/php_odbc.c:814: error: 'len' undeclared (first use in this function) /temp/php-5.2.8/ext/odbc/php_odbc.c: In function 'zif_odbc_execute': /temp/php-5.2.8/ext/odbc/php_odbc.c:981: error: expected specifier-qualifier-list before 'SQLLEN' /temp/php-5.2.8/ext/odbc/php_odbc.c:989: error: 'SQLULEN' undeclared (first use in this function) /temp/php-5.2.8/ext/odbc/php_odbc.c:989: error: expected ';' before 'precision' /temp/php-5.2.8/ext/odbc/php_odbc.c:1046: error: 'precision' undeclared (first use in this function) /temp/php-5.2.8/ext/odbc/php_odbc.c:1048: error: 'params_t' has no member named 'vallen' /temp/php-5.2.8/ext/odbc/php_odbc.c:1049: error: 'params_t' has no member named 'fp' /temp/php-5.2.8/ext/odbc/php_odbc.c:1076: error: 'params_t' has no member named 'fp' /temp/php-5.2.8/ext/odbc/php_odbc.c:1080: error: 'params_t' has no member named 'fp' /temp/php-5.2.8/ext/odbc/php_odbc.c:1081: error: 'params_t' has no member named 'fp' /temp/php-5.2.8/ext/odbc/php_odbc.c:1091: error: 'params_t' has no member named 'vallen' /temp/php-5.2.8/ext/odbc/php_odbc.c:1095: error: 'params_t' has no member named 'fp' /temp/php-5.2.8/ext/odbc/php_odbc.c:1096: error: 'params_t' has no member named 'vallen' /temp/php-5.2.8/ext/odbc/php_odbc.c:1102: error: 'params_t' has no member named 'vallen' /temp/php-5.2.8/ext/odbc/php_odbc.c:1
