Bug #51185 [Opn->Fbk]: 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 Updated by: paj...@php.net Reported by: randy at thehiringsurvey dot com Summary: Apache won't start after PHP 5.3.1 is installed -Status: Open +Status: Feedback Type: Bug Package: Windows Installer Operating System: Windows 7 (x64) PHP Version: 5.3.1 New Comment: Which extension(s) are enabled in the php.ini? It could be due to some extensions requiring external DLLs (oracle for example) or the PHP directory not being in your PATH. Try to call php from the command line as well, with or without using the system php.ini (be sure that you have removed or updated the 5.2's php.ini, especially the extension_dir setting). php.exe -n -i no php.ini loaded php.exe -i with system php.ini Previous Comments: [2010-03-04 11:29:02] paj...@php.net Which extension(s) are enabled in the php.ini? It could be due to some extensions requiring external DLLs (oracle for example) or the PHP directory not being in your PATH. Try to call php from the command line as well, with or without using the system php.ini (be sure that you have removed or updated the 5.2's php.ini, especially the extension_dir setting). php.exe -n -i no php.ini loaded php.exe -i with system php.ini [2010-03-03 09:26:48] c dot fior at bss-gt dot com I had the same problem with OE Windows Server 2003 ... I had to downgrade to previous release [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
Bug #51176 [Csd]: Static calling in non-static method behaves like $this->
Edit report at http://bugs.php.net/bug.php?id=51176&edit=1
ID: 51176
User updated by: majkl578 at gmail dot com
Reported by: majkl578 at gmail dot com
Summary: Static calling in non-static method behaves like
$this->
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Irrelevant
PHP Version: 5.3.2RC3
Assigned To: felipe
New Comment:
Can you explain me, please, why this is not fixed in 5.3.2 stable?
"Thank you for the report, and for helping us make PHP better."
You are intentionally making PHP worse!
Previous Comments:
[2010-03-02 13:37:35] majkl578 at gmail dot com
Will you backport this bugfix to PHP 5.3.2 branch?
Otherwise the behavior will be really odd due to presence of this bug.
[2010-03-02 01:17:06] fel...@php.net
-Status: Open
+Status: Closed
[2010-03-02 01:17:06] fel...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-03-01 16:53:03] majkl578 at gmail dot com
Description:
When calling non-existing static method from non-static method, __call()
is called instead of __callStatic().
self/static/className behaves incorrectly - like $this-> in that
context.
Verified on 5.3.2RC3, 5.3.1 and 5.3.0.
Reproduce code:
---
class Foo
{
public function start()
{
self::bar();
static::bar();
Foo::bar();
}
public function __call($n, $a)
{
echo 'instance';
}
public static function __callStatic($n, $a)
{
echo 'static';
}
}
$foo = new Foo();
$foo->start();
Expected result:
static
static
static
Actual result:
--
instance
instance
instance
--
Edit this bug report at http://bugs.php.net/bug.php?id=51176&edit=1
Req #50871 [Opn]: [PATCH] SPL: default value of spl_autoload_extensions() configurable in php.ini
Edit report at http://bugs.php.net/bug.php?id=50871&edit=1 ID: 50871 Updated by: ka...@php.net Reported by: julesvanvelzen at gmail dot com -Summary: SPL: default value of spl_autoload_extensions() configurable in php.ini +Summary: [PATCH] SPL: default value of spl_autoload_extensions() configurable in php.ini Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: any PHP Version: 5.3.1 New Comment: I added a patch that adds a new ini directive called spl.autoload_extensions to populate spl_autoload_extensions() from php.ini Previous Comments: [2010-03-04 13:39:00] ka...@php.net I added a patch that adds a new ini directive called spl.autoload_extensions to populate spl_autoload_extensions() from php.ini [2010-01-28 08:27:44] julesvanvelzen at gmail dot com Description: I expected the default value, which is now '.inc,.php', of spl_autoload_extensions() to be configurable in php.ini, just like the include_path. -- Edit this bug report at http://bugs.php.net/bug.php?id=50871&edit=1
Bug #51198 [Opn->Bgs]: POSTing performs a GET with option CURLOPT_NOBODY=0
Edit report at http://bugs.php.net/bug.php?id=51198&edit=1
ID: 51198
Updated by: il...@php.net
Reported by: philippe dot gablain at gmail dot com
Summary: POSTing performs a GET with option CURLOPT_NOBODY=0
-Status: Open
+Status: Bogus
Type: Bug
Package: cURL related
Operating System: Linux (ubuntu 9.10 FRA)
PHP Version: 5.2.13
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You cannot do a POST without a body.
Previous Comments:
[2010-03-04 13:48:25] il...@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
You cannot do a POST without a body.
[2010-03-03 17:14:14] philippe dot gablain at gmail dot com
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 this bug report at http://bugs.php.net/bug.php?id=51198&edit=1
Bug #51190 [Opn->Csd]: ftp_put() returns false when transfer was successful
Edit report at http://bugs.php.net/bug.php?id=51190&edit=1 ID: 51190 Updated by: il...@php.net Reported by: alexclifford47 at gmail dot com Summary: ftp_put() returns false when transfer was successful -Status: Open +Status: Closed Type: Bug Package: FTP related Operating System: Windows Server 2003 R2 32-bit PHP Version: 5.3.1 Assigned To: iliaa 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-04 13:53:12] il...@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-04 13:52:59] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=295820 Log: Fixed bug #51190 (ftp_put() returns false when transfer was successful). [2010-03-03 15:55:56] araje at usimagingnetwork dot com I'm having the exact same problem.. The upload is successful , however ftp_put returns false... Any info would be appreciated. Thanks Ameya [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
Bug #51198 [Bgs]: POSTing performs a GET with option CURLOPT_NOBODY=0
Edit report at http://bugs.php.net/bug.php?id=51198&edit=1
ID: 51198
User updated by: philippe dot gablain at gmail dot com
Reported by: philippe dot gablain at gmail dot com
Summary: POSTing performs a GET with option CURLOPT_NOBODY=0
Status: Bogus
Type: Bug
Package: cURL related
Operating System: Linux (ubuntu 9.10 FRA)
PHP Version: 5.2.13
New Comment:
Hello,
You're right, a POST without a body is not a POST.
But in my example CURLOPT_NOBODY is set to FALSE. I don't know why
PHP-Twitter API set this parameter to false (a simple turnarround is
just to not set the option), but setting "NO NOBODY=YES BODY" should not
modify the POST into GET, no ?
Documentation actually says "CURLOPT_NOBODY TRUE to exclude the body
from the output. Request method is then set to HEAD. Changing this to
FALSE does not change it to GET."
Previous Comments:
[2010-03-04 13:48:25] il...@php.net
-Status: Open
+Status: Bogus
[2010-03-04 13:48:25] il...@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
You cannot do a POST without a body.
[2010-03-03 17:14:14] philippe dot gablain at gmail dot com
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 this bug report at http://bugs.php.net/bug.php?id=51198&edit=1
Bug #51198 [Bgs->Tbd]: POSTing performs a GET with option CURLOPT_NOBODY=0
Edit report at http://bugs.php.net/bug.php?id=51198&edit=1
ID: 51198
Updated by: paj...@php.net
Reported by: philippe dot gablain at gmail dot com
Summary: POSTing performs a GET with option CURLOPT_NOBODY=0
-Status: Bogus
+Status: To be documented
Type: Bug
Package: cURL related
Operating System: Linux (ubuntu 9.10 FRA)
PHP Version: 5.2.13
New Comment:
Can someone from the doc team verify that the doc is clear enough about
this behavior? Thanks :)
Previous Comments:
[2010-03-04 14:21:30] paj...@php.net
Can someone from the doc team verify that the doc is clear enough about
this behavior? Thanks :)
[2010-03-04 14:18:19] philippe dot gablain at gmail dot com
Hello,
You're right, a POST without a body is not a POST.
But in my example CURLOPT_NOBODY is set to FALSE. I don't know why
PHP-Twitter API set this parameter to false (a simple turnarround is
just to not set the option), but setting "NO NOBODY=YES BODY" should not
modify the POST into GET, no ?
Documentation actually says "CURLOPT_NOBODY TRUE to exclude the body
from the output. Request method is then set to HEAD. Changing this to
FALSE does not change it to GET."
[2010-03-04 13:48:25] il...@php.net
-Status: Open
+Status: Bogus
[2010-03-04 13:48:25] il...@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
You cannot do a POST without a body.
[2010-03-03 17:14:14] philippe dot gablain at gmail dot com
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 this bug report at http://bugs.php.net/bug.php?id=51198&edit=1
Bug #51155 [Com]: serialize() crashes with unreasonable/unexplicable "out of memory" for objects
Edit report at http://bugs.php.net/bug.php?id=51155&edit=1 ID: 51155 Comment by: Reported by: flavius dot as at gmail dot com Summary: serialize() crashes with unreasonable/unexplicable "out of memory" for objects Status: Feedback Type: Bug Package: SPL related Operating System: ArchLinux x86_64 PHP Version: 5.3.1 New Comment: Using it gives the configure error: configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. Previous Comments: [2010-03-01 17:02:22] 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-26 13:41:59] flavius dot as at gmail dot com Oh and I've forgot to mention, there's plenty of RAM and swap space before running php -f: free -m total used free sharedbuffers cached Mem: 1975 1732243 0131 1027 -/+ buffers/cache:573 1402 Swap: 5718 0 5718 [2010-02-26 13:38:28] flavius dot as at gmail dot com Updated OS: ArchLinux x86_64 [2010-02-26 13:35:13] flavius dot as at gmail dot com Description: When serializing a SplFixedArray with serialize(), the script dies with "Fatal error: Allowed memory size of 134217728 bytes exhausted" The "expected result" works and allocates at most 20.96 mb for $cnt = 8565 on line 15. The "actual result" crashes when serialize()'ing with $cnt only incremented by one, which is not understandable. The actual values may vary, but if you play enough with it you'll find at which amount of items serialize() has that spark. Then you can toggle to using plain arrays on line 17, and that problem will disappear, although arrays actually consume more memory (in my experiments around 1.2 mb more). Reproduce code: --- 1 http://bugs.php.net/bug.php?id=51155&edit=1
Bug #51176 [Csd]: Static calling in non-static method behaves like $this->
Edit report at http://bugs.php.net/bug.php?id=51176&edit=1
ID: 51176
Updated by: fel...@php.net
Reported by: majkl578 at gmail dot com
Summary: Static calling in non-static method behaves like
$this->
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Irrelevant
PHP Version: 5.3.2RC3
Assigned To: felipe
New Comment:
Hello!
This isn't my decision, but the release manager.
Thanks.
Previous Comments:
[2010-03-04 12:33:59] majkl578 at gmail dot com
Can you explain me, please, why this is not fixed in 5.3.2 stable?
"Thank you for the report, and for helping us make PHP better."
You are intentionally making PHP worse!
[2010-03-02 13:37:35] majkl578 at gmail dot com
Will you backport this bugfix to PHP 5.3.2 branch?
Otherwise the behavior will be really odd due to presence of this bug.
[2010-03-02 01:17:06] fel...@php.net
-Status: Open
+Status: Closed
[2010-03-02 01:17:06] fel...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-03-01 16:53:03] majkl578 at gmail dot com
Description:
When calling non-existing static method from non-static method, __call()
is called instead of __callStatic().
self/static/className behaves incorrectly - like $this-> in that
context.
Verified on 5.3.2RC3, 5.3.1 and 5.3.0.
Reproduce code:
---
class Foo
{
public function start()
{
self::bar();
static::bar();
Foo::bar();
}
public function __call($n, $a)
{
echo 'instance';
}
public static function __callStatic($n, $a)
{
echo 'static';
}
}
$foo = new Foo();
$foo->start();
Expected result:
static
static
static
Actual result:
--
instance
instance
instance
--
Edit this bug report at http://bugs.php.net/bug.php?id=51176&edit=1
Bug #51155 [Fbk]: serialize() crashes with unreasonable/unexplicable "out of memory" for objects
Edit report at http://bugs.php.net/bug.php?id=51155&edit=1 ID: 51155 Updated by: paj...@php.net Reported by: flavius dot as at gmail dot com Summary: serialize() crashes with unreasonable/unexplicable "out of memory" for objects Status: Feedback Type: Bug Package: SPL related Operating System: ArchLinux x86_64 PHP Version: 5.3.1 New Comment: That's unrelated to this bug, disable imap to test a new build. However, about this error, get a decent c-client and it will work (like less than 4-5 years old). Previous Comments: [2010-03-04 14:26:28] flavius dot as at gmail dot com Using it gives the configure error: configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. [2010-03-01 17:02:22] 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-26 13:41:59] flavius dot as at gmail dot com Oh and I've forgot to mention, there's plenty of RAM and swap space before running php -f: free -m total used free sharedbuffers cached Mem: 1975 1732243 0131 1027 -/+ buffers/cache:573 1402 Swap: 5718 0 5718 [2010-02-26 13:38:28] flavius dot as at gmail dot com Updated OS: ArchLinux x86_64 [2010-02-26 13:35:13] flavius dot as at gmail dot com Description: When serializing a SplFixedArray with serialize(), the script dies with "Fatal error: Allowed memory size of 134217728 bytes exhausted" The "expected result" works and allocates at most 20.96 mb for $cnt = 8565 on line 15. The "actual result" crashes when serialize()'ing with $cnt only incremented by one, which is not understandable. The actual values may vary, but if you play enough with it you'll find at which amount of items serialize() has that spark. Then you can toggle to using plain arrays on line 17, and that problem will disappear, although arrays actually consume more memory (in my experiments around 1.2 mb more). Reproduce code: --- 1 http://bugs.php.net/bug.php?id=51155&edit=1
Bug #1 [Csd]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Updated 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: El commento duplicatos..? Previous Comments: [2010-03-03 11:14:26] j...@php.net testing "anonymous" commenting. :) [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 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 #1 [Csd->Bgs]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Updated by: j...@php.net Reported by: rasmus at lerdorf dot on dot ca Summary: Apache 1.3b3 + mod_php3 is slow -Status: Closed +Status: Bogus Type: Bug Package: Performance problem Operating System: Solaris 2.5.1 PHP Version: 3.0b3 Assigned To: jani New Comment: Testing duplication.. Previous Comments: [2010-03-04 14:41:30] j...@php.net El commento duplicatos..? [2010-03-03 11:14:26] j...@php.net testing "anonymous" commenting. :) [2010-03-01 20:44:58] j...@php.net test [2010-03-01 20:29:38] der...@php.net testing II [2010-03-01 20:20:57] der...@php.net testing. 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 #1 [Bgs->Csd]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Updated by: j...@php.net Reported by: rasmus at lerdorf dot on dot ca Summary: Apache 1.3b3 + mod_php3 is slow -Status: Bogus +Status: Closed Type: Bug Package: Performance problem Operating System: Solaris 2.5.1 PHP Version: 3.0b3 Assigned To: jani New Comment: One more time.. :) Previous Comments: [2010-03-04 14:56:36] j...@php.net Testing duplication.. [2010-03-04 14:41:30] j...@php.net El commento duplicatos..? [2010-03-03 11:14:26] j...@php.net testing "anonymous" commenting. :) [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 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 #51155 [Com]: serialize() crashes with unreasonable/unexplicable "out of memory" for objects
Edit report at http://bugs.php.net/bug.php?id=51155&edit=1 ID: 51155 Comment by: Reported by: flavius dot as at gmail dot com Summary: serialize() crashes with unreasonable/unexplicable "out of memory" for objects Status: Feedback Type: Bug Package: SPL related Operating System: ArchLinux x86_64 PHP Version: 5.3.1 New Comment: Ok, I've managed to compile and test with php5.3-201003041130, the bug is still there, but it seems to crash for higher values. for 2 items, the peak is peak 21.71 mb before serialize, peak 45.59 mb after serialize. simple maths: it should need approximatively 5 mb for every 5000 items. The following test run for 25000 confirms my theory (roughly, +/- due to temporarily saving the return value, runtime memory, etc): before serialization: peak 26.98 mb after: peak 56.7 mb Ok, it's slightly higher than 5mb, after serialization is a small increase over the expected (which I presumed) 2*n linear growth. Now the final run. But first and foremost $ sapi/cli/php -i |grep memory memory_limit => 128M => 128M And the test run, for 3 items: GENERATING DONE peak 32.24 mb --- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 28574231 bytes) The expected value was somewhere around (and I'll be generous) 80mb. But I suppose it still has that spark of exponential growth somewhere between 25000 and 3 items. Previous Comments: [2010-03-04 14:30:17] paj...@php.net That's unrelated to this bug, disable imap to test a new build. However, about this error, get a decent c-client and it will work (like less than 4-5 years old). [2010-03-04 14:26:28] flavius dot as at gmail dot com Using it gives the configure error: configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. [2010-03-01 17:02:22] 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-26 13:41:59] flavius dot as at gmail dot com Oh and I've forgot to mention, there's plenty of RAM and swap space before running php -f: free -m total used free sharedbuffers cached Mem: 1975 1732243 0131 1027 -/+ buffers/cache:573 1402 Swap: 5718 0 5718 [2010-02-26 13:38:28] flavius dot as at gmail dot com Updated OS: ArchLinux x86_64 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=51155 -- Edit this bug report at http://bugs.php.net/bug.php?id=51155&edit=1
[PHP-BUG] Req #51202 [NEW]: use oci8 result with smarty
From:
Operating system: Win
PHP version: 5.3.1
Package: OCI8 related
Bug Type: Feature/Change Request
Bug description:use oci8 result with smarty
Description:
Hi
I use oci8 php file to connect with oracle db like this:
then, I use smarty file to display data
I would like to use smarty file to display array data
i got only one record with foreach statment (my table contains many
records)
Test script:
---
in php file:
$conn = oci_connect('username', 'passwd', ip-server/My_db');
$query = 'select * from my_table';
$stid = oci_parse($conn, $query);
oci_execute($stid, OCI_DEFAULT);
$row = oci_fetch_array($stid, OCI_ASSOC);
in smarty file:
{foreach from=$row item=soso}
{foreach from=$soso item=fofo}
{$fofo}
{/foreach}
{/foreach}
Actual result:
--
10359 4 1 14-JAN-10 119 2010 5
--
Edit bug report at http://bugs.php.net/bug.php?id=51202&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51202&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51202&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51202&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51202&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51202&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51202&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51202&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51202&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51202&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51202&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51202&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51202&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51202&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51202&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51202&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51202&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51202&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51202&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51202&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51202&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51202&r=mysqlcfg
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: Feedback Type: Bug Package: Windows Installer Operating System: Windows 7 (x64) PHP Version: 5.3.1 New Comment: pajoye asked me which extensions were enabled. I'm sorry but because I have uninstalled 5.3.1 and installed 5.2.13 I can no longer say for certain. I do not have a copy of the php.ini from the 5.3.1 installation. I checked my trash, and it's gone. When I installed 5.3.1 I did go through the custom setup and to select extensions. There were a few extensions that I knew I needed. I think that they (PEAR and MySQL) were both selected by default, so I just took the defaults. Previous Comments: [2010-03-04 11:29:02] paj...@php.net Which extension(s) are enabled in the php.ini? It could be due to some extensions requiring external DLLs (oracle for example) or the PHP directory not being in your PATH. Try to call php from the command line as well, with or without using the system php.ini (be sure that you have removed or updated the 5.2's php.ini, especially the extension_dir setting). php.exe -n -i no php.ini loaded php.exe -i with system php.ini [2010-03-03 09:26:48] c dot fior at bss-gt dot com I had the same problem with OE Windows Server 2003 ... I had to downgrade to previous release [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 #51203 [NEW]: PDO prepared statements, execute returns false on second call without parameter
From:
Operating system: Debian
PHP version: 5.3.1
Package: MySQL related
Bug Type: Bug
Bug description:PDO prepared statements, execute returns false on second call
without parameter
Description:
$sth->execute() returns false on second run but fetchColumn still returns a
value.
Test script:
---
$db = new PDO('mysql:dbname=;unix_socket=/tmp/mysql.sock;','',
'');
$sth2 = $db->prepare("SELECT id FROM users ORDER BY RAND()");
$sth2->execute();
$ret=$sth2->fetchColumn();
echo $ret."\n";
$fail=$sth2->execute();
$ret=$sth2->fetchColumn();
var_dump($fail, $ret);
$sth = $db->prepare("SELECT 1 FROM users where active=?");
if ($sth->execute(array(1))) {
$ret=$sth->fetch();
echo "1\n";
} else die("poo pdo\n");
if ($sth->execute(array(1))) {
$ret=$sth->fetch();
echo "2\n";
} else die(var_export($db->errorInfo(), true));
$sth1 = $db->prepare("SELECT 1 FROM users where active=1");
if ($sth1->execute()) {
$ret=$sth1->fetch();
echo "1\n";
} else die("poo pdo\n");
if ($sth1->execute()) {
$ret=$sth1->fetch();
echo "2\n";
} else die(var_export($db->errorInfo(), true));
die;
Expected result:
1033
bool(true)
string(4) "1142"
1
2
1
2
Actual result:
--
1033
bool(false)
string(4) "1142"
1
2
1
array (
0 => '0',
1 => NULL,
2 => NULL,
)
Relevant strace :
lose(4)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(4, {sa_family=AF_FILE, path="/tmp/mysql.sock"...}, 17) = 0
fcntl64(4, F_SETFL, O_RDWR) = 0
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=4,
revents=POLLIN}])
recv(4, "8\0\0\0\n5.1.42-log\0\336\1\0\0...@mern\0\377\367\10\2"..., 8192,
MSG_DONTWAIT) = 60
send(4,
"G\0\0\1\215\242\7\0\0\0\0\300\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
75, MSG_DONTWAIT) = 75
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=4,
revents=POLLIN}])
recv(4, "\7\0\0\2\0\0\0\2\0\0\0"..., 8192, MSG_DONTWAIT) = 11
send(4, "%\0\0\0\3SELECT id FROM users ORDER B"..., 41, MSG_DONTWAIT) = 41
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=4,
revents=POLLIN}])
recv(4, "\1\0\0\1\1,\0\0\2\3def\10mynatnet\5users\5user"..., 8192,
MSG_DONTWAIT) = 8192
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=4,
revents=POLLIN}])
recv(4,
"1606\5\0\0\221\0041487\5\0\0\222\0041560\5\0\0\223\0041310\5\0"..., 8192,
MSG_DONTWAIT) = 7275
write(1, "1318\n"..., 5)= 5
send(4, "%\0\0\0\3SELECT id FROM users ORDER B"..., 41, MSG_DONTWAIT) = 41
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=4,
revents=POLLIN}])
recv(4, "\1\0\0\1\1,\0\0\2\3def\10mynatnet\5users\5user"..., 8192,
MSG_DONTWAIT) = 8192
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=4,
revents=POLLIN}])
recv(4,
"\0\0\220\0042199\5\0\0\221\0041211\5\0\0\222\0041024\5\0\0\223\00423"...,
8192, MSG_DONTWAIT) = 7275
write(1, "bool(false)\n"..., 12)= 12
write(1, "string(4) \""..., 11) = 11
write(1, "1607"..., 4) = 4
write(1, "\"\n"..., 2) = 2
--
Edit bug report at http://bugs.php.net/bug.php?id=51203&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51203&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51203&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51203&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51203&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51203&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51203&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51203&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51203&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51203&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51203&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51203&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51203&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51203&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51203&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51203&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51203&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51203&r=isapi
Install GNU Sed:
ht
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: Feedback Type: Bug Package: Windows Installer Operating System: Windows 7 (x64) PHP Version: 5.3.1 New Comment: This were the installed extension, but now I have gone back to 5.2.12 because it is a production server extension=php_dbase.dll extension=php_gd2.dll extension=php_imap.dll extension=php_interbase.dll extension=php_mysql.dll extension=php_openssl.dll extension=php_pdo_mysql.dll extension=php_xsl.dll extension=php_zip.dll Previous Comments: [2010-03-04 15:43:21] randy at thehiringsurvey dot com pajoye asked me which extensions were enabled. I'm sorry but because I have uninstalled 5.3.1 and installed 5.2.13 I can no longer say for certain. I do not have a copy of the php.ini from the 5.3.1 installation. I checked my trash, and it's gone. When I installed 5.3.1 I did go through the custom setup and to select extensions. There were a few extensions that I knew I needed. I think that they (PEAR and MySQL) were both selected by default, so I just took the defaults. [2010-03-04 11:29:02] paj...@php.net Which extension(s) are enabled in the php.ini? It could be due to some extensions requiring external DLLs (oracle for example) or the PHP directory not being in your PATH. Try to call php from the command line as well, with or without using the system php.ini (be sure that you have removed or updated the 5.2's php.ini, especially the extension_dir setting). php.exe -n -i no php.ini loaded php.exe -i with system php.ini [2010-03-03 09:26:48] c dot fior at bss-gt dot com I had the same problem with OE Windows Server 2003 ... I had to downgrade to previous release [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
Bug #50613 [Com]: Expected warnings/notices not outputed by PHP on simple array access.
Edit report at http://bugs.php.net/bug.php?id=50613&edit=1 ID: 50613 Comment by: Reported by: felix at amerimerchant dot com Summary: Expected warnings/notices not outputed by PHP on simple array access. Status: No Feedback Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 New Comment: Is there any further step we need to perform to get this out of the "No Feedback" status? Felix's 2010-01-02 00:08 UTC comment answered Jani's question, but we did not see any option for updating the bug status out of the feedback stage ourselves. Is there a manual status change required by Jani, or did we miss an option on the bug reporting form? Previous Comments: [2010-01-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". [2010-01-02 02:08:41] felix at amerimerchant dot com Same behavior using the most recent build I just tried: C:\php5.3.3-dev>php.exe -v PHP 5.3.3-dev (cli) (built: Jan 2 2010 01:06:43) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies C:\php5.3.3-dev>php.exe "C:\Documents and Settings\Administrator\Desktop\test.php" Notice: Uninitialized string offset: 9 in C:\Documents and Settings\Administrator\Desktop test.php on line 6 Notice: Undefined offset: 9 in C:\Documents and Settings\Administrator\Desktop\test.php o line 9 Fatal error: Cannot use object of type stdClass as array in C:\Documents and Settings\Adm nistrator\Desktop\test.php on line 24 C:\php5.3.3-dev> [2009-12-30 23:47:50] 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-12-30 20:55:02] felix at amerimerchant dot com Description: When accessing a variable containing a boolean, integer, floating point, or null value using square bracket syntax, no warning or notice is generated (even if the array index could not exist if the type was silently juggled into a string or array). This occurs even with E_STRICT turned on. Reproduce code: --- Expected result: PHP Notice: Uninitialized string offset: 9 in /tmp/test.php on line 6 PHP Notice: Undefined offset: 9 in /tmp/test.php on line 9 [A notice or warning for line 12] [A notice or warning for line 15] [A notice or warning for line 18] [A notice or warning for line 21] PHP Fatal error: Cannot use object of type stdClass as array in /tmp/test.php on line 24 Actual result: -- PHP Notice: Uninitialized string offset: 9 in /tmp/test.php on line 6 PHP Notice: Undefined offset: 9 in /tmp/test.php on line 9 PHP Fatal error: Cannot use object of type stdClass as array in /tmp/test.php on line 24 -- Edit this bug report at http://bugs.php.net/bug.php?id=50613&edit=1
Bug #50613 [NoF->Opn]: Expected warnings/notices not outputed by PHP on simple array access.
Edit report at http://bugs.php.net/bug.php?id=50613&edit=1 ID: 50613 Updated by: ahar...@php.net Reported by: felix at amerimerchant dot com Summary: Expected warnings/notices not outputed by PHP on simple array access. -Status: No Feedback +Status: Open Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 New Comment: There was an option in the old bug tracker to flick it back to Open. I'm not sure if the new and improved bug tracker does the same. Anyway, reopening. Previous Comments: [2010-03-04 16:13:58] rbetta at amerimerchant dot com Is there any further step we need to perform to get this out of the "No Feedback" status? Felix's 2010-01-02 00:08 UTC comment answered Jani's question, but we did not see any option for updating the bug status out of the feedback stage ourselves. Is there a manual status change required by Jani, or did we miss an option on the bug reporting form? [2010-01-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". [2010-01-02 02:08:41] felix at amerimerchant dot com Same behavior using the most recent build I just tried: C:\php5.3.3-dev>php.exe -v PHP 5.3.3-dev (cli) (built: Jan 2 2010 01:06:43) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies C:\php5.3.3-dev>php.exe "C:\Documents and Settings\Administrator\Desktop\test.php" Notice: Uninitialized string offset: 9 in C:\Documents and Settings\Administrator\Desktop test.php on line 6 Notice: Undefined offset: 9 in C:\Documents and Settings\Administrator\Desktop\test.php o line 9 Fatal error: Cannot use object of type stdClass as array in C:\Documents and Settings\Adm nistrator\Desktop\test.php on line 24 C:\php5.3.3-dev> [2009-12-30 23:47:50] 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-12-30 20:55:02] felix at amerimerchant dot com Description: When accessing a variable containing a boolean, integer, floating point, or null value using square bracket syntax, no warning or notice is generated (even if the array index could not exist if the type was silently juggled into a string or array). This occurs even with E_STRICT turned on. Reproduce code: --- Expected result: PHP Notice: Uninitialized string offset: 9 in /tmp/test.php on line 6 PHP Notice: Undefined offset: 9 in /tmp/test.php on line 9 [A notice or warning for line 12] [A notice or warning for line 15] [A notice or warning for line 18] [A notice or warning for line 21] PHP Fatal error: Cannot use object of type stdClass as array in /tmp/test.php on line 24 Actual result: -- PHP Notice: Uninitialized string offset: 9 in /tmp/test.php on line 6 PHP Notice: Undefined offset: 9 in /tmp/test.php on line 9 PHP Fatal error: Cannot use object of type stdClass as array in /tmp/test.php on line 24 -- Edit this bug report at http://bugs.php.net/bug.php?id=50613&edit=1
Req #12802 [Com]: gethostbyname/gethostbyaddr timeout
Edit report at http://bugs.php.net/bug.php?id=12802&edit=1 ID: 12802 Comment by: Reported by: cheapsalsa at yahoo dot com Summary: gethostbyname/gethostbyaddr timeout Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Linux (N/A) PHP Version: 4.0CVS-2001-08-16 New Comment: bump Previous Comments: [2009-03-04 19:19:12] adifranco at tagged dot com Any intent to fix this? This kind of indeterminism is very crippling to trying to use these functions in a feature that interacts with the user. [2003-08-10 22:54:12] grimtraffic at hotmail dot com To be honest, no timeout has really made it hard to log users. There is no point of logging IP's because they change too often for dial-up users, and with my page timing out every third time someone goes to it, I now have troubles. By the way, 2 out of 3 who use gethostbyaddr have an issue with it timing out constantly. [2003-02-05 06:19:54] sergi at millorsoft dot es Is this bug still open? I think it's a really important bug and can cause very long retards when the DNS lookup doesn't respond or some DNS server is unreacheable. [2001-08-16 21:03:38] cheapsalsa at yahoo dot com I propose creating a timeout argument on the gethostbyname and gethostbyaddr. I have a script that uses these, and if my internet connection goes down it takes 1:30-2:00 minutes for 3 gethostbyname's to timeout. This is way to long, and it would help if I could specify a timeout. -- Edit this bug report at http://bugs.php.net/bug.php?id=12802&edit=1
Req #45952 [Com]: Timeout need for gethostbyname()
Edit report at http://bugs.php.net/bug.php?id=45952&edit=1 ID: 45952 Comment by: Reported by: shefik at allknightaccess dot com Summary: Timeout need for gethostbyname() Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 New Comment: bump Previous Comments: [2008-08-29 18:07:18] shefik at allknightaccess dot com Description: When using the function gethostbyname(), a script can hang indefinitely if the host being queried is down or currently having name server failures. Therefore, a timeout is needed for this function, so the script can continue executing, instead of being stuck at trying to reach an inaccessible host. I know the docs at http://us3.php.net/manual/en/function.gethostbyname.php state "Returns the IP address or a string containing the unmodified hostname on failure." but the the hostname is having dns/nameserver failures at the time of query, then the hostname does not get returned on failure. the script will hang at this function. I am using PHP 5.2.6. How come bug #12802 is still open and not getting addressed? This bug was originally submitted Aug 16, 2001. It is now Aug 29, 2008. 7 years later and still the same bug!!! Why is this bug being ignored for so long? -- Edit this bug report at http://bugs.php.net/bug.php?id=45952&edit=1
Bug #51185 [Fbk]: 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 Updated by: paj...@php.net Reported by: randy at thehiringsurvey dot com Summary: Apache won't start after PHP 5.3.1 is installed Status: Feedback Type: Bug Package: Windows Installer Operating System: Windows 7 (x64) PHP Version: 5.3.1 New Comment: interbase is not available in 5.3, so I think you were using the old php.ini or messing extensions. Previous Comments: [2010-03-04 16:00:19] c dot fior at bss-gt dot com This were the installed extension, but now I have gone back to 5.2.12 because it is a production server extension=php_dbase.dll extension=php_gd2.dll extension=php_imap.dll extension=php_interbase.dll extension=php_mysql.dll extension=php_openssl.dll extension=php_pdo_mysql.dll extension=php_xsl.dll extension=php_zip.dll [2010-03-04 15:43:21] randy at thehiringsurvey dot com pajoye asked me which extensions were enabled. I'm sorry but because I have uninstalled 5.3.1 and installed 5.2.13 I can no longer say for certain. I do not have a copy of the php.ini from the 5.3.1 installation. I checked my trash, and it's gone. When I installed 5.3.1 I did go through the custom setup and to select extensions. There were a few extensions that I knew I needed. I think that they (PEAR and MySQL) were both selected by default, so I just took the defaults. [2010-03-04 11:29:02] paj...@php.net Which extension(s) are enabled in the php.ini? It could be due to some extensions requiring external DLLs (oracle for example) or the PHP directory not being in your PATH. Try to call php from the command line as well, with or without using the system php.ini (be sure that you have removed or updated the 5.2's php.ini, especially the extension_dir setting). php.exe -n -i no php.ini loaded php.exe -i with system php.ini [2010-03-03 09:26:48] c dot fior at bss-gt dot com I had the same problem with OE Windows Server 2003 ... I had to downgrade to previous release [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
Bug #42457 [Com]: PHP directive magic_quotes_sybase not getting enabled in php6 by ini_set() func
Edit report at http://bugs.php.net/bug.php?id=42457&edit=1 ID: 42457 Comment by: Reported by: nikhil dot gupta at in dot ibm dot com Summary: PHP directive magic_quotes_sybase not getting enabled in php6 by ini_set() func Status: Bogus Type: Bug Package: Strings related Operating System: linux, windows PHP Version: 6CVS-2007-08-28 (CVS) New Comment: Good evening. Be honorable yourself if you wish to associate with honorable people. Help me! There is an urgent need for sites: Best swiss made replica rolex watches. I found only this - http://pin.if.uz.zgora.pl/Members/RolexReplicaWatch/rolex-replica-watch-buy-online";>rolex replica watch buy online. Caution is the most electronic-mechanical effective for watches, rolex replica watch. Rolex replica watch, in industry the jewelry is the alsorolex of special  know of the ever-popular club construction. :confused: Thanks in advance. Garnet from Uzbekistan. Previous Comments: [2007-08-28 20:38:39] 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 . [2007-08-28 20:27:25] judas dot iscariote at gmail dot com Expected behaviuor. all magic_quotes_* functionality has been removed from PHP6, you really dont want this damn magic_quotes_* thing ;) [2007-08-28 10:42:58] nikhil dot gupta at in dot ibm dot com Description: On using ini_set() function to enable PHP directive magic_quotes_sybase, we get bool(false) and directive is not enabled. This behaviour is seen only for php6. On php5, directive gets enabled using ini_set(). Reproduce code: --- Expected result: string(12) "how\'re you?" string(1) "0" string(12) "how''re you?" Actual result: -- string(12) "how\'re you?" bool(false) string(12) "how\'re you?" -- Edit this bug report at http://bugs.php.net/bug.php?id=42457&edit=1
Req #45952 [Opn->Dup]: Timeout need for gethostbyname()
Edit report at http://bugs.php.net/bug.php?id=45952&edit=1 ID: 45952 Updated by: ahar...@php.net Reported by: shefik at allknightaccess dot com Summary: Timeout need for gethostbyname() -Status: Open +Status: Duplicate Type: Feature/Change Request Package: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 New Comment: Dupe of the aforementioned bug #12802. Previous Comments: [2010-03-04 16:35:35] tyra3l at gmail dot com bump [2008-08-29 18:07:18] shefik at allknightaccess dot com Description: When using the function gethostbyname(), a script can hang indefinitely if the host being queried is down or currently having name server failures. Therefore, a timeout is needed for this function, so the script can continue executing, instead of being stuck at trying to reach an inaccessible host. I know the docs at http://us3.php.net/manual/en/function.gethostbyname.php state "Returns the IP address or a string containing the unmodified hostname on failure." but the the hostname is having dns/nameserver failures at the time of query, then the hostname does not get returned on failure. the script will hang at this function. I am using PHP 5.2.6. How come bug #12802 is still open and not getting addressed? This bug was originally submitted Aug 16, 2001. It is now Aug 29, 2008. 7 years later and still the same bug!!! Why is this bug being ignored for so long? -- Edit this bug report at http://bugs.php.net/bug.php?id=45952&edit=1
Bug #9970 [Com]: fread() and file() cancels reading of any file on first #26 (Ctrl-Z) symbol
Edit report at http://bugs.php.net/bug.php?id=9970&edit=1
ID: 9970
Comment by:
Reported by: rmi at moscowmail dot com
Summary: fread() and file() cancels reading of any file on
first #26 (Ctrl-Z) symbol
Status: Closed
Type: Bug
Package: Filesystem function related
Operating System: Win2000 Server/Russian
PHP Version: 4.0.4pl1
New Comment:
Hello everyone. If one sticks too rigidly to one's principles, one would
hardly see anybody. Help me! Could you help me find sites on the: Altace
cost. I found only this - http://www.tuxisalive.com/Members/Altace/altace-lipitor-plavix-topol";>altace
lipitor plavix topol. They include myeloma as an other need,
nonsteroidal to proper waltzes, but one which they improve advice
assess, altace. Altace, how will my physical visits pain for 2008? :mad:
Thanks in advance. Jumoke from Chile.
Previous Comments:
[2001-03-24 12:03:50] sni...@php.net
file() function was changed to open file in binary
mode in the CVS (2000/12/12).
--Jani
[2001-03-24 11:05:45] der...@php.net
This is not a bug, if you open the file with fopen ("filename", "rb");
(b = binary) it should work fine.
file() however wont work this way.
[2001-03-24 10:49:54] rmi at moscowmail dot com
This happens only in ISAPI module. fread() and file () reads only
portion of the given file from beginning to the first #26 character.
fgetc() returns an empty string instead of it.
--
Edit this bug report at http://bugs.php.net/bug.php?id=9970&edit=1
Req #28040 [Com]: __DIR__ - Another 'magic constant'
Edit report at http://bugs.php.net/bug.php?id=28040&edit=1 ID: 28040 Comment by: Reported by: fb at fbeyer dot com Summary: __DIR__ - Another 'magic constant' Status: Wont fix Type: Feature/Change Request Package: Feature/Change Request Operating System: * PHP Version: * New Comment: "we will not add this" http://php.net/manual/en/language.constants.predefined.php :) Previous Comments: [2004-04-18 01:01:41] der...@php.net Just use dirname(__FILE__) if you need this information, we will not add this. regards, Derick [2004-04-17 20:23:00] he...@php.net This would also ease writing test scripts. [2004-04-17 19:50:45] fb at fbeyer dot com Description: It would be extremely handy to extend the 'magic constant' family by __DIR__ - a constant poining to the directory where the current file is located, ending with a directory separator slash. __DIR__ could be defined in user-land by Many scripts (e.g. SMARTY_DIR) already define variables/constants for this purpose. __DIR__ would be a nice feature to write include_path independent scripts. -- Edit this bug report at http://bugs.php.net/bug.php?id=28040&edit=1
Bug #50150 [Com]: stat() / lstat() does not work on a mounted cifs
Edit report at http://bugs.php.net/bug.php?id=50150&edit=1 ID: 50150 Comment by: Reported by: balanalin2003 at yahoo dot com Summary: stat() / lstat() does not work on a mounted cifs Status: Bogus Type: Bug Package: Streams related Operating System: ubuntu 9.10 PHP Version: 5.3.0 New Comment: Using SuSE v11.2 with Kernel v2.6.31.5-0.1-default I have the same problem with the SuSE provided PHP v5.3.1 and with clean builds of v5.3.1 and v5.2.13. I can stat from the command line (even through PHP using shell_exec) but all stat() related PHP functions fail. The interesting thing is that stat() works on Linux CIFS shares, but not Windows CIFS shares. Is there some way I can print debug information for each step of the stat() function in the C code to better trouble shoot this? If its a streams problem, can you describe what exactly the problem is? Its not isolated to one machine either. There are several systems in my office that exhibit the same problem. It works properly under SuSE v10.3 and PHP v4.4.0. At the very least, an indication as to what caused the failure would be helpful in the PHP error message. Previous Comments: [2009-11-17 12:37:54] j...@php.net Most likely OS issue. Not PHP bug -> Bogus. [2009-11-17 12:28:06] balanalin2003 at yahoo dot com still getting this error, it may be a problem with my os, or the mount because i have try it on a fedora 7 and filesize worked, wait until you get another report to confirm this, i'm using java until then. Thanks [2009-11-16 09:49:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And use --disable-phar in your configure line. [2009-11-16 06:29:03] balanalin2003 at yahoo dot com r...@alin-laptop:~# uname -r 2.6.31-14-generic Launchpad Janitor wrote on 2009-01-12: #20 This bug was fixed in the package linux - 2.6.28-4.10 so if i have 2.6.31 and it was fixed in 2.6.28, this shouldn't bee the problem thanks for you're response [2009-11-12 17:44:53] j...@php.net Yes, but stat on command line might be different to stat() function. :) Please check the kernel version compared to where this bug is fixed. (and when you give feedback, use the "Edit Submission" link, NOT the "Add Comment"..) 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=50150 -- Edit this bug report at http://bugs.php.net/bug.php?id=50150&edit=1
Bug #50150 [Com]: stat() / lstat() does not work on a mounted cifs
Edit report at http://bugs.php.net/bug.php?id=50150&edit=1 ID: 50150 Comment by: Reported by: balanalin2003 at yahoo dot com Summary: stat() / lstat() does not work on a mounted cifs Status: Bogus Type: Bug Package: Streams related Operating System: ubuntu 9.10 PHP Version: 5.3.0 New Comment: I would like to add that the command line stat returns an Inode value of 281474976718220 on the 'broken' system and 55187670 on the 'working' system. This is suspect to me. Shouldn't it be the same across the board? Previous Comments: [2010-03-04 18:49:08] mpiazza at benefitresource dot com Using SuSE v11.2 with Kernel v2.6.31.5-0.1-default I have the same problem with the SuSE provided PHP v5.3.1 and with clean builds of v5.3.1 and v5.2.13. I can stat from the command line (even through PHP using shell_exec) but all stat() related PHP functions fail. The interesting thing is that stat() works on Linux CIFS shares, but not Windows CIFS shares. Is there some way I can print debug information for each step of the stat() function in the C code to better trouble shoot this? If its a streams problem, can you describe what exactly the problem is? Its not isolated to one machine either. There are several systems in my office that exhibit the same problem. It works properly under SuSE v10.3 and PHP v4.4.0. At the very least, an indication as to what caused the failure would be helpful in the PHP error message. [2009-11-17 12:37:54] j...@php.net Most likely OS issue. Not PHP bug -> Bogus. [2009-11-17 12:28:06] balanalin2003 at yahoo dot com still getting this error, it may be a problem with my os, or the mount because i have try it on a fedora 7 and filesize worked, wait until you get another report to confirm this, i'm using java until then. Thanks [2009-11-16 09:49:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And use --disable-phar in your configure line. [2009-11-16 06:29:03] balanalin2003 at yahoo dot com r...@alin-laptop:~# uname -r 2.6.31-14-generic Launchpad Janitor wrote on 2009-01-12: #20 This bug was fixed in the package linux - 2.6.28-4.10 so if i have 2.6.31 and it was fixed in 2.6.28, this shouldn't bee the problem thanks for you're response 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=50150 -- Edit this bug report at http://bugs.php.net/bug.php?id=50150&edit=1
Bug #50150 [Bgs]: stat() / lstat() does not work on a mounted cifs
Edit report at http://bugs.php.net/bug.php?id=50150&edit=1 ID: 50150 Updated by: ras...@php.net Reported by: balanalin2003 at yahoo dot com Summary: stat() / lstat() does not work on a mounted cifs Status: Bogus Type: Bug Package: Streams related Operating System: ubuntu 9.10 PHP Version: 5.3.0 New Comment: This doesn't sound like a PHP problem at all. My best guess is that you have a 32/64-bit mismatch here. And PHP doesn't currently support 64-bit inodes. There are some patches floating around that will eventually be folded in to address this though. See bug #48886 Previous Comments: [2010-03-04 18:54:36] mpiazza at benefitresource dot com I would like to add that the command line stat returns an Inode value of 281474976718220 on the 'broken' system and 55187670 on the 'working' system. This is suspect to me. Shouldn't it be the same across the board? [2010-03-04 18:49:08] mpiazza at benefitresource dot com Using SuSE v11.2 with Kernel v2.6.31.5-0.1-default I have the same problem with the SuSE provided PHP v5.3.1 and with clean builds of v5.3.1 and v5.2.13. I can stat from the command line (even through PHP using shell_exec) but all stat() related PHP functions fail. The interesting thing is that stat() works on Linux CIFS shares, but not Windows CIFS shares. Is there some way I can print debug information for each step of the stat() function in the C code to better trouble shoot this? If its a streams problem, can you describe what exactly the problem is? Its not isolated to one machine either. There are several systems in my office that exhibit the same problem. It works properly under SuSE v10.3 and PHP v4.4.0. At the very least, an indication as to what caused the failure would be helpful in the PHP error message. [2009-11-17 12:37:54] j...@php.net Most likely OS issue. Not PHP bug -> Bogus. [2009-11-17 12:28:06] balanalin2003 at yahoo dot com still getting this error, it may be a problem with my os, or the mount because i have try it on a fedora 7 and filesize worked, wait until you get another report to confirm this, i'm using java until then. Thanks [2009-11-16 09:49:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And use --disable-phar in your configure line. 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=50150 -- Edit this bug report at http://bugs.php.net/bug.php?id=50150&edit=1
Bug #3952 [Com]: shm_attach crashes httpd-process, if shmat fails
Edit report at http://bugs.php.net/bug.php?id=3952&edit=1
ID: 3952
Comment by:
Reported by: baumert at pilot-webdesign dot de
Summary: shm_attach crashes httpd-process, if shmat fails
Status: Wont fix
Type: Bug
Package: Reproducible Crash
Operating System: Linux 2.0.36, 2.2.14
PHP Version: 3.0.15
New Comment:
Excuse me. Whenever people agree with me I always feel I must be wrong.
Help me! Please help find sites for: Oral isotretinoin vs. I found only
this - http://www.ndsg.co.nz/Members/Isotretinoin";>definition
isotretinoin. Vaporizer treatment - pimples of syndrome heats with
posted ebook reduces and makes in injuries, isotretinoin. Isotretinoin,
severe foods can be increased by otc abnormalities in the acne of
treadmills, symptoms, lives and cases that can be shown thus on the
distressing increase. Thank :-( Kesia from Nicaragua.
Previous Comments:
[2005-03-31 16:13:18] php-bugs at lists dot php dot net
We are sorry, but we do not support PHP 3 related problems anymore.
[2000-03-28 18:31:06] baumert at pilot-webdesign dot de
shm_attach asks, if the return value of shmat is zero. This never
happens.
The error-condition return value is -1.
So just change 162 from
if((shm_ptr = shmat(shm_id,NULL,0))==NULL) {
to
if((shm_ptr = shmat(shm_id,NULL,0))==-1) {
Greetings
Florian
--
Edit this bug report at http://bugs.php.net/bug.php?id=3952&edit=1
Bug #50150 [Com]: stat() / lstat() does not work on a mounted cifs
Edit report at http://bugs.php.net/bug.php?id=50150&edit=1 ID: 50150 Comment by: Reported by: balanalin2003 at yahoo dot com Summary: stat() / lstat() does not work on a mounted cifs Status: Bogus Type: Bug Package: Streams related Operating System: ubuntu 9.10 PHP Version: 5.3.0 New Comment: If support needs to be added to PHP, isn't that a PHP problem. Based on rasmus's suggestion, I've discovered a workaround for now. If you specify "-o noserverino" at mount time the client will assign the inodes instead of the server. I am unaware of any side effects of doing this besides the possibility of not being able to detect hard links correctly. Previous Comments: [2010-03-04 19:14:24] ras...@php.net This doesn't sound like a PHP problem at all. My best guess is that you have a 32/64-bit mismatch here. And PHP doesn't currently support 64-bit inodes. There are some patches floating around that will eventually be folded in to address this though. See bug #48886 [2010-03-04 18:54:36] mpiazza at benefitresource dot com I would like to add that the command line stat returns an Inode value of 281474976718220 on the 'broken' system and 55187670 on the 'working' system. This is suspect to me. Shouldn't it be the same across the board? [2010-03-04 18:49:08] mpiazza at benefitresource dot com Using SuSE v11.2 with Kernel v2.6.31.5-0.1-default I have the same problem with the SuSE provided PHP v5.3.1 and with clean builds of v5.3.1 and v5.2.13. I can stat from the command line (even through PHP using shell_exec) but all stat() related PHP functions fail. The interesting thing is that stat() works on Linux CIFS shares, but not Windows CIFS shares. Is there some way I can print debug information for each step of the stat() function in the C code to better trouble shoot this? If its a streams problem, can you describe what exactly the problem is? Its not isolated to one machine either. There are several systems in my office that exhibit the same problem. It works properly under SuSE v10.3 and PHP v4.4.0. At the very least, an indication as to what caused the failure would be helpful in the PHP error message. [2009-11-17 12:37:54] j...@php.net Most likely OS issue. Not PHP bug -> Bogus. [2009-11-17 12:28:06] balanalin2003 at yahoo dot com still getting this error, it may be a problem with my os, or the mount because i have try it on a fedora 7 and filesize worked, wait until you get another report to confirm this, i'm using java until then. Thanks 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=50150 -- Edit this bug report at http://bugs.php.net/bug.php?id=50150&edit=1
Bug #50150 [Bgs]: stat() / lstat() does not work on a mounted cifs
Edit report at http://bugs.php.net/bug.php?id=50150&edit=1 ID: 50150 Updated by: ras...@php.net Reported by: balanalin2003 at yahoo dot com Summary: stat() / lstat() does not work on a mounted cifs Status: Bogus Type: Bug Package: Streams related Operating System: ubuntu 9.10 PHP Version: 5.3.0 New Comment: It's a feature request that has already been covered elsewhere, not a bug. Previous Comments: [2010-03-04 19:41:38] mpiazza at benefitresource dot com If support needs to be added to PHP, isn't that a PHP problem. Based on rasmus's suggestion, I've discovered a workaround for now. If you specify "-o noserverino" at mount time the client will assign the inodes instead of the server. I am unaware of any side effects of doing this besides the possibility of not being able to detect hard links correctly. [2010-03-04 19:14:24] ras...@php.net This doesn't sound like a PHP problem at all. My best guess is that you have a 32/64-bit mismatch here. And PHP doesn't currently support 64-bit inodes. There are some patches floating around that will eventually be folded in to address this though. See bug #48886 [2010-03-04 18:54:36] mpiazza at benefitresource dot com I would like to add that the command line stat returns an Inode value of 281474976718220 on the 'broken' system and 55187670 on the 'working' system. This is suspect to me. Shouldn't it be the same across the board? [2010-03-04 18:49:08] mpiazza at benefitresource dot com Using SuSE v11.2 with Kernel v2.6.31.5-0.1-default I have the same problem with the SuSE provided PHP v5.3.1 and with clean builds of v5.3.1 and v5.2.13. I can stat from the command line (even through PHP using shell_exec) but all stat() related PHP functions fail. The interesting thing is that stat() works on Linux CIFS shares, but not Windows CIFS shares. Is there some way I can print debug information for each step of the stat() function in the C code to better trouble shoot this? If its a streams problem, can you describe what exactly the problem is? Its not isolated to one machine either. There are several systems in my office that exhibit the same problem. It works properly under SuSE v10.3 and PHP v4.4.0. At the very least, an indication as to what caused the failure would be helpful in the PHP error message. [2009-11-17 12:37:54] j...@php.net Most likely OS issue. Not PHP bug -> Bogus. 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=50150 -- Edit this bug report at http://bugs.php.net/bug.php?id=50150&edit=1
Bug #50684 [Com]: max_file_uploads can't be changed from .htaccess (or ini_set)
Edit report at http://bugs.php.net/bug.php?id=50684&edit=1 ID: 50684 Comment by: Reported by: john dot peterson10 at gmail dot com Summary: max_file_uploads can't be changed from .htaccess (or ini_set) Status: Bogus Type: Bug Package: PHP options/info functions Operating System: Windows PHP Version: 5.2.12 New Comment: Can we at least get the documentation changed? Currently it says PHP_INI_ALL which would include htaccess and ini_set. Previous Comments: [2010-01-07 10:15:21] j...@php.net Allowing that to be changed would open a can of worms. [2010-01-07 08:33:59] john dot peterson10 at gmail dot com Description: The setting max_file_uploads can't be changed from .htaccess. I think it should be possible to change max_file_uploads, like it's possible to change upload_max_filesize, post_max_size and max_input_time from .htaccess. Reproduce code: --- @.htaccess php_value max_file_uploads 50 @settings.php Expected result: max_file_uploads is changed to 50 Actual result: -- max_file_uploads is not changed from its default (or php.ini) value -- Edit this bug report at http://bugs.php.net/bug.php?id=50684&edit=1
Bug #38805 [Com]: PDO Truncates Text from SQL Server Text Data Type Field
Edit report at http://bugs.php.net/bug.php?id=38805&edit=1
ID: 38805
Comment by:
Reported by: gkrajci at arescorporation dot com
Summary: PDO Truncates Text from SQL Server Text Data Type
Field
Status: Assigned
Type: Bug
Package: PDO related
Operating System: Windows NT PBMA-WB2 5.2 build 37
PHP Version: 5.1.6
Assigned To: sfox
New Comment:
I solved this problem by adding to my php script a TEXTSIZE that is less
than the allowed memory from the MSSQL server.
Remember, all the number are in Bytes, so I kept playing with the
numbers, until this worked:
// ranges from 0 - 3145728 = 3Megabytes. Default to 4096.
$sql = "SET TEXTSIZE 3145728";
mssql_query($sql, $db) or die(mssql_get_last_message());
Remember to always know what the allowed upload size for your server
is.
I hope this helps someone
Previous Comments:
[2010-02-12 16:57:02] s...@php.net
Those changes are still in SVN. That means the TEXTLIMIT var is being
set to its highest possible value, which in turn means that truncation
shouldn't be an issue now.
$pdo->query('SET TEXTSIZE 30');
should work from PHP 5.2.11 up, it just needs doccing.
[2010-02-12 09:05:28] philipp at servicemail24 dot de
This problem is actually fixed in cvs:
http://www.mail-archive.com/php-...@lists.php.net/msg40731.html
http://www.mail-archive.com/php-...@lists.php.net/msg40711.html
Here is the working source code:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_dblib/
I have no idea why these fixes aren't included in the 5.2 and 5.3
releases!
@sfox can you ensure that pdo_dblib is updated with the release of
5.2.13 and 5.3.2?
[2010-02-11 15:40:43] philipp at servicemail24 dot de
php 5.3.2 dotdeb still suffers from this problem.
does this fix help?
"Possible fix: remove "case SQLTEXT" from
ext/pdo_dblib/dblib_stmt.c:execute and let it fall though to default."
[2010-01-22 22:51:02] ssufficool at gmail dot com
I imagine the problem is that PDO DBLIB just mem-copies the first packet
of TEXT without calling dbgettext() to retrieve the remainder.
MSSQL handles TEXT fields using dbconvert() which may call dbgettext()
downstream.
Possible fix: remove "case SQLTEXT" from
ext/pdo_dblib/dblib_stmt.c:execute and let it fall though to default.
[2010-01-10 23:22:50] ka...@php.net
Steph, does this need any additional changes to pdo_mssql/pdo_dblib? And
what exactly should be documented?
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=38805
--
Edit this bug report at http://bugs.php.net/bug.php?id=38805&edit=1
Req #15013 [Com]: String length restriction in mssql functions
Edit report at http://bugs.php.net/bug.php?id=15013&edit=1 ID: 15013 Comment by: Reported by: blakjak at webone dot com dot au Summary: String length restriction in mssql functions Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Win2k PHP Version: 4.1.0 New Comment: I'm getting this issue when connecting to Teradata via ODBC. PHP 5.3.1 OS Windows 2003. Please fix it as I'd like to standardise on one set of functions (PDO) for all my DB access (ODBC, SQL Server, Teradata, Oracle, etc) Previous Comments: [2002-01-12 22:50:01] blakjak at webone dot com dot au I read in the response to a previous bug report that the mssql extension doesn't support varchar or char columns larger than 255 characters. My request is that the extension be updated to cope with the 8KB maximum in SQL Server. Please. BJ -- Edit this bug report at http://bugs.php.net/bug.php?id=15013&edit=1
Bug #50578 [Com]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Comment by: Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar Status: Assigned Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 Assigned To: cellog New Comment: Same issue with 5.3.2 finale. Previous Comments: [2010-02-12 14:19:44] Fedora at famillecollet dot com Same issue with PHP 5.3.2RC2 [2009-12-26 12:28:34] Fedora at FamilleCollet dot com Trivial which fix the issue : http://remi.fedorapeople.org/php-5.3.2-phar.patch [2009-12-26 12:26:46] Fedora at FamilleCollet dot com Description: default PHP_PHARCMD_BANG is PHP_EXCUTABLE which is relative to top_builddir. This result to a php.phar which include a bad path to php. Until PHP 5.3.1, PHP_EXCUTABLE was not set (by default) on Makefile, so all works fine With 5.3.2RC1, PHP_EXCUTABLE is set to $(top_builddir)/$(SAPI_CLI_PATH) -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
[PHP-BUG] Bug #51205 [NEW]: Fatal error: com_exception: The parameter is incorrect
From:
Operating system: Windows XP
PHP version: 5.3.1
Package: COM related
Bug Type: Bug
Bug description:Fatal error: com_exception: The parameter is incorrect
Description:
Hi,
I need to use RNGCryptoServiceProvider in PHP.
I have tried:
$rng = new DOTNET("mscorlib",
"System.Security.Cryptography.RNGCryptoServiceProvider");
$arr = array(0);
$v = new VARIANT($arr,VT_ARRAY);
$rng->GetBytes($v);
unset($rng);
The component loads fine.
But I got this error: Fatal error: Uncaught exception 'com_exception'
with message 'Error [0x80070057] The parameter is incorrect.
Any ideas?
--
Edit bug report at http://bugs.php.net/bug.php?id=51205&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51205&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51205&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51205&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51205&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51205&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51205&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51205&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51205&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51205&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51205&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51205&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51205&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51205&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51205&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51205&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51205&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51205&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51205&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51205&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51205&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51205&r=mysqlcfg
[PHP-BUG] Bug #51206 [NEW]: PHP4 works, PHP5 says "this variant has no properties"
From:
Operating system: Windows XP
PHP version: 5.3.1
Package: COM related
Bug Type: Bug
Bug description:PHP4 works, PHP5 says "this variant has no properties"
Description:
Test script works, as expected, under PHP4. Gives nonsensical error under
PHP5.
Test script:
---
getBinaryValue(0x8002,
'SOFTWARE\\Microsoft\\Cryptography\\RNG', 'Seed', $values);
var_dump($values->value);
?>
Expected result:
>From PHP4:
array(80) {
[0]=>
int(105)
[1]=>
int(144)
[2]=>
int(158)
[3]=>
int(99)
[4]=>
int(155)
[5]=>
int(55)
[6]=>
int(130)
[7]=>
int(185)
[8]=>
int(210)
[9]=>
int(60)
[10]=>
int(182)
[11]=>
int(200)
[12]=>
int(170)
[13]=>
int(52)
[14]=>
int(34)
[15]=>
int(86)
[16]=>
int(17)
[17]=>
int(147)
[18]=>
int(100)
[19]=>
int(212)
[20]=>
int(205)
[21]=>
int(146)
[22]=>
int(243)
[23]=>
int(102)
[24]=>
int(17)
[25]=>
int(159)
[26]=>
int(193)
[27]=>
int(252)
[28]=>
int(189)
[29]=>
int(83)
[30]=>
int(143)
[31]=>
int(51)
[32]=>
int(183)
[33]=>
int(3)
[34]=>
int(48)
[35]=>
int(46)
[36]=>
int(102)
[37]=>
int(73)
[38]=>
int(210)
[39]=>
int(237)
[40]=>
int(13)
[41]=>
int(244)
[42]=>
int(194)
[43]=>
int(117)
[44]=>
int(254)
[45]=>
int(234)
[46]=>
int(166)
[47]=>
int(147)
[48]=>
int(104)
[49]=>
int(192)
[50]=>
int(211)
[51]=>
int(117)
[52]=>
int(50)
[53]=>
int(148)
[54]=>
int(253)
[55]=>
int(148)
[56]=>
int(237)
[57]=>
int(85)
[58]=>
int(70)
[59]=>
int(242)
[60]=>
int(32)
[61]=>
int(159)
[62]=>
int(38)
[63]=>
int(182)
[64]=>
int(211)
[65]=>
int(36)
[66]=>
int(205)
[67]=>
int(115)
[68]=>
int(212)
[69]=>
int(117)
[70]=>
int(40)
[71]=>
int(249)
[72]=>
int(102)
[73]=>
int(67)
[74]=>
int(100)
[75]=>
int(147)
[76]=>
int(236)
[77]=>
int(194)
[78]=>
int(241)
[79]=>
int(28)
}
Actual result:
--
>From PHP5:
Fatal error: Uncaught exception 'com_exception' with message 'this variant
has no properties' in C:\php\test.php:5 Stack trace: #0 C:\php\test.php(5):
unknown() #1 {main} thrown in C:\php\test.php on line 5
--
Edit bug report at http://bugs.php.net/bug.php?id=51206&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51206&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51206&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51206&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51206&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51206&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51206&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51206&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51206&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51206&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51206&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51206&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51206&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51206&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51206&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51206&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51206&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51206&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51206&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51206&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51206&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51206&r=mysqlcfg
Bug #50578 [Asn]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Updated by: paj...@php.net Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar Status: Assigned Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 -Assigned To: cellog +Assigned To: dufuz New Comment: Please take a look at this patch and let us know if it works. It would rock if it can make it in the next release. Previous Comments: [2010-03-04 22:30:55] Fedora at famillecollet dot com Same issue with 5.3.2 finale. [2010-02-12 14:19:44] Fedora at famillecollet dot com Same issue with PHP 5.3.2RC2 [2009-12-26 12:28:34] Fedora at FamilleCollet dot com Trivial which fix the issue : http://remi.fedorapeople.org/php-5.3.2-phar.patch [2009-12-26 12:26:46] Fedora at FamilleCollet dot com Description: default PHP_PHARCMD_BANG is PHP_EXCUTABLE which is relative to top_builddir. This result to a php.phar which include a bad path to php. Until PHP 5.3.1, PHP_EXCUTABLE was not set (by default) on Makefile, so all works fine With 5.3.2RC1, PHP_EXCUTABLE is set to $(top_builddir)/$(SAPI_CLI_PATH) -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
Bug #50578 [Asn]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Updated by: paj...@php.net Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar Status: Assigned Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 -Assigned To: dufuz +Assigned To: cellog New Comment: Greg, can you valid and apply the patch please? Or simply valid it and I can apply it if it looks fine for you. Previous Comments: [2010-03-05 01:04:57] paj...@php.net Please take a look at this patch and let us know if it works. It would rock if it can make it in the next release. [2010-03-04 22:30:55] Fedora at famillecollet dot com Same issue with 5.3.2 finale. [2010-02-12 14:19:44] Fedora at famillecollet dot com Same issue with PHP 5.3.2RC2 [2009-12-26 12:28:34] Fedora at FamilleCollet dot com Trivial which fix the issue : http://remi.fedorapeople.org/php-5.3.2-phar.patch [2009-12-26 12:26:46] Fedora at FamilleCollet dot com Description: default PHP_PHARCMD_BANG is PHP_EXCUTABLE which is relative to top_builddir. This result to a php.phar which include a bad path to php. Until PHP 5.3.1, PHP_EXCUTABLE was not set (by default) on Makefile, so all works fine With 5.3.2RC1, PHP_EXCUTABLE is set to $(top_builddir)/$(SAPI_CLI_PATH) -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
[PHP-BUG] Bug #51207 [NEW]: horizontal misalignment of characters extending beyond their left margin
From:
Operating system: Linux & Windows XP
PHP version: 5.2.13
Package: GD related
Bug Type: Bug
Bug description:horizontal misalignment of characters extending beyond their
left margin
Description:
The following bug is present in PHP 5.2.13 and was not present in PHP
5.2.11. (It was probably introduced while attempting to solve Bug #49600.)
My test bed is Windows XP/Apache 2.0, production site runs on Linux/Apache
1.3, both are showing the same symptom.
We are using the commercial font "Pirouette Text" by Linotype which I
obviously cannot include in this report. What sets this font apart from
most other fonts is the fact that some characters extend horizontally
beyond their bounding boxes in terms of character placement.
My little test script spells out the word "Information" in "Pirouette
Text". In this font the letter "f" (among others) is made up of a large
S-like curve extending well into its neighboring letters
Test script:
---
$text = "Information";
$font = "pirouette.otf";
$size = 41;
$dim = imagettfbbox($size, 0, $font, $text);
$off_y = -$dim[7];
$off_x = -$dim[0];
$img_h = $dim[1]+$off_y+1;
$img_w = $dim[2]+$off_x+2;
unset($dim);
$img = imagecreatetruecolor($img_w, $img_h);
imagefilledrectangle($img, 0, 0, $img_w-1, $img_h-1, 0xFF);
imagettftext($img, $size, 0, $off_x, $off_y, 0x00, $font, $text);
header("Content-Type: image/gif");
imagetruecolortopalette($img, false, 32);
imagegif($img);
imagedestroy($img);
Expected result:
This is what it should look like (rendered by PHP 5.2.11):
http://mitglieder.hrc1880.de/penkert/php5_2_11.gif
Actual result:
--
And this is how PHP 5.2.13 messes it up:
http://mitglieder.hrc1880.de/penkert/php5_2_13.gif
--
Edit bug report at http://bugs.php.net/bug.php?id=51207&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51207&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51207&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51207&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51207&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51207&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51207&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51207&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51207&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51207&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51207&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51207&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51207&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51207&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51207&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51207&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51207&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51207&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51207&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51207&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51207&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51207&r=mysqlcfg
Bug #27633 [Com]: Double \r problem on ftp_get in ASCII mode on Win32
Edit report at http://bugs.php.net/bug.php?id=27633&edit=1 ID: 27633 Comment by: Reported by: vr...@php.net Summary: Double \r problem on ftp_get in ASCII mode on Win32 Status: Closed Type: Bug Package: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa New Comment: Good evening. I'm glad I didn't have to fight in any war. I'm glad I didn't have to pick up a gun. I'm glad I didn't get killed or kill somebody. I hope my kids enjoy the same lack of manhood. Help me! Help to find sites on the: Ultram fatal dosage. I found only this - http://www.sasev.org/Members/Ultram";>how to abuse ultram. Ultram, i then post explore the law of her pain. You're away engaging to acquire a extended-release of that online min of importance properties; center by much posting around and staggering for it to test to you, ultram. :cool: Thanks in advance. Clarke from Jordan. Previous Comments: [2005-03-11 15:27:06] vr...@php.net Works for me, thanks! [2005-03-11 00:38:31] il...@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. [2005-02-23 09:59:31] sni...@php.net Ilia, your fix did not work? :) [2005-02-23 09:37:21] vr...@php.net It's the same with the latest Windows snapshot :-(. [2005-02-23 04:54:07] 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 There was some problem with win32 snapshots again.. 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=27633 -- Edit this bug report at http://bugs.php.net/bug.php?id=27633&edit=1
Bug #50999 [Fbk->Csd]: unaligned memory access in Zend/zend_API.c
Edit report at http://bugs.php.net/bug.php?id=50999&edit=1 ID: 50999 Updated by: geiss...@php.net Reported by: geissert at debian dot org Summary: unaligned memory access in Zend/zend_API.c -Status: Feedback +Status: Closed Type: Bug Package: DBM/DBA related Operating System: linux ia64 PHP Version: 5.3SVN-2010-02-12 Assigned To: felipe 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. Yes, it seems to enough to fix it. Thanks. Previous Comments: [2010-03-03 01:30:58] fel...@php.net Hello, I've committed a possible fix, could you check it again? Thanks. [2010-03-03 01:29:40] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=295764 Log: - Possible fix for bug #50999 [2010-02-10 20:59:26] geissert at debian dot org Failed test: ext/dba/tests/dba_cdb_read.phpt log: EXPECTED OUTPUT database handler: cdb 7NNN =1234 #1122 ?1212314 #1212314 =1231324 ACTUAL OUTPUT database handler: cdb 7NNN =1234 #1122 ?1212314 #1212314 =Bus error (core dumped) FAILED [2010-02-10 19:12:28] geissert at debian dot org Description: There's an unaligned memory access on zend_parse_arg_impl(): *p = Z_LVAL_PP(arg); -- Edit this bug report at http://bugs.php.net/bug.php?id=50999&edit=1
Bug #51207 [Opn]: imageTTFText: misalignment of characters which extend beyond their left margin
Edit report at http://bugs.php.net/bug.php?id=51207&edit=1
ID: 51207
User updated by: penkert at yahoo dot com
Reported by: penkert at yahoo dot com
-Summary: horizontal misalignment of characters extending beyond
their left margin
+Summary: imageTTFText: misalignment of characters which extend
beyond their left margin
Status: Open
Type: Bug
Package: GD related
Operating System: Linux & Windows XP
PHP Version: 5.2.13
New Comment:
Sorry, I forgot to mention I'm talking about PHP's imageTTFText
function.
And also, while previewing and editing my report the part of my last
paragraph after the apostrophe got lost. So here it is again:
My little test script spells out the word "Information" in "Pirouette
Text". In this font the letter "f" (among others) is made up of a large
S-like curve extending well into its neighboring letters' "territories".
PHP 5.2.11 places the "f" correctly. PHP 5.2.13, on the other hand,
seems to use the character's leftmost extremum for positioning it next
to the previous character which is, of course, incorrect. There are a
few more minor differences between the two PHP version's resultsall
in favor of 5.2.11.
Previous Comments:
[2010-03-05 01:28:10] penkert at yahoo dot com
Description:
The following bug is present in PHP 5.2.13 and was not present in PHP
5.2.11. (It was probably introduced while attempting to solve Bug
#49600.) My test bed is Windows XP/Apache 2.0, production site runs on
Linux/Apache 1.3, both are showing the same symptom.
We are using the commercial font "Pirouette Text" by Linotype which I
obviously cannot include in this report. What sets this font apart from
most other fonts is the fact that some characters extend horizontally
beyond their bounding boxes in terms of character placement.
My little test script spells out the word "Information" in "Pirouette
Text". In this font the letter "f" (among others) is made up of a large
S-like curve extending well into its neighboring letters
Test script:
---
$text = "Information";
$font = "pirouette.otf";
$size = 41;
$dim = imagettfbbox($size, 0, $font, $text);
$off_y = -$dim[7];
$off_x = -$dim[0];
$img_h = $dim[1]+$off_y+1;
$img_w = $dim[2]+$off_x+2;
unset($dim);
$img = imagecreatetruecolor($img_w, $img_h);
imagefilledrectangle($img, 0, 0, $img_w-1, $img_h-1, 0xFF);
imagettftext($img, $size, 0, $off_x, $off_y, 0x00, $font, $text);
header("Content-Type: image/gif");
imagetruecolortopalette($img, false, 32);
imagegif($img);
imagedestroy($img);
Expected result:
This is what it should look like (rendered by PHP 5.2.11):
http://mitglieder.hrc1880.de/penkert/php5_2_11.gif
Actual result:
--
And this is how PHP 5.2.13 messes it up:
http://mitglieder.hrc1880.de/penkert/php5_2_13.gif
--
Edit this bug report at http://bugs.php.net/bug.php?id=51207&edit=1
Bug #51190 [Csd]: ftp_put() returns false when transfer was successful
Edit report at http://bugs.php.net/bug.php?id=51190&edit=1 ID: 51190 User updated by: alexclifford47 at gmail dot com Reported by: alexclifford47 at gmail dot com Summary: ftp_put() returns false when transfer was successful Status: Closed Type: Bug Package: FTP related Operating System: Windows Server 2003 R2 32-bit PHP Version: 5.3.1 Assigned To: iliaa New Comment: I will give this a try when I get a chance. How long until these fixes are into a stable release? Thanks. Previous Comments: [2010-03-04 13:53:12] il...@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-04 13:52:59] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=295820 Log: Fixed bug #51190 (ftp_put() returns false when transfer was successful). [2010-03-03 15:55:56] araje at usimagingnetwork dot com I'm having the exact same problem.. The upload is successful , however ftp_put returns false... Any info would be appreciated. Thanks Ameya [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
[PHP-BUG] Bug #51210 [NEW]: request_order prevents _COOKIE populating _REQUEST
From:
Operating system: any
PHP version: 5.3.1
Package: *Configuration Issues
Bug Type: Bug
Bug description:request_order prevents _COOKIE populating _REQUEST
Description:
PHP 5.3 introduced a new configuration option named 'request_order'.
# Added "request_order" INI variable to control specifically _REQUEST
behavior. (Stas)"
http://www.php.net/ChangeLog-5.php#5.3.0
It's default value within php.ini (and related comments) are:
--
; This directive determines which super global data (G,P,C,E & S) should
; be registered into the super global array REQUEST. If so, it also
determines
; the order in which that data is registered. The values for this directive
are
; specified in the same manner as the variables_order directive, EXCEPT
one.
; Leaving this value empty will cause PHP to use the value set in the
; variables_order directive. It does not mean it will leave the super
globals
; array REQUEST empty.
; Default Value: None
; Development Value: "GP"
; Production Value: "GP"
; http://www.php.net/manual/en/ini.core.php#ini.request-order
request_order = "GP"
--
This variable omits 'C' for COOKIES.
Versions prior to PHP 5.3 merged the contents of the _COOKIE array into
_REQUEST.
Due to this default configuration change, _REQUEST can no longer be used to
access cookie values without modifying the request_order php.ini variable.
This changes how _REQUEST is used in PHP 5.3 by default.
This appears to be an oversight/bug, because the PHP documentation still
indicates that _REQUEST can be used to access cookies.
" An associative array that by default contains the contents of _GET, _POST
and _COOKIE. "
http://au2.php.net/manual/en/reserved.variables.request.php
Suggested Fix: Update PHP 5.3's default php.ini configuration file to have
'GPC' instead of 'GP' for 'request_order', to restore prior functionality.
Test script:
---
http://pastebin.com/MmwkU0Z3
Expected result:
The line '_REQUEST has the cookie, no bug present.' because the default
php.ini config value for request_order should be 'GPC' to include cookies.
Actual result:
--
The line '_REQUEST is missing TestCookie, there is a bug.' because the
default php.ini config value for request_order currently omits cookies
('GP').
--
Edit bug report at http://bugs.php.net/bug.php?id=51210&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51210&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51210&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51210&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51210&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51210&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51210&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51210&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51210&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51210&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51210&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51210&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51210&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51210&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51210&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51210&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51210&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51210&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51210&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51210&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51210&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51210&r=mysqlcfg
Bug #51135 [Fbk->NoF]: imagettftext does not work for characters > 99999
Edit report at http://bugs.php.net/bug.php?id=51135&edit=1 ID: 51135 Updated by: php-bugs@lists.php.net Reported by: sharon_correll at sil dot org Summary: imagettftext does not work for characters > 9 -Status: Feedback +Status: No Feedback Type: Bug Package: GD related Operating System: Windows Vista PHP Version: 5.2.12 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2010-02-24 22:19:58] paj...@php.net or 5.3.3RC2 (http://windows.php.net/qa/) [2010-02-24 22:19:37] paj...@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-24 20:54:53] sharon_correll at sil dot org Description: The imagettftext function doesn't not work for characters > 9. For instance, U+1869F (9) produces a null glyph for the font that I am using, but U+186A0 (10) produces "𘚠". (I am actually using PHP version 5.2.6. Please tell me if upgrading is likely to fix this problem.) Reproduce code: --- $point_size = 32; $scratch_image = ImageCreateTrueColor( $point_size*10, $point_size*10); $origin_x = 2 * $point_size; $origin_y = 5 * $point_size; $white = ImageColorAllocate($scratch_image, 255, 255, 255); $black = ImageColorAllocate($scratch_image, 0, 0, 0); ImageFill( $scratch_image, 0, 0, $white ); $glyph_text = "𘚠"; // FILL IN THE FONT NAME WITH SOME FONT THAT YOU HAVE AVAILABLE: $box = imagettftext( $scratch_image, $point_size, 0, $origin_x, $origin_y, $black, "FONT.TTF, $glyph_text ); $final_image = imagecreatetruecolor( 300, 200 ); ImageFill( $final_image, 0, 0, $white ); imagecopymerge( $final_image, $scratch_image, 0, 0, $box[6], $box[7], 300, 200, 100 ); imagecolortransparent( $final_image, $white ); imagedestroy( $scratch_image ); imagepng( $final_image, "testbug.png" ); Expected result: I expect the "testbug.png" file to show a "null" glyph (assuming the font doesn't have a glyph for U+186A0--I am using Code 2000 which has a wide range of Unicode characters, but not U+186A0.) Actual result: -- I see "𘚠" instead of the glyph. -- Edit this bug report at http://bugs.php.net/bug.php?id=51135&edit=1
Bug #50934 [Fbk->NoF]: UnexpectedValueException: RecursiveDirectoryIterator
Edit report at http://bugs.php.net/bug.php?id=50934&edit=1
ID: 50934
Updated by: php-bugs@lists.php.net
Reported by: draeli at draeli dot com
Summary: UnexpectedValueException: RecursiveDirectoryIterator
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: SPL related
Operating System: win32 only - Windows
PHP Version: 5.3.1
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2010-02-26 00:19:31] ka...@php.net
Does this work in 5.2.x ?
[2010-02-04 21:52:44] draeli at draeli dot com
I use the latest (I have download, install and try before report).
[2010-02-04 20:37:05] 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-04 19:30:05] draeli at draeli dot com
Description:
Under Windows (XP Sp3) I want to remove files and dir recursively.
When dir contain '-' (dash symbol), error message
"UnexpectedValueException:
RecursiveDirectoryIterator::__construct(E:\directoryTest\name - file)
[recursivedirectoryiterator.--construct]: failed to open dir: No such
file or directory in" is call and script is stop after loop
(consequently dir is really remove)
Reproduce code:
---
foreach (new \RecursiveIteratorIterator(new
\RecursiveDirectoryIterator('E:\directoryTest'),
\RecursiveIteratorIterator::SELF_FIRST) as $objCur) {
if ( $objCur->isDir() ){
rmdir($objCur->getPathname());
}else{
unlink($objCur->getPathname());
}
}
Expected result:
I try to remove file and dir recurvely since one dir.
Actual result:
--
Actual result is file are delete, dir too but script stop after loop if
current read dir contain dash symbol.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50934&edit=1
Bug #51135 [NoF->Bgs]: imagettftext does not work for characters > 99999
Edit report at http://bugs.php.net/bug.php?id=51135&edit=1 ID: 51135 Updated by: ahar...@php.net Reported by: sharon_correll at sil dot org Summary: imagettftext does not work for characters > 9 -Status: No Feedback +Status: Bogus Type: Bug Package: GD related Operating System: Windows Vista PHP Version: 5.2.12 New Comment: This is still happening in PHP_5_3, but it's not a PHP bug as such: it's a bug in libgd itself. There's already an open bug in the libgd issue tracker covering this issue, which still exists in the current HEAD of libgd: http://bugs.libgd.org/?do=details&task_id=42 Previous Comments: [2010-03-05 06:01:03] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2010-02-24 22:19:58] paj...@php.net or 5.3.3RC2 (http://windows.php.net/qa/) [2010-02-24 22:19:37] paj...@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-24 20:54:53] sharon_correll at sil dot org Description: The imagettftext function doesn't not work for characters > 9. For instance, U+1869F (9) produces a null glyph for the font that I am using, but U+186A0 (10) produces "𘚠". (I am actually using PHP version 5.2.6. Please tell me if upgrading is likely to fix this problem.) Reproduce code: --- $point_size = 32; $scratch_image = ImageCreateTrueColor( $point_size*10, $point_size*10); $origin_x = 2 * $point_size; $origin_y = 5 * $point_size; $white = ImageColorAllocate($scratch_image, 255, 255, 255); $black = ImageColorAllocate($scratch_image, 0, 0, 0); ImageFill( $scratch_image, 0, 0, $white ); $glyph_text = "𘚠"; // FILL IN THE FONT NAME WITH SOME FONT THAT YOU HAVE AVAILABLE: $box = imagettftext( $scratch_image, $point_size, 0, $origin_x, $origin_y, $black, "FONT.TTF, $glyph_text ); $final_image = imagecreatetruecolor( 300, 200 ); ImageFill( $final_image, 0, 0, $white ); imagecopymerge( $final_image, $scratch_image, 0, 0, $box[6], $box[7], 300, 200, 100 ); imagecolortransparent( $final_image, $white ); imagedestroy( $scratch_image ); imagepng( $final_image, "testbug.png" ); Expected result: I expect the "testbug.png" file to show a "null" glyph (assuming the font doesn't have a glyph for U+186A0--I am using Code 2000 which has a wide range of Unicode characters, but not U+186A0.) Actual result: -- I see "𘚠" instead of the glyph. -- Edit this bug report at http://bugs.php.net/bug.php?id=51135&edit=1
Bug #51062 [Bgs]: DBA DB4 build uses mismatched headers & libraries
Edit report at http://bugs.php.net/bug.php?id=51062&edit=1 ID: 51062 Updated by: s...@php.net Reported by: seanius at debian dot org -Summary: test failures in ext/dba +Summary: DBA DB4 build uses mismatched headers & libraries Status: Bogus Type: Bug Package: DBM/DBA related Operating System: Debian PHP Version: 5.3.1 Assigned To: sixd New Comment: I added DB 4.7 & DB 4.8 to the autodetect list in config.m4 for PHP 5.2.14-dev, PHP 5.3.3-dev and PHP 6. This changes the default behavior and may help many cases. It certainly allowed DBA DB4 to work when I had 4.7 headers and 4.7 & 4.6 libraries, and built using "--with-db4". Without the change I saw the corrupted output you reported. Config.m4 still doesn't check the library version matches the header version. Previous Comments: [2010-02-19 08:57:34] seanius at debian dot org actually it's fairly common (at least on debian-derived systems, couldn't speak for others) to have multiple versions of libdb installed. The problem is that the code that does the testing of headers will match against a generic "db.h" and then will happily link against any other version of libdb that it finds (and it doesn't seem to be searching includes/libs in the same order). i'd argue that the configure detection ought to be a bit more thorough in this regard but won't press the point. [2010-02-19 08:46:22] j...@php.net -Status: Open +Status: Bogus No need for several reports on basically same issue, and regarding the header issues: That's nothing we can or will do about. If you mess your system with multiple libs and headers, that's your problem. [2010-02-17 22:40:04] seanius at debian dot org some more investigation reveals that the problem was caused by having db4.8 headers alongside db4.6 and db4.8 runtime libraries (i.e. having installed libdb4.6, libdb4.8, and libdv-dev (which is 4.8 in latest debian/ubuntu)). the build scripts find the the headers from the db4.8 package, and the 4.6 libraries since there is no code for testing for versions > 4.6. strangely enough it's able to build/link. having the libdb4.6 headers installed instead of the 4.8 headers removes the problem and the tests pass, but i would argue that this is still a bug. namely: * php doesn't support building against db4.8 (i could report a seperate bug about this if it's better) * php wrongly builds against headers for one version of libdb and links against another. [2010-02-16 21:52:06] seanius at debian dot org Description: Tested against the debian 5.3.1 packages as well as a recent 5.3 snapshot. fails on a variety of BE/LE and 32/64bit archs. note that the failure is different from the snapshot (Segfaults in some cases) and from 5.3.1 (various warnings about invalid parameters). i don't want to flood the description so i'll only include the 5.3 snapshot output here. = PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.3.3-dev ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64 INI actual : /home/sean/Download/php5.3-201002160730 More .INIs : CWD : /home/sean/Download/php5.3-201002160730 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/25 [ext/dba/tests/bug36436.phpt] DIFF 001+ DB->sync: method not permitted before handle's open method 002+ Segmentation fault 001- resource(%d) of type (dba persistent) 002- string(3) "XYZ" 003- string(1) "X" 004- string(1) "Y" 005- ===DONE=== DONE FAIL Bug #36436 (DBA problem with Berkeley DB4) [ext/dba/tests/bug36436.phpt] TEST 2/25 [ext/dba/tests/bug48240.phpt] DIFF 001+ DB->sync: method not permitted before handle's open method 002- ===DONE=== 003+ Segmentation fault DONE FAIL Bug #48240 (DBA Segmentation fault dba_nextkey) [ext/dba/tests/bug48240.phpt] TEST 3/25 [ext/dba/tests/bug49125.phpt] DIFF 001+ DB->sync: method not permitted before handle's open method 001- bool(true) 002+ Segmentation fault DONE FAIL Bug #49125 (Error in dba_exists C code) [ext/dba/tests/bug49125.phpt] PASS DBA File Creation Test [ext/dba/tests/dba001.phpt] PASS DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] PASS DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] PASS DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] PASS DBA FirstKey/NextKey Loop Test With 5
Bug #51062 [Bgs]: DBA DB4 build uses mismatched headers & libraries
Edit report at http://bugs.php.net/bug.php?id=51062&edit=1 ID: 51062 Updated by: s...@php.net Reported by: seanius at debian dot org Summary: DBA DB4 build uses mismatched headers & libraries Status: Bogus Type: Bug Package: DBM/DBA related Operating System: Debian PHP Version: 5.3.1 Assigned To: sixd New Comment: The change is in: http://svn.php.net/viewvc?view=revision&revision=295844 Previous Comments: [2010-03-05 06:39:12] s...@php.net I added DB 4.7 & DB 4.8 to the autodetect list in config.m4 for PHP 5.2.14-dev, PHP 5.3.3-dev and PHP 6. This changes the default behavior and may help many cases. It certainly allowed DBA DB4 to work when I had 4.7 headers and 4.7 & 4.6 libraries, and built using "--with-db4". Without the change I saw the corrupted output you reported. Config.m4 still doesn't check the library version matches the header version. [2010-02-19 08:57:34] seanius at debian dot org actually it's fairly common (at least on debian-derived systems, couldn't speak for others) to have multiple versions of libdb installed. The problem is that the code that does the testing of headers will match against a generic "db.h" and then will happily link against any other version of libdb that it finds (and it doesn't seem to be searching includes/libs in the same order). i'd argue that the configure detection ought to be a bit more thorough in this regard but won't press the point. [2010-02-19 08:46:22] j...@php.net -Status: Open +Status: Bogus No need for several reports on basically same issue, and regarding the header issues: That's nothing we can or will do about. If you mess your system with multiple libs and headers, that's your problem. [2010-02-17 22:40:04] seanius at debian dot org some more investigation reveals that the problem was caused by having db4.8 headers alongside db4.6 and db4.8 runtime libraries (i.e. having installed libdb4.6, libdb4.8, and libdv-dev (which is 4.8 in latest debian/ubuntu)). the build scripts find the the headers from the db4.8 package, and the 4.6 libraries since there is no code for testing for versions > 4.6. strangely enough it's able to build/link. having the libdb4.6 headers installed instead of the 4.8 headers removes the problem and the tests pass, but i would argue that this is still a bug. namely: * php doesn't support building against db4.8 (i could report a seperate bug about this if it's better) * php wrongly builds against headers for one version of libdb and links against another. [2010-02-16 21:52:06] seanius at debian dot org Description: Tested against the debian 5.3.1 packages as well as a recent 5.3 snapshot. fails on a variety of BE/LE and 32/64bit archs. note that the failure is different from the snapshot (Segfaults in some cases) and from 5.3.1 (various warnings about invalid parameters). i don't want to flood the description so i'll only include the 5.3 snapshot output here. = PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.3.3-dev ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 22:40:40 UTC 2010 x86_64 INI actual : /home/sean/Download/php5.3-201002160730 More .INIs : CWD : /home/sean/Download/php5.3-201002160730 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/25 [ext/dba/tests/bug36436.phpt] DIFF 001+ DB->sync: method not permitted before handle's open method 002+ Segmentation fault 001- resource(%d) of type (dba persistent) 002- string(3) "XYZ" 003- string(1) "X" 004- string(1) "Y" 005- ===DONE=== DONE FAIL Bug #36436 (DBA problem with Berkeley DB4) [ext/dba/tests/bug36436.phpt] TEST 2/25 [ext/dba/tests/bug48240.phpt] DIFF 001+ DB->sync: method not permitted before handle's open method 002- ===DONE=== 003+ Segmentation fault DONE FAIL Bug #48240 (DBA Segmentation fault dba_nextkey) [ext/dba/tests/bug48240.phpt] TEST 3/25 [ext/dba/tests/bug49125.phpt] DIFF 001+ DB->sync: method not permitted before handle's open method 001- bool(true) 002+ Segmentation fault DONE FAIL Bug #49125 (Error in dba_exists C code) [ext/dba/tests/bug49125.phpt] PASS DBA File Creation Test [ext/dba/tests/dba001.phpt] PASS DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] PASS DBA Insert/Replace/Fetch Test
Bug #51086 [Asn->Csd]: will not work with libdb4.8
Edit report at http://bugs.php.net/bug.php?id=51086&edit=1 ID: 51086 Updated by: s...@php.net Reported by: seanius at debian dot org Summary: will not work with libdb4.8 -Status: Assigned +Status: Closed Type: Bug Package: DBM/DBA related Operating System: * PHP Version: 5.3, 6 (2010-02-19) Assigned To: sixd New Comment: The next patchset of Berkeley DB 4.8 will possibly have the root cause fixed and the undefined behavior that DBA was depending on reverted. In the meantime I've merged a fix and a workaround to PHP 5.2.14-dev, PHP 5.2.3-dev and PHP 6.0. Note: now when using Berkely DB 4.8 prior or equal to 4.8.26, the workaround causes a message regarding meta data to be suppressed when opening the database. This causes a diff in a few cases where that message was previously displayed in DB 4.7, but prevents the message incorrectly displaying in all other tests. Previous Comments: [2010-03-05 07:45:30] s...@php.net Automatic comment from SVN on behalf of sixd Revision: http://svn.php.net/viewvc/?view=revision&revision=295847 Log: Fixed bug #51086 (DBA DB4 doesn't work with Berkeley DB 4.8) [2010-03-02 17:12:03] s...@php.net The Berkeley DB developers are reviewing this. [2010-02-19 09:05:25] seanius at debian dot org -Summary: will not build/work with libdb4.8 +Summary: will not work with libdb4.8 -Operating System: Debian (and others) +Operating System: * -PHP Version: 5.3.1 +PHP Version: 5.3, 6 (2010-02-19 heh, seems we're stepping on each other's toes now. i'll set the stuff back that i just clobbered, and promise to be quiet for a few hours :) actually it won't build correctly against db4.8. i had to modify the snapshot to link against db4.8, as otherwise you see http://bugs.php.net/bug.php?id=51062 , though apparently that's a bogus issue, hrm... :) [2010-02-19 09:00:54] seanius at debian dot org -Summary: will not work with libdb4.8 +Summary: will not build/work with libdb4.8 -Operating System: * +Operating System: Debian (and others) -PHP Version: 5.3, 6 (2010-02-19) +PHP Version: 5.3.1 sorry for all the noise, when trying the latest snapshot it apparently unpacked on top of a previous snapshot in which i had been investigating the issue. the tests fail in the new snapshot with more than just the NOTICE error (i had been playing with the open flags as mentioned previously). the actual failure diff looks like: TEST 1/25 [ext/dba/tests/bug36436.phpt] DIFF 001+ Notice: dba_popen(): fop_read_meta: /home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm: unexpected file type or format in /home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on line 6 002+ 003+ Notice: dba_popen(): /home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm: Invalid type 5 specified in /home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on line 6 004+ 005+ Warning: dba_popen(/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm,c): Driver initialization failed for handler: db4: Invalid argument in /home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on line 6 001- resource(%d) of type (dba persistent) 002- string(3) "XYZ" 003- string(1) "X" 004- string(1) "Y" 005- ===DONE=== [2010-02-19 08:45:00] j...@php.net -Summary: will not build/work with libdb4.8 +Summary: will not work with libdb4.8 -Operating System: Debian (and others) +Operating System: * -PHP Version: 5.3.1 +PHP Version: 5.3, 6 (2010-02-19) At least it builds now. :) 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=51086 -- Edit this bug report at http://bugs.php.net/bug.php?id=51086&edit=1
Req #51202 [Opn]: use oci8 result with smarty
Edit report at http://bugs.php.net/bug.php?id=51202&edit=1
ID: 51202
Updated by: s...@php.net
Reported by: houssam dot asaad at hiast dot edu dot sy
Summary: use oci8 result with smarty
Status: Open
Type: Feature/Change Request
Package: OCI8 related
Operating System: Win
PHP Version: 5.3.1
Assigned To: sixd
New Comment:
oci_fetch_array() only returns one row. It's called "array" because the
column
values for that row are stored in an array. See
http://www.php.net/manual/en/function.oci-fetch-array.php
Try oci_fetch_all():
http://www.php.net/manual/en/function.oci-fetch-all.php
Previous Comments:
[2010-03-04 15:41:22] houssam dot asaad at hiast dot edu dot sy
Description:
Hi
I use oci8 php file to connect with oracle db like this:
then, I use smarty file to display data
I would like to use smarty file to display array data
i got only one record with foreach statment (my table contains many
records)
Test script:
---
in php file:
$conn = oci_connect('username', 'passwd', ip-server/My_db');
$query = 'select * from my_table';
$stid = oci_parse($conn, $query);
oci_execute($stid, OCI_DEFAULT);
$row = oci_fetch_array($stid, OCI_ASSOC);
in smarty file:
{foreach from=$row item=soso}
{foreach from=$soso item=fofo}
{$fofo}
{/foreach}
{/foreach}
Actual result:
--
10359 4 1 14-JAN-10 119 2010 5
--
Edit this bug report at http://bugs.php.net/bug.php?id=51202&edit=1
Req #51202 [Asn->Bgs]: use oci8 result with smarty
Edit report at http://bugs.php.net/bug.php?id=51202&edit=1
ID: 51202
Updated by: s...@php.net
Reported by: houssam dot asaad at hiast dot edu dot sy
Summary: use oci8 result with smarty
-Status: Assigned
+Status: Bogus
Type: Feature/Change Request
Package: OCI8 related
Operating System: Win
PHP Version: 5.3.1
Assigned To: sixd
New Comment:
.
Previous Comments:
[2010-03-05 08:03:18] s...@php.net
oci_fetch_array() only returns one row. It's called "array" because the
column
values for that row are stored in an array. See
http://www.php.net/manual/en/function.oci-fetch-array.php
Try oci_fetch_all():
http://www.php.net/manual/en/function.oci-fetch-all.php
[2010-03-04 15:41:22] houssam dot asaad at hiast dot edu dot sy
Description:
Hi
I use oci8 php file to connect with oracle db like this:
then, I use smarty file to display data
I would like to use smarty file to display array data
i got only one record with foreach statment (my table contains many
records)
Test script:
---
in php file:
$conn = oci_connect('username', 'passwd', ip-server/My_db');
$query = 'select * from my_table';
$stid = oci_parse($conn, $query);
oci_execute($stid, OCI_DEFAULT);
$row = oci_fetch_array($stid, OCI_ASSOC);
in smarty file:
{foreach from=$row item=soso}
{foreach from=$soso item=fofo}
{$fofo}
{/foreach}
{/foreach}
Actual result:
--
10359 4 1 14-JAN-10 119 2010 5
--
Edit this bug report at http://bugs.php.net/bug.php?id=51202&edit=1
Bug #51196 [Opn->Fbk]: SQLT_INT or OCI_B_INT not binding correctly
Edit report at http://bugs.php.net/bug.php?id=51196&edit=1 ID: 51196 Updated by: s...@php.net Reported by: joel at layers dot com Summary: SQLT_INT or OCI_B_INT not binding correctly -Status: Open +Status: Feedback Type: Bug Package: OCI8 related Operating System: linux 2.6.21.7-2.fc8xen PHP Version: 5.3.1 New Comment: 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. Previous Comments: [2010-03-03 14:12:13] joel at layers dot com 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; [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] Bug #51211 [NEW]: phpinfo() crashes on 5.3.2 (tested final release)
From: Operating system: WinXP/2003 PHP version: 5.3.2RC3 Package: Unknown/Other Function Bug Type: Bug Bug description:phpinfo() crashes on 5.3.2 (tested final release) Description: i just tried to open phpinfo(); .. and apache crashed tested as apache module and as fcgi when php is used as apache_module a small part of phpinfo is shown until the "date" infoblock appears then php/apache crashes With PHP 5.3.1 everything works fine. Test script: --- Expected result: A full phpinfo page without crashing Actual result: -- php crashes -- Edit bug report at http://bugs.php.net/bug.php?id=51211&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51211&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51211&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51211&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51211&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51211&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51211&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51211&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51211&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51211&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51211&r=support Expected behavior: http://bugs.php.net/fix.php?id=51211&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51211&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51211&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51211&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51211&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51211&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51211&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51211&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51211&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51211&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51211&r=mysqlcfg
Bug #51211 [Opn->Fbk]: phpinfo() crashes on 5.3.2 (tested final release)
Edit report at http://bugs.php.net/bug.php?id=51211&edit=1 ID: 51211 Updated by: ahar...@php.net Reported by: lubbers_corrado at yahoo dot com Summary: phpinfo() crashes on 5.3.2 (tested final release) -Status: Open +Status: Feedback Type: Bug Package: Unknown/Other Function Operating System: WinXP/2003 PHP Version: 5.3.2RC3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2010-03-05 08:21:42] lubbers_corrado at yahoo dot com Description: i just tried to open phpinfo(); .. and apache crashed tested as apache module and as fcgi when php is used as apache_module a small part of phpinfo is shown until the "date" infoblock appears then php/apache crashes With PHP 5.3.1 everything works fine. Test script: --- Expected result: A full phpinfo page without crashing Actual result: -- php crashes -- Edit this bug report at http://bugs.php.net/bug.php?id=51211&edit=1
Bug #51211 [Fbk->Csd]: phpinfo() crashes on 5.3.2 (tested final release)
Edit report at http://bugs.php.net/bug.php?id=51211&edit=1 ID: 51211 User updated by: lubbers_corrado at yahoo dot com Reported by: lubbers_corrado at yahoo dot com Summary: phpinfo() crashes on 5.3.2 (tested final release) -Status: Feedback +Status: Closed Type: Bug Package: Reproducible crash Operating System: WinXP/2003 PHP Version: 5.3.2RC3 New Comment: my fault...i still used an incompatible version of eaccelerator which caused the crash. Previous Comments: [2010-03-05 08:26:02] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2010-03-05 08:21:42] lubbers_corrado at yahoo dot com Description: i just tried to open phpinfo(); .. and apache crashed tested as apache module and as fcgi when php is used as apache_module a small part of phpinfo is shown until the "date" infoblock appears then php/apache crashes With PHP 5.3.1 everything works fine. Test script: --- Expected result: A full phpinfo page without crashing Actual result: -- php crashes -- Edit this bug report at http://bugs.php.net/bug.php?id=51211&edit=1
