#48847 [NEW]: debug_backtrace doesn't reference arguments in stack in some cases
From: an0nym at narod dot ru Operating system: * PHP version: 5.3.0 PHP Bug Type: Unknown/Other Function Bug description: debug_backtrace doesn't reference arguments in stack in some cases Description: When argument of function or method is defined with type declaration and default value and is called with some value of this argument, debug_backtrace() doesn't reference this argument of function in stack. When function definition is the same except argument doesn't have default value, everything goes normal. Reproduce code: --- Expected result: bool(false) bool(true) bool(false) bool(true) Actual result: -- bool(false) bool(true) bool(true) bool(false) -- Edit bug report at http://bugs.php.net/?id=48847&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48847&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48847&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48847&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48847&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48847&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48847&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48847&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48847&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48847&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48847&r=support Expected behavior: http://bugs.php.net/fix.php?id=48847&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48847&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48847&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48847&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48847&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48847&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48847&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48847&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48847&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48847&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48847&r=mysqlcfg
#48848 [NEW]: Neater insertion of PHP variables in HTML
From: tcjohans at riseup dot net
Operating system: Windows Vista
PHP version: 5.2.10
PHP Bug Type: Feature/Change Request
Bug description: Neater insertion of PHP variables in HTML
Description:
Hello,
Here is an idea of how to facilitate the interaction between PHP and HTML
code. Much of this interaction just has to do with the insertion of the
value of a previously defined PHP variable into the HTML document.
Currently, this is done through a rather roundabout coding:
This snippet contains 28 characters, i.e. 16 more than the 12 of the
variable name. Could it be put neater and more economical?
I think so. I would propose a shorter format:
A simple prefix that simply just tells PHP that what immediately follows
is a PHP variable whose value should be inserted into the HTML document,
but that in all other regards this is just HTML code.
There should also be a closing suffix (but this is perhaps mostly to give
an aesthetically balanced coding.)
E.g. a prefix like "<$php:" and a suffix like ">" (or whatever), so that
one could just write something like
<$php:somevariable>
in the HTML code in order to have the value of $somevariable to be
inserted there.
The 28 characters of the usual way has now become just 19 characters. And
the whole snippet is much more concise and clearer: it gives a neater
appearance within the surrounding HTML code, which facilitates for the
developer/designer.
This would simply be so much more economic and neater than the usual way.
The idea can be extended:
For instance, in order to call a function somewhere in a piece of HTML
code, one might perhaps do something like this:
Thomas
Reproduce code:
---
This is some HTML text.
Followed by:
<$php:greeting>
<$php:goodbye("world")>
End
Expected result:
This is some HTML text.
Followed by:
Hello World!
Goodbye world!
End
--
Edit bug report at http://bugs.php.net/?id=48848&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48848&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48848&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48848&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48848&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48848&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48848&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48848&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48848&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48848&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48848&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48848&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48848&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48848&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48848&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48848&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48848&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48848&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48848&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48848&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48848&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48848&r=mysqlcfg
#48848 [Opn->Bgs]: Neater insertion of PHP variables in HTML
ID: 48848
Updated by: der...@php.net
Reported By: tcjohans at riseup dot net
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows Vista
PHP Version: 5.2.10
New Comment:
Uhm, are you not aware that we have this already in the form of:
Previous Comments:
[2009-07-08 08:02:20] tcjohans at riseup dot net
Description:
Hello,
Here is an idea of how to facilitate the interaction between PHP and
HTML code. Much of this interaction just has to do with the insertion of
the value of a previously defined PHP variable into the HTML document.
Currently, this is done through a rather roundabout coding:
This snippet contains 28 characters, i.e. 16 more than the 12 of the
variable name. Could it be put neater and more economical?
I think so. I would propose a shorter format:
A simple prefix that simply just tells PHP that what immediately
follows is a PHP variable whose value should be inserted into the HTML
document, but that in all other regards this is just HTML code.
There should also be a closing suffix (but this is perhaps mostly to
give an aesthetically balanced coding.)
E.g. a prefix like "<$php:" and a suffix like ">" (or whatever), so
that one could just write something like
<$php:somevariable>
in the HTML code in order to have the value of $somevariable to be
inserted there.
The 28 characters of the usual way has now become just 19 characters.
And the whole snippet is much more concise and clearer: it gives a
neater appearance within the surrounding HTML code, which facilitates
for the developer/designer.
This would simply be so much more economic and neater than the usual
way.
The idea can be extended:
For instance, in order to call a function somewhere in a piece of HTML
code, one might perhaps do something like this:
Thomas
Reproduce code:
---
This is some HTML text.
Followed by:
<$php:greeting>
<$php:goodbye("world")>
End
Expected result:
This is some HTML text.
Followed by:
Hello World!
Goodbye world!
End
--
Edit this bug report at http://bugs.php.net/?id=48848&edit=1
#48849 [NEW]: php5_module unable catch exception
From: caotao1570 at gmail dot com
Operating system: linux
PHP version: 5.2CVS-2009-07-08 (snap)
PHP Bug Type: Apache2 related
Bug description: php5_module unable catch exception
Description:
php5_module unable catch exception
½á¹û´íÎó
php 5.2.6
ÔÚÃüÁîÐÐÏÂÔËÐÐûÓÐÎÊÌ⣬µ«ÊÇÔÚapache2ϾÍÓÐÎÊÌâÁË
Reproduce code:
---
try
{
throw new Exception("ex");
for($i=0;$i<1;$i++)
{
}
}catch(Exception $e)
{
echo "Exception\n";
return ;
}
echo "end\n";
Expected result:
not echo "Exception"
if:
--
try
{
throw new Exception("ex");
}catch(Exception $e)
{
echo "Exception\n";
return ;
}
echo "end\n";
cho "Exception"
Actual result:
--
echo "Exception"
--
Edit bug report at http://bugs.php.net/?id=48849&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48849&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48849&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48849&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48849&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48849&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48849&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48849&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48849&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48849&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48849&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48849&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48849&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48849&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48849&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48849&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48849&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48849&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48849&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48849&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48849&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48849&r=mysqlcfg
#48834 [Opn->Asn]: DateTime should also use locales
ID: 48834
Updated by: der...@php.net
Reported By: sparky89 at gmx dot de
-Status: Open
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: Debian
PHP Version: 5.2.10
-Assigned To:
+Assigned To: derick
New Comment:
This is indeed planned for PHP 6, where there is an experimental
function "date_format_locale()" alreadyâbut that is bound to change.
Previous Comments:
[2009-07-07 12:41:59] sparky89 at gmx dot de
Description:
as of 5.2 there are features of DateTime class.
http://de.php.net/datetime
Im asking myself at the moment, why it does not look up locales. It is
somehow stupid to use datetime, convert it to timestamp just to get an
output of the month for any language, assuming strftime to convert the
timestamp.
I hope this will be changed.
Reproduce code:
---
';
$date1 = new DateTime('2009-07-07 13:20:12');
setlocale(LC_ALL, 'German');
var_dump(strftime('%A', $date1->format('U')));
var_dump($date1->format('l'));
setlocale(LC_ALL, 'English');
var_dump(strftime('%A', $date1->getTimestamp()));
var_dump($date1->format('l'));
echo '';
highlight_file(__FILE__);
?>
Expected result:
string(8) "Dienstag"
string(7) "Dienstag"
string(7) "Tuesday"
string(7) "Tuesday"
Actual result:
--
string(8) "Dienstag"
string(7) "Tuesday"
string(7) "Tuesday"
string(7) "Tuesday"
--
Edit this bug report at http://bugs.php.net/?id=48834&edit=1
#48851 [NEW]: calling setcookie with "invalid time value" causes high load for apache process
From: stephan dot schulze at kapthon dot com
Operating system: Centos 5.3
PHP version: 5.2.10
PHP Bug Type: Apache2 related
Bug description: calling setcookie with "invalid time value" causes high load
for apache process
Description:
If you call setcookie with an invalid time value causes high load for the
calling apache process
Reproduce code:
---
setcookie("SessionID", $S, time() . 15768000, "/");
Expected result:
Cookie is set and there should be no load for the apache process
Actual result:
--
Cookie is set and there is a load of 100% for the apache process
--
Edit bug report at http://bugs.php.net/?id=48851&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48851&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48851&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48851&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48851&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48851&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48851&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48851&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48851&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48851&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48851&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48851&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48851&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48851&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48851&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48851&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48851&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48851&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48851&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48851&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48851&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48851&r=mysqlcfg
#48845 [Opn->Bgs]: dl is incorrect disabled in CGI context
ID: 48845
Updated by: paj...@php.net
Reported By: pkwan at advsofteng dot net
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 5.3.0
New Comment:
Do not report twice the same bug.
Previous Comments:
[2009-07-08 06:51:58] pkwan at advsofteng dot net
Description:
According to the PHP documentation, the "dl" function is deprecated,
but not disabled. So it should continue to work. However, it is disabled
if the PHP is run in CGI context.
The followings are the supporting documentation as published in
http://www.php.net/dl
- 5.3.0 This function now throws an E_DEPRECATED notice on all sapi's
except for CLI, CGI and Embed.
- As of PHP 5, the dl() function is deprecated in every SAPI except
CLI.
Use Extension Loading Directives method instead.
- Since PHP 6 this function is disabled in all SAPIs, except CLI, CGI
and embed.
The above means "dl" is disabled in some SAPI only starting from PHP 6.
Even in PHP 6, "dl" should continue to work in CLI, CGI and embed.
In PHP 5, "dl" is deprecated but not disabled. It should work in CLI,
CGI, Embed, and at most throws a E_DEPRECATED notice in other SAPI.
In practice, "dl" does not work in CGI, and no E_DEPRECATED notice is
throw in any case. After some trouble-shooting, the code that causes the
problem is (located in cgi_main.c):
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
The "cgi-main.c" detects that it is actually run as CGI (by detecting
the server environmental variables), it will disables the "dl" function
in CGI usage, conflicting with the documentation.
Reproduce code:
---
NOTE : You can reproduce the problem by actually using php-cgi
in CGI. You cannot reproduce the problem if you just run php-cgi from
the command line. The php-cgi will check for the server environmental
variables to detect if it is actually running as CGI, and will disable
"dl" only if it is actually running as CGI.
Expected result:
If the above code is executed in CGI, no error message is expected.
Actual result:
--
Fatal error: Call to undefined function dl() in
C:\Inetpub\Scripts\phpinfo.php on line 1
--
Edit this bug report at http://bugs.php.net/?id=48845&edit=1
#48839 [Bgs->Tbd]: dl is incorrect disabled instead of deprecated
ID: 48839
Updated by: paj...@php.net
Reported By: pkwan at advsofteng dot net
-Status: Bogus
+Status: To be documented
Bug Type: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.3.0
New Comment:
moved this bug as a doc bug.
Previous Comments:
[2009-07-08 06:36:27] pkwan at advsofteng dot net
But you are using php-cgi in the command line, not as a CGI.
If you actually used php-cgi as a CGI, the code in "cgi_main.c" will
detect that it is used as a CGI (by checking the CGI environmental
variables), and disables "dl". This is done by the following code in
"cgi_main.c".
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
[2009-07-08 00:05:43] paj...@php.net
I'm not sure what you are using but dl works with cgi:
C:\php530>php-cgi.exe t.php
X-Powered-By: PHP/5.3.0
Content-type: text/html
Warning: dl() [function.dl]: Unable
to load dynamic library 'C:\php5\any_name.dll' - T
he specified module could not be found.
in C:\\t.php on line 1
[2009-07-07 18:49:57] pkwan at advsofteng dot net
Description:
According to the PHP documentation, the "dl" function is deprecated,
but not disabled. So it should continue to work. The followings are the
supporting documentation as published in http://www.php.net/dl
- 5.3.0 This function now throws an E_DEPRECATED notice on all sapi's
except for CLI, CGI and Embed.
- As of PHP 5, the dl() function is deprecated in every SAPI except
CLI. Use Extension Loading Directives method instead.
- Since PHP 6 this function is disabled in all SAPIs, except CLI, CGI
and embed.
The above means "dl" is disabled in some SAPI only starting from PHP 6.
Even in PHP 6, "dl" should continue to work in CLI, CGI and embed.
In PHP 5, "dl" is deprecated but not disabled. It should work in CLI,
CGI, Embed, and at most throws a E_DEPRECATED notice in other SAPI.
In practice, "dl" does not work in CGI, and no E_DEPRECATED notice is
throw in any case. After some trouble-shooting, the code that causes the
problem is (located in cgi_main.c):
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
The above disables the "dl" function in CGI usage, conflicting with the
documentation.
Reproduce code:
---
Expected result:
If the above code is executed in CGI, no error message is expected.
Actual result:
--
Fatal error: Call to undefined function dl() in
C:\Inetpub\Scripts\phpinfo.php on line 1
--
Edit this bug report at http://bugs.php.net/?id=48839&edit=1
#48845 [Bgs]: dl is incorrect disabled in CGI context
ID: 48845
User updated by: pkwan at advsofteng dot net
Reported By: pkwan at advsofteng dot net
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 5.3.0
New Comment:
Sorry about reporting the bug again. But in the previous report, the
developer reviewing it is using incorrect test method and cannot
reproduce the problem, and then he marked the bug as Bogus, and there is
no way I can re-open it. So I submitted again and included the correct
test method to reproduce the problem.
Previous Comments:
[2009-07-08 09:20:32] paj...@php.net
Do not report twice the same bug.
[2009-07-08 06:51:58] pkwan at advsofteng dot net
Description:
According to the PHP documentation, the "dl" function is deprecated,
but not disabled. So it should continue to work. However, it is disabled
if the PHP is run in CGI context.
The followings are the supporting documentation as published in
http://www.php.net/dl
- 5.3.0 This function now throws an E_DEPRECATED notice on all sapi's
except for CLI, CGI and Embed.
- As of PHP 5, the dl() function is deprecated in every SAPI except
CLI.
Use Extension Loading Directives method instead.
- Since PHP 6 this function is disabled in all SAPIs, except CLI, CGI
and embed.
The above means "dl" is disabled in some SAPI only starting from PHP 6.
Even in PHP 6, "dl" should continue to work in CLI, CGI and embed.
In PHP 5, "dl" is deprecated but not disabled. It should work in CLI,
CGI, Embed, and at most throws a E_DEPRECATED notice in other SAPI.
In practice, "dl" does not work in CGI, and no E_DEPRECATED notice is
throw in any case. After some trouble-shooting, the code that causes the
problem is (located in cgi_main.c):
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
The "cgi-main.c" detects that it is actually run as CGI (by detecting
the server environmental variables), it will disables the "dl" function
in CGI usage, conflicting with the documentation.
Reproduce code:
---
NOTE : You can reproduce the problem by actually using php-cgi
in CGI. You cannot reproduce the problem if you just run php-cgi from
the command line. The php-cgi will check for the server environmental
variables to detect if it is actually running as CGI, and will disable
"dl" only if it is actually running as CGI.
Expected result:
If the above code is executed in CGI, no error message is expected.
Actual result:
--
Fatal error: Call to undefined function dl() in
C:\Inetpub\Scripts\phpinfo.php on line 1
--
Edit this bug report at http://bugs.php.net/?id=48845&edit=1
#48848 [Bgs]: Neater insertion of PHP variables in HTML
ID: 48848
User updated by: tcjohans at riseup dot net
Reported By: tcjohans at riseup dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows Vista
PHP Version: 5.2.10
New Comment:
Thank you for your reply, Derick.
I was not aware of that.
However, it appears that the tagging is available only if you
have control of the php.ini file and can set the short_open_tag setting.
Which creates a problem with portability of scripts and in any event
does not make these tags available to all. I just tried it in my script
and it did not work.
Previous Comments:
[2009-07-08 08:08:08] der...@php.net
Uhm, are you not aware that we have this already in the form of:
[2009-07-08 08:02:20] tcjohans at riseup dot net
Description:
Hello,
Here is an idea of how to facilitate the interaction between PHP and
HTML code. Much of this interaction just has to do with the insertion of
the value of a previously defined PHP variable into the HTML document.
Currently, this is done through a rather roundabout coding:
This snippet contains 28 characters, i.e. 16 more than the 12 of the
variable name. Could it be put neater and more economical?
I think so. I would propose a shorter format:
A simple prefix that simply just tells PHP that what immediately
follows is a PHP variable whose value should be inserted into the HTML
document, but that in all other regards this is just HTML code.
There should also be a closing suffix (but this is perhaps mostly to
give an aesthetically balanced coding.)
E.g. a prefix like "<$php:" and a suffix like ">" (or whatever), so
that one could just write something like
<$php:somevariable>
in the HTML code in order to have the value of $somevariable to be
inserted there.
The 28 characters of the usual way has now become just 19 characters.
And the whole snippet is much more concise and clearer: it gives a
neater appearance within the surrounding HTML code, which facilitates
for the developer/designer.
This would simply be so much more economic and neater than the usual
way.
The idea can be extended:
For instance, in order to call a function somewhere in a piece of HTML
code, one might perhaps do something like this:
Thomas
Reproduce code:
---
This is some HTML text.
Followed by:
<$php:greeting>
<$php:goodbye("world")>
End
Expected result:
This is some HTML text.
Followed by:
Hello World!
Goodbye world!
End
--
Edit this bug report at http://bugs.php.net/?id=48848&edit=1
#48848 [Bgs]: Neater insertion of PHP variables in HTML
ID: 48848
User updated by: tcjohans at riseup dot net
Reported By: tcjohans at riseup dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows Vista
PHP Version: 5.2.10
New Comment:
The PHP Manual says:
"Using short tags should be avoided when developing applications or
libraries that are meant for redistribution, or deployment on PHP
servers which are not under your control, because short tags may not be
supported on the target server. For portable, redistributable code, be
sure not to use short tags."
I think the request now becomes:
Short tags should be made available to all by enabling scripts to
dynamically set the ini settings for short tags in their scripts.
Thomas
PS! Do you really have to call this "bogus"??
Previous Comments:
[2009-07-08 10:19:32] tcjohans at riseup dot net
Thank you for your reply, Derick.
I was not aware of that.
However, it appears that the tagging is available only if you
have control of the php.ini file and can set the short_open_tag setting.
Which creates a problem with portability of scripts and in any event
does not make these tags available to all. I just tried it in my script
and it did not work.
[2009-07-08 08:08:08] der...@php.net
Uhm, are you not aware that we have this already in the form of:
[2009-07-08 08:02:20] tcjohans at riseup dot net
Description:
Hello,
Here is an idea of how to facilitate the interaction between PHP and
HTML code. Much of this interaction just has to do with the insertion of
the value of a previously defined PHP variable into the HTML document.
Currently, this is done through a rather roundabout coding:
This snippet contains 28 characters, i.e. 16 more than the 12 of the
variable name. Could it be put neater and more economical?
I think so. I would propose a shorter format:
A simple prefix that simply just tells PHP that what immediately
follows is a PHP variable whose value should be inserted into the HTML
document, but that in all other regards this is just HTML code.
There should also be a closing suffix (but this is perhaps mostly to
give an aesthetically balanced coding.)
E.g. a prefix like "<$php:" and a suffix like ">" (or whatever), so
that one could just write something like
<$php:somevariable>
in the HTML code in order to have the value of $somevariable to be
inserted there.
The 28 characters of the usual way has now become just 19 characters.
And the whole snippet is much more concise and clearer: it gives a
neater appearance within the surrounding HTML code, which facilitates
for the developer/designer.
This would simply be so much more economic and neater than the usual
way.
The idea can be extended:
For instance, in order to call a function somewhere in a piece of HTML
code, one might perhaps do something like this:
Thomas
Reproduce code:
---
This is some HTML text.
Followed by:
<$php:greeting>
<$php:goodbye("world")>
End
Expected result:
This is some HTML text.
Followed by:
Hello World!
Goodbye world!
End
--
Edit this bug report at http://bugs.php.net/?id=48848&edit=1
#48839 [Tbd]: dl is incorrect disabled instead of deprecated
ID: 48839
User updated by: pkwan at advsofteng dot net
Reported By: pkwan at advsofteng dot net
Status: To be documented
Bug Type: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.3.0
New Comment:
Are you sure you want it do be a doc bug?
CGI PHP will be very inefficient and has very poor performance without
"dl".
It is because in CGI, PHP needs to be restarted for every PHP request.
Without "dl", all extensions have to be defined in "php.ini". It means
PHP needs to load all extensions for every PHP request, even if the
extensions are not used by a script.
I would think it is reasonable to load extensions using "php.ini" for
the PHP Apache module, because PHP is only started once as an Apache
module. However, for CGI PHP, it is a poor design to load extensions
using "php.ini". Using "dl" is much more reasonable.
In my opinion, the original documentation to allow "dl" to be used for
"CLI" and "CGI" seems to be a good design.
Previous Comments:
[2009-07-08 09:21:21] paj...@php.net
moved this bug as a doc bug.
[2009-07-08 06:36:27] pkwan at advsofteng dot net
But you are using php-cgi in the command line, not as a CGI.
If you actually used php-cgi as a CGI, the code in "cgi_main.c" will
detect that it is used as a CGI (by checking the CGI environmental
variables), and disables "dl". This is done by the following code in
"cgi_main.c".
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
[2009-07-08 00:05:43] paj...@php.net
I'm not sure what you are using but dl works with cgi:
C:\php530>php-cgi.exe t.php
X-Powered-By: PHP/5.3.0
Content-type: text/html
Warning: dl() [function.dl]: Unable
to load dynamic library 'C:\php5\any_name.dll' - T
he specified module could not be found.
in C:\\t.php on line 1
[2009-07-07 18:49:57] pkwan at advsofteng dot net
Description:
According to the PHP documentation, the "dl" function is deprecated,
but not disabled. So it should continue to work. The followings are the
supporting documentation as published in http://www.php.net/dl
- 5.3.0 This function now throws an E_DEPRECATED notice on all sapi's
except for CLI, CGI and Embed.
- As of PHP 5, the dl() function is deprecated in every SAPI except
CLI. Use Extension Loading Directives method instead.
- Since PHP 6 this function is disabled in all SAPIs, except CLI, CGI
and embed.
The above means "dl" is disabled in some SAPI only starting from PHP 6.
Even in PHP 6, "dl" should continue to work in CLI, CGI and embed.
In PHP 5, "dl" is deprecated but not disabled. It should work in CLI,
CGI, Embed, and at most throws a E_DEPRECATED notice in other SAPI.
In practice, "dl" does not work in CGI, and no E_DEPRECATED notice is
throw in any case. After some trouble-shooting, the code that causes the
problem is (located in cgi_main.c):
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
The above disables the "dl" function in CGI usage, conflicting with the
documentation.
Reproduce code:
---
Expected result:
If the above code is executed in CGI, no error message is expected.
Actual result:
--
Fatal error: Call to undefined function dl() in
C:\Inetpub\Scripts\phpinfo.php on line 1
--
Edit this bug report at http://bugs.php.net/?id=48839&edit=1
#48839 [Tbd]: dl is incorrect disabled instead of deprecated
ID: 48839
Updated by: paj...@php.net
Reported By: pkwan at advsofteng dot net
Status: To be documented
Bug Type: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.3.0
New Comment:
Yes, I'm sure. There are reasons why it has been done (avoid crashes
being one of them). Also I don't see how performance can be affected by
the dl removal (using dl is slow) :)
Previous Comments:
[2009-07-08 10:37:28] pkwan at advsofteng dot net
Are you sure you want it do be a doc bug?
CGI PHP will be very inefficient and has very poor performance without
"dl".
It is because in CGI, PHP needs to be restarted for every PHP request.
Without "dl", all extensions have to be defined in "php.ini". It means
PHP needs to load all extensions for every PHP request, even if the
extensions are not used by a script.
I would think it is reasonable to load extensions using "php.ini" for
the PHP Apache module, because PHP is only started once as an Apache
module. However, for CGI PHP, it is a poor design to load extensions
using "php.ini". Using "dl" is much more reasonable.
In my opinion, the original documentation to allow "dl" to be used for
"CLI" and "CGI" seems to be a good design.
[2009-07-08 09:21:21] paj...@php.net
moved this bug as a doc bug.
[2009-07-08 06:36:27] pkwan at advsofteng dot net
But you are using php-cgi in the command line, not as a CGI.
If you actually used php-cgi as a CGI, the code in "cgi_main.c" will
detect that it is used as a CGI (by checking the CGI environmental
variables), and disables "dl". This is done by the following code in
"cgi_main.c".
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
[2009-07-08 00:05:43] paj...@php.net
I'm not sure what you are using but dl works with cgi:
C:\php530>php-cgi.exe t.php
X-Powered-By: PHP/5.3.0
Content-type: text/html
Warning: dl() [function.dl]: Unable
to load dynamic library 'C:\php5\any_name.dll' - T
he specified module could not be found.
in C:\\t.php on line 1
[2009-07-07 18:49:57] pkwan at advsofteng dot net
Description:
According to the PHP documentation, the "dl" function is deprecated,
but not disabled. So it should continue to work. The followings are the
supporting documentation as published in http://www.php.net/dl
- 5.3.0 This function now throws an E_DEPRECATED notice on all sapi's
except for CLI, CGI and Embed.
- As of PHP 5, the dl() function is deprecated in every SAPI except
CLI. Use Extension Loading Directives method instead.
- Since PHP 6 this function is disabled in all SAPIs, except CLI, CGI
and embed.
The above means "dl" is disabled in some SAPI only starting from PHP 6.
Even in PHP 6, "dl" should continue to work in CLI, CGI and embed.
In PHP 5, "dl" is deprecated but not disabled. It should work in CLI,
CGI, Embed, and at most throws a E_DEPRECATED notice in other SAPI.
In practice, "dl" does not work in CGI, and no E_DEPRECATED notice is
throw in any case. After some trouble-shooting, the code that causes the
problem is (located in cgi_main.c):
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
The above disables the "dl" function in CGI usage, conflicting with the
documentation.
Reproduce code:
---
Expected result:
If the above code is executed in CGI, no error message is expected.
Actual result:
--
Fatal error: Call to undefined function dl() in
C:\Inetpub\Scripts\phpinfo.php on line 1
--
Edit this bug report at http://bugs.php.net/?id=48839&edit=1
#48848 [Bgs]: Neater insertion of PHP variables in HTML
ID: 48848
User updated by: tcjohans at riseup dot net
Reported By: tcjohans at riseup dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows Vista
PHP Version: 5.2.10
New Comment:
Actually, using might be more efficient
performance-wise than the current short tag format .
With .
I.e. the parser would not operate with TWO different PHP start tags -
which I suppose slows down parsing -, but only ONE, tagging is available only if you
have control of the php.ini file and can set the short_open_tag setting.
Which creates a problem with portability of scripts and in any event
does not make these tags available to all. I just tried it in my script
and it did not work.
[2009-07-08 08:08:08] der...@php.net
Uhm, are you not aware that we have this already in the form of:
[2009-07-08 08:02:20] tcjohans at riseup dot net
Description:
Hello,
Here is an idea of how to facilitate the interaction between PHP and
HTML code. Much of this interaction just has to do with the insertion of
the value of a previously defined PHP variable into the HTML document.
Currently, this is done through a rather roundabout coding:
This snippet contains 28 characters, i.e. 16 more than the 12 of the
variable name. Could it be put neater and more economical?
I think so. I would propose a shorter format:
A simple prefix that simply just tells PHP that what immediately
follows is a PHP variable whose value should be inserted into the HTML
document, but that in all other regards this is just HTML code.
There should also be a closing suffix (but this is perhaps mostly to
give an aesthetically balanced coding.)
E.g. a prefix like "<$php:" and a suffix like ">" (or whatever), so
that one could just write something like
<$php:somevariable>
in the HTML code in order to have the value of $somevariable to be
inserted there.
The 28 characters of the usual way has now become just 19 characters.
And the whole snippet is much more concise and clearer: it gives a
neater appearance within the surrounding HTML code, which facilitates
for the developer/designer.
This would simply be so much more economic and neater than the usual
way.
The idea can be extended:
For instance, in order to call a function somewhere in a piece of HTML
code, one might perhaps do something like this:
Thomas
Reproduce code:
---
This is some HTML text.
Followed by:
<$php:greeting>
<$php:goodbye("world")>
End
Expected result:
This is some HTML text.
Followed by:
Hello World!
Goodbye world!
End
--
Edit this bug report at http://bugs.php.net/?id=48848&edit=1
#48839 [Tbd]: dl is incorrect disabled instead of deprecated
ID: 48839
User updated by: pkwan at advsofteng dot net
Reported By: pkwan at advsofteng dot net
Status: To be documented
Bug Type: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.3.0
New Comment:
Your point about the performance of "dl" is valid for PHP as an Apache
module. However, for CGI, the reverse is true. "dl" is much more
efficent than "php.ini".
If you have tested it in a real and typical CGI environment, you can
see that CGI PHP becomes very slow without "dl".
In a typical PHP environment, there may be around 10 to 20 extensions.
Without "dl", the extensions must be listed in "php.ini". It means the
CGI PHP must load all these 20 extensions running each PHP script
(remember, in CGI, the PHP is restarted for each request), even if a
typical PHP script only used none or a few extensions. This is the cause
of the slowness.
I know "dl" is slower than "php.ini" if PHP is an Apache module, but it
is much faster than the "php.ini" for if it is a CGI.
For the "avoidance of crash", may be you are correct, as I did not have
enough experience in "avoidance of crash". However, I suspect much of
the crashing problems is when PHP is when it is used as an Apache
module. It should be much more stable in CGI.
It is because CGI is never multi-threaded, and it is always used by one
script only. Remember in CGI, each script is handled by a separate PHP
process, which is only used once for that instance of the script. It is
hard to see why "dl" can be more crash prone than using "php.ini" in
CGI.
Finally, even if the PHP dies, it affects only that instance of the
script. For CGI, the PHP process will terminate anyone at the end of the
script. So it should not affect the stability of the system.
Previous Comments:
[2009-07-08 10:40:58] paj...@php.net
Yes, I'm sure. There are reasons why it has been done (avoid crashes
being one of them). Also I don't see how performance can be affected by
the dl removal (using dl is slow) :)
[2009-07-08 10:37:28] pkwan at advsofteng dot net
Are you sure you want it do be a doc bug?
CGI PHP will be very inefficient and has very poor performance without
"dl".
It is because in CGI, PHP needs to be restarted for every PHP request.
Without "dl", all extensions have to be defined in "php.ini". It means
PHP needs to load all extensions for every PHP request, even if the
extensions are not used by a script.
I would think it is reasonable to load extensions using "php.ini" for
the PHP Apache module, because PHP is only started once as an Apache
module. However, for CGI PHP, it is a poor design to load extensions
using "php.ini". Using "dl" is much more reasonable.
In my opinion, the original documentation to allow "dl" to be used for
"CLI" and "CGI" seems to be a good design.
[2009-07-08 09:21:21] paj...@php.net
moved this bug as a doc bug.
[2009-07-08 06:36:27] pkwan at advsofteng dot net
But you are using php-cgi in the command line, not as a CGI.
If you actually used php-cgi as a CGI, the code in "cgi_main.c" will
detect that it is used as a CGI (by checking the CGI environmental
variables), and disables "dl". This is done by the following code in
"cgi_main.c".
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
[2009-07-08 00:05:43] paj...@php.net
I'm not sure what you are using but dl works with cgi:
C:\php530>php-cgi.exe t.php
X-Powered-By: PHP/5.3.0
Content-type: text/html
Warning: dl() [function.dl]: Unable
to load dynamic library 'C:\php5\any_name.dll' - T
he specified module could not be found.
in C:\\t.php on line 1
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/48839
--
Edit this bug report at http://bugs.php.net/?id=48839&edit=1
#46224 [Com]: Cannot instantiate .Net object (ABCpdf 6.1 .Net)
ID: 46224
Comment by: p dot stankowski at transcomp dot pl
Reported By: mark at koalit dot dk
Status: Open
Bug Type: COM related
Operating System: Vista Business SP1 (da)
PHP Version: 5.2.6
New Comment:
.Net framework 3.5 installed. PHP version 2.3.0.
I have created class library in C# called TestLibrary.dll.
It has only one class:
namespace TestLibrary
{
public class Test
{
public string GetString() { return "Test passed"; }
}
}
Then signed it and added it to GAC. In C:\Windows\assembly I have found
all values needed:
Version: 1.0.0.0
Culture: Neutral
Public Key Token: c42df41937303b82
Script:
GetString());
?>
Expected result:
Test passed
Actual result:
PHP Fatal error: Uncaught exception 'com_exception' with message
'Failed to instantiate .Net object [CreateInstance] [0x80131047] ' in
C:\home\Projects\hi_1289_IT-ZEB-SERVER\trunk\src\PHPWithNETTest\index.php:10
Stack trace:
#0
C:\home\Projects\hi_1289_IT-ZEB-SERVER\trunk\src\PHPWithNETTest\index.php(10):
dotnet->dotnet('TestLibrary, Ve...', 'TestLibrary.Tes...')
#1 {main}
thrown in
C:\home\Projects\hi_1289_IT-ZEB-SERVER\trunk\src\PHPWithNETTest\index.php
on line 10
Previous Comments:
[2008-10-24 10:39:56] bj...@php.net
reclassified.
[2008-10-03 13:08:31] mark at koalit dot dk
Forgot to include PHP version (5.2.6)
[2008-10-03 13:07:10] mark at koalit dot dk
Description:
.Net framework version 3.5 (latest) is installed.
Installed a specific .Net component, but PHP fails to instantiate the
object.
The script is runnning from command line.
The standard example:
$stack = new DOTNET("mscorlib", "System.Collections.Stack");
$stack->Push(".Net");
$stack->Push("Hello ");
echo $stack->Pop() . $stack->Pop();
Works fine - returns "Hello .Net"
Seems like lot's of users have problems using .Net objects from PHP -
can you confirm this as a bug or is a local problem ?
Reproduce code:
---
$pdf = new DOTNET("Assembly=ABCpdf, Version=6.1.1.5, Culture=neutral,
PublicKeyToken=a7a0b3f5184f2169", "Websupergoo.ABCpdf6.Doc");
(needs to install ABCpdf 6.1 .Net from www.websupergoo.com)
Expected result:
nothing
Actual result:
--
PHP Fatal error : Uncaught exception 'com_exception' with message
'Failed to instantiate .Net object [CreateInstance] [0x80131047]' in
D:\dotnet\dotnet.php
Stack trace:
#0 (snip) dotnet->dotnet('Assembly=ABCpdf...',
'Websupergoo.ABCpdf6.Doc')
#1 {main}
thrown in D:\dotnet\dotnet.php
--
Edit this bug report at http://bugs.php.net/?id=46224&edit=1
#46224 [Com]: Cannot instantiate .Net object (ABCpdf 6.1 .Net)
ID: 46224
Comment by: p dot stankowski at transcomp dot pl
Reported By: mark at koalit dot dk
Status: Open
Bug Type: COM related
Operating System: Vista Business SP1 (da)
PHP Version: 5.2.6
New Comment:
Just had to replace:
"TestLibrary, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c42df41937303b82'"
with:
"TestLibrary, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=c42df41937303b82"
Sorry for spam, one sign "'" caused this error. Now the result is "Test
passed".
Previous Comments:
[2009-07-08 11:53:20] p dot stankowski at transcomp dot pl
.Net framework 3.5 installed. PHP version 2.3.0.
I have created class library in C# called TestLibrary.dll.
It has only one class:
namespace TestLibrary
{
public class Test
{
public string GetString() { return "Test passed"; }
}
}
Then signed it and added it to GAC. In C:\Windows\assembly I have found
all values needed:
Version: 1.0.0.0
Culture: Neutral
Public Key Token: c42df41937303b82
Script:
GetString());
?>
Expected result:
Test passed
Actual result:
PHP Fatal error: Uncaught exception 'com_exception' with message
'Failed to instantiate .Net object [CreateInstance] [0x80131047] ' in
C:\home\Projects\hi_1289_IT-ZEB-SERVER\trunk\src\PHPWithNETTest\index.php:10
Stack trace:
#0
C:\home\Projects\hi_1289_IT-ZEB-SERVER\trunk\src\PHPWithNETTest\index.php(10):
dotnet->dotnet('TestLibrary, Ve...', 'TestLibrary.Tes...')
#1 {main}
thrown in
C:\home\Projects\hi_1289_IT-ZEB-SERVER\trunk\src\PHPWithNETTest\index.php
on line 10
[2008-10-24 10:39:56] bj...@php.net
reclassified.
[2008-10-03 13:08:31] mark at koalit dot dk
Forgot to include PHP version (5.2.6)
[2008-10-03 13:07:10] mark at koalit dot dk
Description:
.Net framework version 3.5 (latest) is installed.
Installed a specific .Net component, but PHP fails to instantiate the
object.
The script is runnning from command line.
The standard example:
$stack = new DOTNET("mscorlib", "System.Collections.Stack");
$stack->Push(".Net");
$stack->Push("Hello ");
echo $stack->Pop() . $stack->Pop();
Works fine - returns "Hello .Net"
Seems like lot's of users have problems using .Net objects from PHP -
can you confirm this as a bug or is a local problem ?
Reproduce code:
---
$pdf = new DOTNET("Assembly=ABCpdf, Version=6.1.1.5, Culture=neutral,
PublicKeyToken=a7a0b3f5184f2169", "Websupergoo.ABCpdf6.Doc");
(needs to install ABCpdf 6.1 .Net from www.websupergoo.com)
Expected result:
nothing
Actual result:
--
PHP Fatal error : Uncaught exception 'com_exception' with message
'Failed to instantiate .Net object [CreateInstance] [0x80131047]' in
D:\dotnet\dotnet.php
Stack trace:
#0 (snip) dotnet->dotnet('Assembly=ABCpdf...',
'Websupergoo.ABCpdf6.Doc')
#1 {main}
thrown in D:\dotnet\dotnet.php
--
Edit this bug report at http://bugs.php.net/?id=46224&edit=1
#48852 [NEW]: php windows save file to remote share strange access denied
From: trutas dot ctx at gmail dot com Operating system: Windows Server 2003 x64 IIS6.0 PHP version: 5.3.0 PHP Bug Type: IIS related Bug description: php windows save file to remote share strange access denied Description: Access denied on a simple file_put_contents - the strange thing is vbscript test file on the same folder works - destination has everyone->modify/read/write. localhost/test.asp localhost/test.php i think it is not relevant but test.php and test.asp are located on the same \\share that we're trying to save the file to (but on a different folder). Apparently it works if we map this share to a local drive and use the local path (eg. E:\ ); file_get_contents works fine. We are using Windows 2003 Server x64, IIS 6.0, PHP 5.3RC04 x64 via MS FastCGI . Reproduce code: --- Expected result: file saved with content "..." Actual result: -- PHP Warning: file_put_contents(\\share\intraroot$\folder\file.txt): failed to open stream: Permission denied in ... -- Edit bug report at http://bugs.php.net/?id=48852&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48852&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48852&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48852&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48852&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48852&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48852&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48852&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48852&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48852&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48852&r=support Expected behavior: http://bugs.php.net/fix.php?id=48852&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48852&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48852&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48852&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48852&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48852&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48852&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48852&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48852&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48852&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48852&r=mysqlcfg
#48853 [NEW]: Using bundled pcre fails if no unbundled headers are available on the system
From: leonard-php-bugs at ottolander dot nl Operating system: CentOS-4 PHP version: 5.2CVS-2009-07-08 (CVS) PHP Bug Type: Compile Failure Bug description: Using bundled pcre fails if no unbundled headers are available on the system Description: Building 5.2.9 on CentOS-4, although later versions until CVS today are affected. The OS is not really relevant, just the reason there are no unbundled headers available as there's a version mismatch with the bundled headers. Using the bundled pcre library by not supplying any pcre configure options. When the unbundled (upgraded/matching) headers are available on the system the build succeeds. However, if no unbundled headers are available httpd.h cannot find the bundled pcreposix.h (and other headers). This is *not* an apache issue, the issue is a missing include path in the build. If you compare ext/pcre/config0.m4 an include path is provided in case of an external pcre (although on CentOS it will be found in /usr/include no matter if a path is specifically provided): if test "$PHP_PCRE_REGEX" != "no"; then if test "$PHP_PCRE_REGEX" = "yes"; then ... (no PHP_ADD_INCLUDE here) else ... PHP_ADD_INCLUDE($PCRE_INCDIR) ... fi Fix with this patch which provides the include path (ignore the line wraps, it's just a single line addition): --- php-5.2.9/ext/pcre/config0.m4.000 2008-12-29 16:27:11.0 +0100 +++ php-5.2.9/ext/pcre/config0.m4 2009-07-08 13:27:11.0 +0200 @@ -13,6 +13,7 @@ if test "$PHP_PCRE_REGEX" != "no"; then if test "$PHP_PCRE_REGEX" = "yes"; then PHP_NEW_EXTENSION(pcre, pcrelib/pcre_chartables.c pcrelib/pcre_ucd.c pcrelib/pcre_compile.c pcrelib/pcre_config.c pcrelib/pcre_exec.c pcrelib/pcre_fullinfo.c pcrelib/pcre_get.c pcrelib/pcre_globals.c pcrelib/pcre_info.c pcrelib/pcre_maketables.c pcrelib/pcre_newline.c pcrelib/pcre_ord2utf8.c pcrelib/pcre_refcount.c pcrelib/pcre_study.c pcrelib/pcre_tables.c pcrelib/pcre_try_flipped.c pcrelib/pcre_valid_utf8.c pcrelib/pcre_version.c pcrelib/pcre_xclass.c php_pcre.c, $ext_shared,,-...@ext_srcdir@/pcrelib) PHP_ADD_BUILD_DIR($ext_builddir/pcrelib) +PHP_ADD_INCLUDE([$ext_srcdir/pcrelib]) PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/]) AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ]) else Reproduce code: --- Make sure you REMOVE any unbundled pcre headers from the system. /usr/include is in the include path and thus the necessary unbundled headers will be found so you wont see the build fail. Configure without any pcre related options to use the bundled version. Expected result: Headers found, build succeeds. It does with the patch. Actual result: -- /bin/sh /usr/src/redhat/BUILD/php-5.2.9/build-apache/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/include/httpd -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-0 -I/usr/include/apr-0 -Isapi/apache2handler/ -I/usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/include -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/main -I/usr/src/redhat/BUILD/php-5.2.9 -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/ext/date/lib -I/usr/src/redhat/BUILD/php-5.2.9/ext/date/lib -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/TSRM -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/Zend -I/usr/src/redhat/BUILD/php-5.2.9/main -I/usr/src/redhat/BUILD/php-5.2.9/Zend -I/usr/src/redhat/BUILD/php-5.2.9/TSRM -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/-I/usr/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -fno-strict-aliasing -prefer-pic -c /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/php_apache.h:24, from /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26: /usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or directory make: *** [sapi/apache2handler/mod_php5.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=48853&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48853&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48853&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48853&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48853&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48853&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48853&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48853&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48853&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48853&r=oldversion Not developer issue:
#48852 [Opn->Fbk]: php windows save file to remote share strange access denied
ID: 48852 Updated by: paj...@php.net Reported By: trutas dot ctx at gmail dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: How did you install php? FCGI or ISAPI? Previous Comments: [2009-07-08 14:01:20] trutas dot ctx at gmail dot com Description: Access denied on a simple file_put_contents - the strange thing is vbscript test file on the same folder works - destination has everyone->modify/read/write. localhost/test.asp localhost/test.php i think it is not relevant but test.php and test.asp are located on the same \\share that we're trying to save the file to (but on a different folder). Apparently it works if we map this share to a local drive and use the local path (eg. E:\ ); file_get_contents works fine. We are using Windows 2003 Server x64, IIS 6.0, PHP 5.3RC04 x64 via MS FastCGI . Reproduce code: --- Expected result: file saved with content "..." Actual result: -- PHP Warning: file_put_contents(\\share\intraroot$\folder\file.txt): failed to open stream: Permission denied in ... -- Edit this bug report at http://bugs.php.net/?id=48852&edit=1
#48839 [Tbd]: dl is incorrect disabled instead of deprecated
ID: 48839
User updated by: pkwan at advsofteng dot net
Reported By: pkwan at advsofteng dot net
Status: To be documented
Bug Type: Scripting Engine problem
-Operating System: win32 only
+Operating System: All OS
PHP Version: 5.3.0
New Comment:
I would like to add that this problem is not win32 only, but affects
all OS. (I changed the OS field to "All OS".) As CGI is important for
non-Windows OS, so I think this issue is important.
Previous Comments:
[2009-07-08 11:20:45] pkwan at advsofteng dot net
Your point about the performance of "dl" is valid for PHP as an Apache
module. However, for CGI, the reverse is true. "dl" is much more
efficent than "php.ini".
If you have tested it in a real and typical CGI environment, you can
see that CGI PHP becomes very slow without "dl".
In a typical PHP environment, there may be around 10 to 20 extensions.
Without "dl", the extensions must be listed in "php.ini". It means the
CGI PHP must load all these 20 extensions running each PHP script
(remember, in CGI, the PHP is restarted for each request), even if a
typical PHP script only used none or a few extensions. This is the cause
of the slowness.
I know "dl" is slower than "php.ini" if PHP is an Apache module, but it
is much faster than the "php.ini" for if it is a CGI.
For the "avoidance of crash", may be you are correct, as I did not have
enough experience in "avoidance of crash". However, I suspect much of
the crashing problems is when PHP is when it is used as an Apache
module. It should be much more stable in CGI.
It is because CGI is never multi-threaded, and it is always used by one
script only. Remember in CGI, each script is handled by a separate PHP
process, which is only used once for that instance of the script. It is
hard to see why "dl" can be more crash prone than using "php.ini" in
CGI.
Finally, even if the PHP dies, it affects only that instance of the
script. For CGI, the PHP process will terminate anyone at the end of the
script. So it should not affect the stability of the system.
[2009-07-08 10:40:58] paj...@php.net
Yes, I'm sure. There are reasons why it has been done (avoid crashes
being one of them). Also I don't see how performance can be affected by
the dl removal (using dl is slow) :)
[2009-07-08 10:37:28] pkwan at advsofteng dot net
Are you sure you want it do be a doc bug?
CGI PHP will be very inefficient and has very poor performance without
"dl".
It is because in CGI, PHP needs to be restarted for every PHP request.
Without "dl", all extensions have to be defined in "php.ini". It means
PHP needs to load all extensions for every PHP request, even if the
extensions are not used by a script.
I would think it is reasonable to load extensions using "php.ini" for
the PHP Apache module, because PHP is only started once as an Apache
module. However, for CGI PHP, it is a poor design to load extensions
using "php.ini". Using "dl" is much more reasonable.
In my opinion, the original documentation to allow "dl" to be used for
"CLI" and "CGI" seems to be a good design.
[2009-07-08 09:21:21] paj...@php.net
moved this bug as a doc bug.
[2009-07-08 06:36:27] pkwan at advsofteng dot net
But you are using php-cgi in the command line, not as a CGI.
If you actually used php-cgi as a CGI, the code in "cgi_main.c" will
detect that it is used as a CGI (by checking the CGI environmental
variables), and disables "dl". This is done by the following code in
"cgi_main.c".
if (!cgi && !fastcgi && !bindpath) {
cgi_sapi_module.additional_functions = additional_functions;
}
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/48839
--
Edit this bug report at http://bugs.php.net/?id=48839&edit=1
#48852 [Fbk->Opn]: php windows save file to remote share strange access denied
ID: 48852 User updated by: trutas dot ctx at gmail dot com Reported By: trutas dot ctx at gmail dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: Note: test.php is located at \\share\intraroot$\site\ i've just tested it further and tryed a few workarounds: - it doesn't work with relative path (since both files are within the same share) "..\\folder\\file.txt"; - it doesn't work with dirname(__FILE__)."\\..\\folder\\file.txt"; - does not work with forward slashes //share/... - the error is "permission denied" even if the destination folder doesn't exist - i've found this because at a time i had wrongly typed share\\intraroot$folder\\file.txt - that does not exist; I'm guessing it has something to do with the home directory in IIS being on a remote share - the production servers are clustered... Every other technology (vbscript, .NET) on IIS accesses the shares normally. Previous Comments: [2009-07-08 15:03:05] paj...@php.net How did you install php? FCGI or ISAPI? [2009-07-08 14:01:20] trutas dot ctx at gmail dot com Description: Access denied on a simple file_put_contents - the strange thing is vbscript test file on the same folder works - destination has everyone->modify/read/write. localhost/test.asp localhost/test.php i think it is not relevant but test.php and test.asp are located on the same \\share that we're trying to save the file to (but on a different folder). Apparently it works if we map this share to a local drive and use the local path (eg. E:\ ); file_get_contents works fine. We are using Windows 2003 Server x64, IIS 6.0, PHP 5.3RC04 x64 via MS FastCGI . Reproduce code: --- Expected result: file saved with content "..." Actual result: -- PHP Warning: file_put_contents(\\share\intraroot$\folder\file.txt): failed to open stream: Permission denied in ... -- Edit this bug report at http://bugs.php.net/?id=48852&edit=1
#48852 [Opn]: php windows save file to remote share strange access denied
ID: 48852 User updated by: trutas dot ctx at gmail dot com Reported By: trutas dot ctx at gmail dot com Status: Open Bug Type: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: FastCGI Previous Comments: [2009-07-08 15:13:50] trutas dot ctx at gmail dot com Note: test.php is located at \\share\intraroot$\site\ i've just tested it further and tryed a few workarounds: - it doesn't work with relative path (since both files are within the same share) "..\\folder\\file.txt"; - it doesn't work with dirname(__FILE__)."\\..\\folder\\file.txt"; - does not work with forward slashes //share/... - the error is "permission denied" even if the destination folder doesn't exist - i've found this because at a time i had wrongly typed share\\intraroot$folder\\file.txt - that does not exist; I'm guessing it has something to do with the home directory in IIS being on a remote share - the production servers are clustered... Every other technology (vbscript, .NET) on IIS accesses the shares normally. [2009-07-08 15:03:05] paj...@php.net How did you install php? FCGI or ISAPI? [2009-07-08 14:01:20] trutas dot ctx at gmail dot com Description: Access denied on a simple file_put_contents - the strange thing is vbscript test file on the same folder works - destination has everyone->modify/read/write. localhost/test.asp localhost/test.php i think it is not relevant but test.php and test.asp are located on the same \\share that we're trying to save the file to (but on a different folder). Apparently it works if we map this share to a local drive and use the local path (eg. E:\ ); file_get_contents works fine. We are using Windows 2003 Server x64, IIS 6.0, PHP 5.3RC04 x64 via MS FastCGI . Reproduce code: --- Expected result: file saved with content "..." Actual result: -- PHP Warning: file_put_contents(\\share\intraroot$\folder\file.txt): failed to open stream: Permission denied in ... -- Edit this bug report at http://bugs.php.net/?id=48852&edit=1
#48852 [Opn->Fbk]: php windows save file to remote share strange access denied
ID: 48852 Updated by: paj...@php.net Reported By: trutas dot ctx at gmail dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: Be sure that you configured the user correctly or that the user has the correct access. Previous Comments: [2009-07-08 15:15:19] trutas dot ctx at gmail dot com FastCGI [2009-07-08 15:13:50] trutas dot ctx at gmail dot com Note: test.php is located at \\share\intraroot$\site\ i've just tested it further and tryed a few workarounds: - it doesn't work with relative path (since both files are within the same share) "..\\folder\\file.txt"; - it doesn't work with dirname(__FILE__)."\\..\\folder\\file.txt"; - does not work with forward slashes //share/... - the error is "permission denied" even if the destination folder doesn't exist - i've found this because at a time i had wrongly typed share\\intraroot$folder\\file.txt - that does not exist; I'm guessing it has something to do with the home directory in IIS being on a remote share - the production servers are clustered... Every other technology (vbscript, .NET) on IIS accesses the shares normally. [2009-07-08 15:03:05] paj...@php.net How did you install php? FCGI or ISAPI? [2009-07-08 14:01:20] trutas dot ctx at gmail dot com Description: Access denied on a simple file_put_contents - the strange thing is vbscript test file on the same folder works - destination has everyone->modify/read/write. localhost/test.asp localhost/test.php i think it is not relevant but test.php and test.asp are located on the same \\share that we're trying to save the file to (but on a different folder). Apparently it works if we map this share to a local drive and use the local path (eg. E:\ ); file_get_contents works fine. We are using Windows 2003 Server x64, IIS 6.0, PHP 5.3RC04 x64 via MS FastCGI . Reproduce code: --- Expected result: file saved with content "..." Actual result: -- PHP Warning: file_put_contents(\\share\intraroot$\folder\file.txt): failed to open stream: Permission denied in ... -- Edit this bug report at http://bugs.php.net/?id=48852&edit=1
#48854 [NEW]: array_merge_recursive modifies arrays after first one
From: stakadush at yahoo dot com
Operating system: Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: array_merge_recursive modifies arrays after first one
Description:
array_merge_recursive seems to modify the arrays which are passed,
except for the first one.
it turns all first-level non-array elements, into arrays.
the code will explain it better :)
Reproduce code:
---
$array1 = array(
'friends' => 5,
'children' => array(
'dogs' => 0,
),
);
$array2 = array(
'friends' => 10,
'children' => array(
'cats' => 5,
),
);
echo sprintf("Second array before: %s\n", print_r($array2, true));
$merged = array_merge_recursive($array1, $array2);
echo sprintf("Second array after: %s\n", print_r($array2, true));
Expected result:
to have $array2 untouched after array_merge_recursive:
Array
(
[friends] => 10
[children] => Array
(
[cats] => 5
)
)
Actual result:
--
$array2 gets modified after array_merge_recursive, and every first-
level no-array element, gets turned into an array (in this case
'friends')...
Array
(
[friends] => Array
(
[0] => 10
)
[children] => Array
(
[cats] => 5
)
)
--
Edit bug report at http://bugs.php.net/?id=48854&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48854&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48854&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48854&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48854&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48854&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48854&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48854&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48854&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48854&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48854&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48854&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48854&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48854&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48854&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48854&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48854&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48854&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48854&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48854&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48854&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48854&r=mysqlcfg
#46740 [Com]: PHP Not Cleanly Closing MySQL Connections on Apache Death
ID: 46740
Comment by: dmlance at gmail dot com
Reported By: php at matthewboehm dot com
Status: Open
Bug Type: PDO related
Operating System: RHEL5.2
PHP Version: 5.2.9
New Comment:
Same problem with 2.2.11 and 5.2.10.
Due high load on my server with croned scripts I got about 60% aborted
connections in my logs.
Previous Comments:
[2009-04-01 14:34:46] dstuff at brainsware dot org
Got the same problem using PHP version 5.2.9 on Debian (Lenny)
[2008-12-03 15:45:59] php at matthewboehm dot com
Description:
When using PHP/MySQL with persistent connections, upon the death of
an apache child, you get an 'aborted connection' message inside the
MySQL server's error log.
In my supremely most humbled opinion, I can only presume that PHP is
not cleanly closing opened MySQL connections when an apache child
dies and the PHP module is unloaded from apache's memory.
Reproduce code:
---
To reproduce:
1. Start httpd (I used 2.2.10) with PHP 5.2.6. httpd should use the
prefork MPM with the following settings on the MPM:
StartServers 5
MinSpareServers5
MaxSpareServers 10
MaxRequestsPerChild 1000
2. Browser the following PHP file several times to initiate several
persistent connections to your MySQL database. This can be either of the
MySQL methods that support persistence. (mysql_pconnect, and PDO)
true, PDO::ATTR_ERRMODE =>
PDO::ERRMODE_EXCEPTION));
if($res = $dbh->query("SELECT * FROM myTable"))
{
print "Query success";
}
else
{
print "Query failed";
}
}
catch(PDOException $e)
{
echo 'Error: ' . $e->getMessage();
}
3. Stop apache via any means. You will see in your MySQL log 1 aborted
connection line for each terminated apache process.
In my testing, I used 'ab' to throw 10,000 requests of the above code
at apache. Every 1000 requests, I would see the error in MySQL. This is
because of the MaxRequestsPerChild setting to be 1000. Every 1000, an
apache thread will suicide and then spawn a new thread.
Once the load test was complete, if more than MaxSpareServers threads
where running, apache would kill them off as well and you would see that
same number of errors in MySQL.
Expected result:
I would not expect to see any errors from MySQL. I would expect all
connections to be properly closed upon the death of an apache
process.
Actual result:
--
The actual result is an incorrectly closed MySQL connection.
--
Edit this bug report at http://bugs.php.net/?id=46740&edit=1
#48855 [NEW]: Decimals are rounded with PDO bindValue in mysql double/float fields
From: lorenzo-99 at libero dot it
Operating system: Windows XP
PHP version: 5.2.10
PHP Bug Type: PDO related
Bug description: Decimals are rounded with PDO bindValue in mysql double/float
fields
Description:
I'm inserting a new record in a Mysql table with a PDO routine, the table
have a double field (not specified the scale and size for the field), I'm
using the bindValue function, I try to save the value 9.1234567 in the
field, after the insert I found it saves 9.123457, so maximum 6 decimals
(with rounding).
The same problem happens with a float field, in this case it saves maximum
5 decimals
I didn't try with other dbms, my Mysql version is 5.1.36 (i verified that
the problem happens also with older versions)
Reproduce code:
---
This saves only 6 decimal (using bindValue):
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', :value)");
/*** bind values ***/
$sth->bindValue(':value', 9.1234567, PDO::PARAM_STR);
/*** execute the prepared statement ***/
$sth->execute();
This saves all decimals (without bindValue)
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', 9.1234567)");
/*** execute the prepared statement ***/
$sth->execute();
--
Edit bug report at http://bugs.php.net/?id=48855&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48855&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48855&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48855&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48855&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48855&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48855&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48855&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48855&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48855&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48855&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48855&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48855&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48855&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48855&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48855&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48855&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48855&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48855&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48855&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48855&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48855&r=mysqlcfg
#48837 [Com]: Building --with-curlwrappers can cause bad/illegal format or missing URL errors
ID: 48837 Comment by: jd at cpanel dot net Reported By: ram...@php.net Status: Feedback Bug Type: cURL related Operating System: Ubuntu 9.04 PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment: Probably the same issue as: http://bugs.php.net/bug.php?id=48603 It looks like when safe_mode or open_basedir are enabled and php is compiled with curlwrappers, curlwrappers registers the curl extension to handle file streams and then php_curl_option_url() in interface.c tells libcurl not to handle file requests. The "URL using bad/illegal format or missing URL" error message comes from libcurl itself. Previous Comments: [2009-07-07 18:36:01] ram...@php.net Oddly enough, I cannot reproduce this now in 5.3.0 or 5.2.10, though I was having this problem the other day. When I build either version with --with-curlwrappers and use the same code I used the other day, it appears to work fine now. As far as I know, nothing else on the system has changed in the meantime. I guess you can feel free to bogus this issue, since I can't reproduce it. [2009-07-07 17:17:45] j...@php.net Does this happen with PHP 5.2.10? [2009-07-07 16:59:06] ram...@php.net Description: I received the error "URL using bad/illegal format or missing URL" on some require_once() calls when PHP was built with --with-curlwrappers. Building PHP without --with-curlwrappers fixed the problem. Reproduce code: --- I was using a vanilla install of Zend Framework when I noticed the problem. Expected result: The file did exist at the location being required, and the include_path was correct, so I expected the file to be required. Actual result: -- Warning: require_once(): URL using bad/illegal format or missing URL in /home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader.php on line 396 Warning: require_once(/home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader/Exception.php): failed to open stream: operation failed in /home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader.php on line 396 Fatal error: require_once(): Failed opening required 'Zend/Loader/PluginLoader/Exception.php' (include_path='/home/ramsey/dev/zftest/lib') in /home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader.php on line 396 -- Edit this bug report at http://bugs.php.net/?id=48837&edit=1
#48854 [Opn->Csd]: array_merge_recursive modifies arrays after first one
ID: 48854
Updated by: fel...@php.net
Reported By: stakadush at yahoo dot com
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
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.
Fixed in 5.3, HEAD.
Previous Comments:
[2009-07-08 15:43:05] stakadush at yahoo dot com
Description:
array_merge_recursive seems to modify the arrays which are passed,
except for the first one.
it turns all first-level non-array elements, into arrays.
the code will explain it better :)
Reproduce code:
---
$array1 = array(
'friends' => 5,
'children' => array(
'dogs' => 0,
),
);
$array2 = array(
'friends' => 10,
'children' => array(
'cats' => 5,
),
);
echo sprintf("Second array before: %s\n", print_r($array2, true));
$merged = array_merge_recursive($array1, $array2);
echo sprintf("Second array after: %s\n", print_r($array2, true));
Expected result:
to have $array2 untouched after array_merge_recursive:
Array
(
[friends] => 10
[children] => Array
(
[cats] => 5
)
)
Actual result:
--
$array2 gets modified after array_merge_recursive, and every first-
level no-array element, gets turned into an array (in this case
'friends')...
Array
(
[friends] => Array
(
[0] => 10
)
[children] => Array
(
[cats] => 5
)
)
--
Edit this bug report at http://bugs.php.net/?id=48854&edit=1
#48856 [NEW]: PDO_Statement->bindParam binds multiple parameters of the same name
From: dhammari at q90 dot com
Operating system: Linux 2.6.27-gentoo-r8
PHP version: 5.2.10
PHP Bug Type: PDO related
Bug description: PDO_Statement->bindParam binds multiple parameters of the
same name
Description:
My PDO Statement seems to bind multiple parameters of the same name even
though the PDO->Prepare documentation indicates that this should fail: "You
cannot use a named parameter marker of the same name twice in a prepared
statement." Nevertheless, my SQL statement that is reusing the same
parameter is getting through and returning a valid result set from a MySQL
engine.
PHP Version: 5.2.9-pl2-gentoo
System: Linux 2.6.27-gentoo-r8
Reproduce code:
---
= :myParameter AND
LENGTH(name) > :myParameter AND 1 = :myParameter";
$params = array("myParameter" => 1);
$statement = $pdo->prepare($sql);
foreach($params as $key => $value){
$statement->bindParam(":".$key, $value);
}
$statement->debugDumpParams();
$success = $statement->execute();
if(!$success){
echo("\nSQL FAILED\n");
var_dump($pdo->errorInfo());
var_dump($statement->errorInfo());
}
else{
echo("\nSQL SUCCEEDED\n");
$result = $statement->fetchALL(PDO::FETCH_ASSOC);
var_dump($result);
}
?>
Expected result:
I expect to see the following error:
Invalid parameter number: number of bound variables does not match number
of tokens
SQL FAILED
array
0 => string '0' (length=5)
array
0 => string 'HY093' (length=5)
Actual result:
--
Instead, I get the following:
SQL SUCCEEDED
array
0 =>
array
'id' => string '1' (length=1)
'Name' => string 'Binds Both Parameters' (length=21)
'Description' => string 'Seems to bind both parameters' (length=29)
1 =>
array
'id' => string '2' (length=1)
'Name' => string 'Binds All Parameters' (length=20)
'Description' => string 'Seems to bind all parameters' (length=28)
--
Edit bug report at http://bugs.php.net/?id=48856&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48856&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48856&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48856&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48856&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48856&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48856&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48856&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48856&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48856&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48856&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48856&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48856&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48856&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48856&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48856&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48856&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48856&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48856&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48856&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48856&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48856&r=mysqlcfg
#48843 [Opn->Fbk]: Can't seem to stop Deprecated messages in php.log
ID: 48843 Updated by: j...@php.net Reported By: jeff at jeffweinberger dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Mac OS/X 10.5.7 client version PHP Version: 5.3.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-07-08 00:58:31] jeff at jeffweinberger dot com Description: I am getting large numbers of "PHP Deprecated..." messages in my php.log file (I expect this, based on some not-yet-updated code). Until I update all my PHP code, I want to shut off these messages (they are causing the log file to exceed several GB). I have tried all of the following in php.ini: error_reporting = E_ALL & ~E_DEPRECATED & E_ERROR & E_WARNING & E_PARSE & E_NOTICE & E_CORE_ERROR & E_USER_ERROR & E_USER_WARNING & E_USER_NOTICE & E_COMPILE_ERROR & E_COMPILE_WARNING error_reporting = ~E_DEPRECATED & E_ALL & E_ERROR & E_WARNING & E_PARSE & E_NOTICE & E_CORE_ERROR & E_USER_ERROR & E_USER_WARNING & E_USER_NOTICE & E_COMPILE_ERROR & E_COMPILE_WARNING error_reporting = E_ALL & E_ERROR & E_WARNING & E_PARSE & E_NOTICE & E_CORE_ERROR & E_USER_ERROR & E_USER_WARNING & E_USER_NOTICE & E_COMPILE_ERROR & E_COMPILE_WARNING & ~E_DEPRECATED error_reporting = E_ERROR & E_CORE_ERROR & E_USER_ERROR & E_COMPILE_ERROR & E_COMPILE_WARNING & ~E_DEPRECATED error_reporting = ~E_DEPRECATED & E_ERROR & E_CORE_ERROR & E_USER_ERROR & E_COMPILE_ERROR & E_COMPILE_WARNING error_reporting = E_ALL & ~E_DEPRECATED error_reporting = 24575 error_reporting = 3 and after each change, I restart Apache (PHP is running as a CGI with Apache 2.2.11) and PHP. in my php_info() display, the error_reporting value shows the correct value for the then-active line (above), but the log entries still appear. I have tried the suggestions of several on the PHP-General mailing list to no avail. Please let me know if there is additional information that will help. Expected result: "PHP Deprecated..." messages no longer appear in php.log Actual result: -- "PHP Deprecated..." messages still appear in large numbers php.log -- Edit this bug report at http://bugs.php.net/?id=48843&edit=1
#48846 [Opn->Bgs]: convertin int to float
ID: 48846 Updated by: j...@php.net Reported By: marcin at datamomentu dot eu -Status: Open +Status: Bogus Bug Type: Variables related Operating System: Windows XP PHP Version: 5.3.0 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2009-07-08 06:52:00] marcin at datamomentu dot eu Description: $t1 = floatval(8.95); var_dump($t1); $t2 = $t1*100; var_dump($t2); $t3 = (int)$t2; var_dump($t3); t3 should be 8.95 and its 8.94 its true for t1 = 7.95 or 9.95 its not true for t1 = 6.95 or 5.95 or 4.95 etc Reproduce code: --- $t1 = floatval(8.95); var_dump($t1); t2 = $t1*100; var_dump($t2); $t3 = (int)$t2; var_dump($t3); Expected result: t3 = 8.95 Actual result: -- t3 = 8.94 -- Edit this bug report at http://bugs.php.net/?id=48846&edit=1
#48853 [Opn->Fbk]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853 Updated by: j...@php.net Reported By: leonard-php-bugs at ottolander dot nl -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: CentOS-4 PHP Version: 5.2CVS-2009-07-08 (CVS) New Comment: And your configure line is..? Previous Comments: [2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl Description: Building 5.2.9 on CentOS-4, although later versions until CVS today are affected. The OS is not really relevant, just the reason there are no unbundled headers available as there's a version mismatch with the bundled headers. Using the bundled pcre library by not supplying any pcre configure options. When the unbundled (upgraded/matching) headers are available on the system the build succeeds. However, if no unbundled headers are available httpd.h cannot find the bundled pcreposix.h (and other headers). This is *not* an apache issue, the issue is a missing include path in the build. If you compare ext/pcre/config0.m4 an include path is provided in case of an external pcre (although on CentOS it will be found in /usr/include no matter if a path is specifically provided): if test "$PHP_PCRE_REGEX" != "no"; then if test "$PHP_PCRE_REGEX" = "yes"; then ... (no PHP_ADD_INCLUDE here) else ... PHP_ADD_INCLUDE($PCRE_INCDIR) ... fi Fix with this patch which provides the include path (ignore the line wraps, it's just a single line addition): --- php-5.2.9/ext/pcre/config0.m4.000 2008-12-29 16:27:11.0 +0100 +++ php-5.2.9/ext/pcre/config0.m4 2009-07-08 13:27:11.0 +0200 @@ -13,6 +13,7 @@ if test "$PHP_PCRE_REGEX" != "no"; then if test "$PHP_PCRE_REGEX" = "yes"; then PHP_NEW_EXTENSION(pcre, pcrelib/pcre_chartables.c pcrelib/pcre_ucd.c pcrelib/pcre_compile.c pcrelib/pcre_config.c pcrelib/pcre_exec.c pcrelib/pcre_fullinfo.c pcrelib/pcre_get.c pcrelib/pcre_globals.c pcrelib/pcre_info.c pcrelib/pcre_maketables.c pcrelib/pcre_newline.c pcrelib/pcre_ord2utf8.c pcrelib/pcre_refcount.c pcrelib/pcre_study.c pcrelib/pcre_tables.c pcrelib/pcre_try_flipped.c pcrelib/pcre_valid_utf8.c pcrelib/pcre_version.c pcrelib/pcre_xclass.c php_pcre.c, $ext_shared,,-...@ext_srcdir@/pcrelib) PHP_ADD_BUILD_DIR($ext_builddir/pcrelib) +PHP_ADD_INCLUDE([$ext_srcdir/pcrelib]) PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/]) AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ]) else Reproduce code: --- Make sure you REMOVE any unbundled pcre headers from the system. /usr/include is in the include path and thus the necessary unbundled headers will be found so you wont see the build fail. Configure without any pcre related options to use the bundled version. Expected result: Headers found, build succeeds. It does with the patch. Actual result: -- /bin/sh /usr/src/redhat/BUILD/php-5.2.9/build-apache/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/include/httpd -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-0 -I/usr/include/apr-0 -Isapi/apache2handler/ -I/usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/include -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/main -I/usr/src/redhat/BUILD/php-5.2.9 -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/ext/date/lib -I/usr/src/redhat/BUILD/php-5.2.9/ext/date/lib -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/TSRM -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/Zend -I/usr/src/redhat/BUILD/php-5.2.9/main -I/usr/src/redhat/BUILD/php-5.2.9/Zend -I/usr/src/redhat/BUILD/php-5.2.9/TSRM -I/usr/src/redhat/BUILD/php-5.2.9/build-apache/-I/usr/include -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -fno-strict-aliasing -prefer-pic -c /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/php_apache.h:24, from /usr/src/redhat/BUILD/php-5.2.9/sapi/apache2handler/mod_php5.c:26: /usr/include/httpd/httpd.h:43:23: pcreposix.h: No such file or directory make: *** [sapi/apache2handler/mod_php5.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=48853&edit=1
#48849 [Opn->Bgs]: php5_module unable catch exception
ID: 48849
Updated by: j...@php.net
Reported By: caotao1570 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: linux
-PHP Version: 5.2CVS-2009-07-08 (snap)
+PHP Version: 5.2.6
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
Previous Comments:
[2009-07-08 08:15:30] caotao1570 at gmail dot com
Description:
php5_module unable catch exception
½á¹û´íÎó
php 5.2.6
ÔÚÃüÁîÐÐÏÂÔËÐÐûÓÐÎÊÌ⣬µ«ÊÇÔÚapache2ϾÍÓÐÎÊÌâÁË
Reproduce code:
---
try
{
throw new Exception("ex");
for($i=0;$i<1;$i++)
{
}
}catch(Exception $e)
{
echo "Exception\n";
return ;
}
echo "end\n";
Expected result:
not echo "Exception"
if:
--
try
{
throw new Exception("ex");
}catch(Exception $e)
{
echo "Exception\n";
return ;
}
echo "end\n";
cho "Exception"
Actual result:
--
echo "Exception"
--
Edit this bug report at http://bugs.php.net/?id=48849&edit=1
#48793 [Opn->Fbk]: Setting error_log in php.ini causes redirection
ID: 48793 Updated by: j...@php.net Reported By: memoimyself at yahoo dot com dot br -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: WinXP SP3 PHP Version: 5.3.0 -Assigned To: +Assigned To: fb-req-jani New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Should be fixed now.. Previous Comments: [2009-07-07 22:17:27] memoimyself at yahoo dot com dot br [Re: j...@php.net 7 Jul 3:38pm] What crashes, specifically, should I watch out for? Applications do crash on occasion, just as they do on any box and with any OS (in my not very limited experience). But I have not experienced a surge in application crashes since upgrading to PHP 5.3.0, and have not had a single major OS crash so far. [2009-07-07 22:13:01] memoimyself at yahoo dot com dot br [Re: ninzya 5 Jul 1:55pm] You're right, my browser(s) is very likely responsible for the redirection. Firefox 3.0.11 redirects; IE 8 reports the page as inaccessible; and Opera doesn't do anything. But the fact remains that something is causing the problem, and that something involves PHP -- and only when error_log is set in php.ini. As I've previously reported, Apache continues serving pages/files other than PHP normally. I'm aware that PHP interacts with Apache and even with the OS so that the problem could be due to a combination of factors. But I had never had this problem before, and the only significant change in my set-up has been the upgrade of PHP from 5.2.8 to 5.3.0. In other words, something seems to have changed in PHP that may be causing this strange problem. [2009-07-07 15:38:10] j...@php.net Check if there are some crashes happening. (most likely there are since others have reported the same..) [2009-07-05 13:55:37] ninzya at inbox dot lv I guess this is your browser's activity. PHP itself does not deal with 'user hint' redirections by prepending or appending www's and com's to the requested host. Your browser, probably, reacts to HTTP 500 error code and attempts a redirection to probably valid location of www.localhost.com. Anyway, look at the access.log of apache, see what's the apache's response code to your request. Another guess may be is that the PHP is failing (segfaulting) with error_log, which leads to connection interruption between your browser and web server. Then browser attempts to connect to www.localhost.com... Anyway, redirection is being done by your browser. [2009-07-04 21:10:31] memoimyself at yahoo dot com dot br Q: Is your apache server on 8080 port? A: Nope, 80. My httpd.conf is pretty straightforward and uses default values. Please note that Apache serves pure HTML (as well as other files) normally. Things only get weird when PHP is involved AND error_log is set in php.ini. 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/48793 -- Edit this bug report at http://bugs.php.net/?id=48793&edit=1
#48218 [Opn->Asn]: ZipArchive->open fails under some circumstances
ID: 48218
Updated by: j...@php.net
Reported By: mb at smartftp dot com
-Status: Open
+Status: Assigned
Bug Type: Zip Related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-10)
Assigned To: pajoye
Previous Comments:
[2009-07-06 14:37:18] mb at smartftp dot com
Restricted privileges: read only access
If the open() function really requires rw access consider to fall back
to read-only "r" if read-write "rw" fails. This way the archive can be
opened for read only access.
Regards,
Mat
[2009-07-06 13:21:07] paj...@php.net
It open the files in read/write mode.
What do you mean by restricted privileges? Can you describe the exact
situation when you get this error (which permissions, context, etc.)?
[2009-05-10 00:36:24] mb at smartftp dot com
Description:
The ZIPArchive->open fails with error 11 when a zip file is opened that
has just been created using ZIPArchive.
The test code works as expected when running it under administrative
privileges. However when running it under restricted access privileges
the ZIPArchive->open function is unable to open the file. On the other
side readfile() can successfully open the same file. My guess is that
the ZipArchive->open functions tries to open the file using a mode other
than just read.
Reproduce code:
---
open($file, ZIPARCHIVE::CREATE | ZIPARCHIVE::OVERWRITE ))
{
for($i=0; $i<10; $i++)
{
$bogus = "fjewklfj23klfj23lkfj23l";
$create->addFromString($i, $bogus);
}
if(!$create->close())
{
print("close failed");
}
}
$zip = new ZipArchive();
$open = $zip->open($file);
if($open === TRUE)
{
print("ok\n");
}
else
{
print("error ".$open."\n");
readfile($file);
}
Expected result:
ok
Actual result:
--
error 11.
content of zip file.
--
Edit this bug report at http://bugs.php.net/?id=48218&edit=1
#48857 [NEW]: fetch mashes data when Stored Procedure uses prepared statments
From: web at sellingpower dot com
Operating system: ubuntu5.6
PHP version: 5.2.10
PHP Bug Type: MySQLi related
Bug description: fetch mashes data when Stored Procedure uses prepared
statments
Description:
We are using the mysqli extension to interface with MySQL 5.0.51a. We
are using the prepare/bind_param/execute/bind_result/fetch process against
stored procedures. When the stored procedure pulls the data via a prepared
statment, fetch mangles the data when putting it into the bound result
variables.
PROCEDURE `p_TestNonPreparedStatement`()
and
PROCEDURE `p_TestPreparedStatement`()
produce identical results in the query browser but very different results
when run through getresult($stmt,$fields)
Unfortunately, this server is behind a firewall and not accessible to the
public.
All previous bug reports similar to this have identified this behavior as
not a bug without identifying how to get around the problem.
Reproduce code:
---
CREATE definer=`rober...@`` PROCEDURE `p_TestNonPreparedStatement`()
READS SQL DATA
DETERMINISTIC
BEGIN
SELECT * FROM `eBlast`.`veMailList`;
END
--
CREATE definer=`rober...@`` PROCEDURE `p_TestPreparedStatement`()
READS SQL DATA
DETERMINISTIC
BEGIN
DECLARE `new_query` VARCHAR(4096) DEFAULT '';
SET `new_query` = 'SELECT * FROM `eBlast`.`veMailList`';
SET @new_query = `new_query`;
PREPARE `filtersetlist_query` FROM @new_query;
EXECUTE `filtersetlist_query`;
DEALLOCATE PREPARE `filtersetlist_query`;
END
--
public function pullSendees($status_id,&$fields)
{
$sendees = array();
$DB = new mysqli(DB_SERVER, DB_SERVER_USERNAME,
DB_SERVER_PASSWORD,
DB_DATABASE_EBLAST);
if (mysqli_connect_errno()) {
throw new Exception('Connection to database failed');
}
$stmt = $DB->stmt_init();
if ($stmt->prepare('CALL `eBlast`.`p_TestNonPreparedStatement`
(?,?)'))
{
$stmt->bind_param('is',$this->id,$status_id);
$stmt->execute();
$sendees = getresult($stmt,$fields);
$stmt->close();
}
$DB->close();
return $sendees;
}
function getresult($stmt,&$fields)
{
$result = array();
$metadata = $stmt->result_metadata();
$fields = $metadata->fetch_fields();
for (;;)
{
$pointers = array();
$row = new stdClass();
$pointers[0] = $stmt;
$count = 1;
foreach ($fields as $field)
{
$fieldname = $field->name;
$pointers[$count] = &$row->$fieldname;
$count++;
}
call_user_func_array('mysqli_stmt_bind_result', $pointers);
if (!mysqli_stmt_fetch($stmt))
break;
foreach ($fields as $field)
{
$fieldname = $field->name;
trigger_error('$' . 'row->' . $fieldname . ' = ' .
$row->$fieldname);
}
$result[] = $row;
}
$metadata->free();
return $result;
}
Expected result:
Prepared Statment Results:
1 1 Robert Polickoski
robertpolicko...@sellingpower.com
Fredericksburg VA 223 22406-1126 1 1
6 7 2 1 1 1 1
1 0 0 1 1 0 0 1 1
1 1
Actual result:
--
NonPrepared Statment Results:
1919246959 1867516532
ickoski!robertpolicko...@sellingpower.comfredericksburgva223
22406-112611672111110 1 822161665
���elli-5
-5
251 251 251 -5 -5 0
101 108 108 105 110
103 32 30575-101-114 32:72:2008-10-07 00:00:00
2009-02-09
16:54:304294966272-105-01 0027694-101-102 116:95
--
Edit bug report at http://bugs.php.net/?id=48857&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48857&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48857&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48857&r=trysnapshot60
Fixed in CVS:
http://
#48857 [Opn]: fetch mashes data when Stored Procedure uses prepared statements
ID: 48857
User updated by: web at sellingpower dot com
-Summary: fetch mashes data when Stored Procedure uses prepared
statments
Reported By: web at sellingpower dot com
Status: Open
Bug Type: MySQLi related
Operating System: ubuntu5.6
PHP Version: 5.2.10
New Comment:
I misspelled statement in the summary and wanted to correct it for
search purposes.
Previous Comments:
[2009-07-08 21:54:45] web at sellingpower dot com
Description:
We are using the mysqli extension to interface with MySQL 5.0.51a. We
are using the prepare/bind_param/execute/bind_result/fetch process
against stored procedures. When the stored procedure pulls the data via
a prepared statment, fetch mangles the data when putting it into the
bound result variables.
PROCEDURE `p_TestNonPreparedStatement`()
and
PROCEDURE `p_TestPreparedStatement`()
produce identical results in the query browser but very different
results when run through getresult($stmt,$fields)
Unfortunately, this server is behind a firewall and not accessible to
the public.
All previous bug reports similar to this have identified this behavior
as not a bug without identifying how to get around the problem.
Reproduce code:
---
CREATE definer=`rober...@`` PROCEDURE `p_TestNonPreparedStatement`()
READS SQL DATA
DETERMINISTIC
BEGIN
SELECT * FROM `eBlast`.`veMailList`;
END
--
CREATE definer=`rober...@`` PROCEDURE `p_TestPreparedStatement`()
READS SQL DATA
DETERMINISTIC
BEGIN
DECLARE `new_query` VARCHAR(4096) DEFAULT '';
SET `new_query` = 'SELECT * FROM `eBlast`.`veMailList`';
SET @new_query = `new_query`;
PREPARE `filtersetlist_query` FROM @new_query;
EXECUTE `filtersetlist_query`;
DEALLOCATE PREPARE `filtersetlist_query`;
END
--
public function pullSendees($status_id,&$fields)
{
$sendees = array();
$DB = new mysqli(DB_SERVER, DB_SERVER_USERNAME,
DB_SERVER_PASSWORD,
DB_DATABASE_EBLAST);
if (mysqli_connect_errno()) {
throw new Exception('Connection to database failed');
}
$stmt = $DB->stmt_init();
if ($stmt->prepare('CALL `eBlast`.`p_TestNonPreparedStatement`
(?,?)'))
{
$stmt->bind_param('is',$this->id,$status_id);
$stmt->execute();
$sendees = getresult($stmt,$fields);
$stmt->close();
}
$DB->close();
return $sendees;
}
function getresult($stmt,&$fields)
{
$result = array();
$metadata = $stmt->result_metadata();
$fields = $metadata->fetch_fields();
for (;;)
{
$pointers = array();
$row = new stdClass();
$pointers[0] = $stmt;
$count = 1;
foreach ($fields as $field)
{
$fieldname = $field->name;
$pointers[$count] = &$row->$fieldname;
$count++;
}
call_user_func_array('mysqli_stmt_bind_result', $pointers);
if (!mysqli_stmt_fetch($stmt))
break;
foreach ($fields as $field)
{
$fieldname = $field->name;
trigger_error('$' . 'row->' . $fieldname . ' = ' .
$row->$fieldname);
}
$result[] = $row;
}
$metadata->free();
return $result;
}
Expected result:
Prepared Statment Results:
1 1 Robert Polickoski
robertpolicko...@sellingpower.com
Fredericksburg VA 223 22406-1126 1 1
6 7 2 1 1 1
1 1 0 0 1 1 0 0 1
1 1 1
Actual result:
--
NonPrepared Statment Results:
1919246959 1867516532
ickoski!robertpolicko...@sellingpower.comfredericksburgva223
22406-112611672111110 1 822161665
���elli-5
-5
251 251 251 -5 -5 0
101 108 108 105 110
103 32 30575-101-114 32:72:2008-10-07 00:00:00
2009-02-09
16:54:304294966272-105-01 0027694-101-102 116:95
---
#48858 [NEW]: array item definition problem?
From: justin dot carlson at gmail dot com
Operating system: Windows XP
PHP version: 5.3.0
PHP Bug Type: Arrays related
Bug description: array item definition problem?
Description:
Array items are not as defined when using the same key twice.
I have not yet tested this outside of a class.
Reproduce code:
---
'Apple',
self::B => 'Boy',
self::C => 'Cat',
self::D => 'Dog'
);
public static function Bar() {
print_R( self::$sample );
}
}
?>
Expected result:
In PHP 5.2.x:
Array
(
[2] => Boy
[3] => Cat
[1] => Dog
)
This is what I would expect to be valid, as the 2nd entry would override
the first, making "Dog" the correct value for index 1.
Actual result:
--
In PHP 5.3.x:
Array
(
[1] => Apple
[2] => Boy
[3] => Cat
)
This was not expected, as the 1st entry maintained it's value.
--
Edit bug report at http://bugs.php.net/?id=48858&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48858&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48858&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48858&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48858&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48858&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48858&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48858&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48858&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48858&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48858&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48858&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48858&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48858&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48858&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48858&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48858&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48858&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48858&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48858&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48858&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48858&r=mysqlcfg
#48853 [Com]: Using bundled pcre fails if no unbundled headers are available on the system
ID: 48853
Comment by: leonard-php-bugs at ottolander dot nl
Reported By: leonard-php-bugs at ottolander dot nl
Status: Feedback
Bug Type: Compile Failure
Operating System: CentOS-4
PHP Version: 5.2CVS-2009-07-08 (CVS)
New Comment:
As I said, I'm not using a --with- or --without-pcre option. The other
options seem not very relevant in this context but I'll paste the line
from the used rpm spec file here. %configure translates to configure ;)
%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--without-mime-magic \
--without-sqlite \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
$*
I'd say, just open ext/pcre/config0.m4 and see there's no
PHP_ADD_INCLUDE inside the second (nested) if that causes httpd.h to be
unable to locate pcreposix.h if no pcre headers are installed on the
system.
If there is already a local copy of the pcre headers installed the
-I/usr/include will cause the build to still find a (possible incorrect)
version of the headers, and it succeeds (if the versions are close
enough).
On my system these headers aren't available as on CentOS-4 they are
version 4.5, so I removed them. This is an unusual situation, which is
probably why nobody noticed this issue before (the local headers are
probably available on most systems because builds like apache depend on
them).
Previous Comments:
[2009-07-08 20:37:17] j...@php.net
And your configure line is..?
[2009-07-08 14:17:45] leonard-php-bugs at ottolander dot nl
Description:
Building 5.2.9 on CentOS-4, although later versions until CVS today are
affected. The OS is not really relevant, just the reason there are no
unbundled headers available as there's a version mismatch with the
bundled headers.
Using the bundled pcre library by not supplying any pcre configure
options. When the unbundled (upgraded/matching) headers are available on
the system the build succeeds. However, if no unbundled headers are
available httpd.h cannot find the bundled pcreposix.h (and other
headers).
This is *not* an apache issue, the issue is a missing include path in
the build.
If you compare ext/pcre/config0.m4 an include path is provided in case
of an external pcre (although on CentOS it will be found in /usr/include
no matter if a path is specifically provided):
if test "$PHP_PCRE_REGEX" != "no"; then
if test "$PHP_PCRE_REGEX" = "yes"; then
... (no PHP_ADD_INCLUDE here)
else
...
PHP_ADD_INCLUDE($PCRE_INCDIR)
...
fi
Fix with this patch which provides the include path (ignore the line
wraps, it's just a single line addition):
--- php-5.2.9/ext/pcre/config0.m4.000 2008-12-29 16:27:11.0
+0100
+++ php-5.2.9/ext/pcre/config0.m4 2009-07-08 13:27:11.0 +0200
@@ -13,6 +13,7 @@ if test "$PHP_PCRE_REGEX" != "no"; then
if test "$PHP_PCRE_REGEX" = "yes"; then
PHP_NEW_EXTENSION(pcre, pcrelib/pcre_chartables.c
pcrelib/pcre_ucd.c pcrelib/pcre_compile.c pcrelib/pcre_config.c
pcrelib/pcre_exec.c pcrelib/pcre_fullinfo.c pcrelib/pcre_get.c
pcrelib/pcre_globals.c pcrelib/pcre_info.c pcrelib/pcre_maketables.c
pcrelib/pcre_newline.c pcrelib/pcre_ord2utf8.c pcrelib/pcre_refcount.c
pcrelib/pcre_study.c pcrelib/pcre_tables.c pcrelib/pcre_try_flipped.c
pcrelib/pcre_valid_utf8.c pcrelib/pcre_version.c pcrelib/pcre_xclass.c
php_pcre.c, $ext_shared,,-...@ext_srcdir@/pcrelib)
PHP_ADD_BUILD_DIR($ext_builddir/pcrelib)
+PHP_ADD_INCLUDE([$ext_srcdir/pcrelib])
PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/])
AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ])
else
Reproduce code:
---
Make sure you REMOVE any unbundled pcre headers from the system.
/usr/include is in the include path and thus the necessary unbundled
headers will be found so you wont see the build fail.
Configure without any pcre related options to use the bundled version.
Expected result:
---
#48859 [NEW]: PDO mysql does not support multiple inital queries
From: techi at techi dot name Operating system: all PHP version: 5.2.10 PHP Bug Type: PDO related Bug description: PDO mysql does not support multiple inital queries Description: When using intial SQL query with PDO::MYSQL_ATTR_INIT_COMMAND, only one query can be queried. More queries throws exception SQLSTATE[HY000]: General error: 2014 I am not sure, if this is bug or feature or some PDO limitation, but sometimes more than one initial query is needed Reproduce code: --- $pdo = new PDO( 'mysql:host=hostname;dbname=defaultDbName', 'username', 'password', array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8;SET time_zone = 'Europe/Prague'") ); Actual result: -- SQLSTATE[HY000]: General error: 2014 -- Edit bug report at http://bugs.php.net/?id=48859&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48859&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48859&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48859&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48859&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48859&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48859&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48859&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48859&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48859&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48859&r=support Expected behavior: http://bugs.php.net/fix.php?id=48859&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48859&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48859&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48859&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48859&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48859&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48859&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48859&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48859&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48859&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48859&r=mysqlcfg
#48793 [Fbk->Opn]: Setting error_log in php.ini causes redirection
ID: 48793 User updated by: memoimyself at yahoo dot com dot br Reported By: memoimyself at yahoo dot com dot br -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: WinXP SP3 PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment: I've just installed the CVS snapshot and the problem I reported has indeed been fixed. Thank you very much! Previous Comments: [2009-07-08 20:38:44] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Should be fixed now.. [2009-07-07 22:17:27] memoimyself at yahoo dot com dot br [Re: j...@php.net 7 Jul 3:38pm] What crashes, specifically, should I watch out for? Applications do crash on occasion, just as they do on any box and with any OS (in my not very limited experience). But I have not experienced a surge in application crashes since upgrading to PHP 5.3.0, and have not had a single major OS crash so far. [2009-07-07 22:13:01] memoimyself at yahoo dot com dot br [Re: ninzya 5 Jul 1:55pm] You're right, my browser(s) is very likely responsible for the redirection. Firefox 3.0.11 redirects; IE 8 reports the page as inaccessible; and Opera doesn't do anything. But the fact remains that something is causing the problem, and that something involves PHP -- and only when error_log is set in php.ini. As I've previously reported, Apache continues serving pages/files other than PHP normally. I'm aware that PHP interacts with Apache and even with the OS so that the problem could be due to a combination of factors. But I had never had this problem before, and the only significant change in my set-up has been the upgrade of PHP from 5.2.8 to 5.3.0. In other words, something seems to have changed in PHP that may be causing this strange problem. [2009-07-07 15:38:10] j...@php.net Check if there are some crashes happening. (most likely there are since others have reported the same..) [2009-07-05 13:55:37] ninzya at inbox dot lv I guess this is your browser's activity. PHP itself does not deal with 'user hint' redirections by prepending or appending www's and com's to the requested host. Your browser, probably, reacts to HTTP 500 error code and attempts a redirection to probably valid location of www.localhost.com. Anyway, look at the access.log of apache, see what's the apache's response code to your request. Another guess may be is that the PHP is failing (segfaulting) with error_log, which leads to connection interruption between your browser and web server. Then browser attempts to connect to www.localhost.com... Anyway, redirection is being done by your browser. 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/48793 -- Edit this bug report at http://bugs.php.net/?id=48793&edit=1
#48860 [NEW]: Data in SplQueue objects is not persistent
From: dave at dtracorp dot com
Operating system: windows xp
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: Data in SplQueue objects is not persistent
Description:
I'm trying to store an SplQueue object in the session, on page reload the
SplQueue object is still there, but it has no data. This happens on Windows
XP (Apache 2.0.58), but also on Fedora 8 (apache 2.2), and a Debian build
running apache 2.2.
Reproduce code:
---
enqueue('something');
$q->enqueue('over there');
session_start();
$_SESSION['q'] = $q;
?>
on the second page
';
print_r($q);
Expected result:
SplQueue Object
(
[flags:SplDoublyLinkedList:private] => 4
[dllist:SplDoublyLinkedList:private] => Array
(
[0] => something
[1] => over there
)
)
Actual result:
--
SplQueue Object
(
[flags:SplDoublyLinkedList:private] => 4
[dllist:SplDoublyLinkedList:private] => Array
(
)
)
--
Edit bug report at http://bugs.php.net/?id=48860&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48860&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48860&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48860&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48860&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48860&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48860&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48860&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48860&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48860&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48860&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48860&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48860&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48860&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48860&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48860&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48860&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48860&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48860&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48860&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48860&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48860&r=mysqlcfg
#48775 [Fbk->Opn]: php-5.2.10 treats include_path as url/hostname
ID: 48775
User updated by: alexander at sulfrian dot net
Reported By: alexander at sulfrian dot net
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Same problem with the latest snapshot.
But I got the problem. Problem with roundcube is fixed if I ./configure
laltest snapshot (or 5.2.10) without --with-curlwrappers (means
--without-curlwrappers).
With 5.2.9 it worked with --with-curlwrappers. Maybe it is a side
condition of the stream_wrapper in include (change from 5.2.9 to
5.2.10). Would be nice if it is fixable :)
Thanks
Alexander
Previous Comments:
[2009-07-07 17:20:18] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-07-06 23:02:26] hoffie at gentoo dot org
I don't think we are shipping any intrusive patches here at gentoo
anymore, and those we do ship haven't changed for some time.
Also, I'm using roundcube without problems on one of my machines with
the latest php and another dev just told me he's using horde without
problems.
Please retry with a vanilla php build (tarball from php.net)
[2009-07-05 01:26:17] t...@php.net
Because I work on RoundCube, I double-checked this bug submission.
Just compiled PHP 5.2.10 from source with this:
./configure --with-mysql --enable-fastcgi --enable-force-cgi-redirect
make
And then put the "sapi/cgi/php-cgi" into the webserver as the fcgi
binary it uses to serve PHP to test it. And, absolutely no issues.
It seems to me like the Gentoo packages are borked. I suggest you guys
verify that it works for you when you compile PHP from source.
[2009-07-03 14:09:01] bugs+php at nospam dot obeliks dot de
I can confirm that I'm having the same problem with php-5.2.10 on
Gentoo linux.
Here it occurs with Horde Webmail, which uses the following call to
change the include_path (which worked fine on any previous version of
php):
> ini_set('include_path', dirname(__FILE__) . PATH_SEPARATOR .
dirname(__FILE__) . '/../pear');
[2009-07-03 08:59:52] alexander at sulfrian dot net
Noticed while trying to install roundcube webmail 0.2.0. I just tried
to create a minimal testing script and didn't get it.
One strange thing is, that if i call the script via php cli from shell,
it is working. Don't know how i could debug it. roundcube using the
__autoload function and all includes seems to be ok. Is there any
possibility to echo the hostname, that could not be resolved if such
error occur?
I am using Gentoo Linux and so installed php from source via the
portage system of gentoo. I not changed the config and so used the
original that is installed by gentoo. (Do not know if it is 100%
identical to the original from the php source package.)
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/48775
--
Edit this bug report at http://bugs.php.net/?id=48775&edit=1
#22662 [Com]: shell_exec not working on windows XP
ID: 22662
Comment by: bmcclory at gmail dot com
Reported By: pjaleysen at hotmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 4.3.2-RC
New Comment:
Can someone tell me why the following code will not work in Windows:
system("nmap $host");
Driving me nuts. It works fine on apache servers and apparantly other
IIS servers. I don't know if i'm missing something in php.ini or what.
Other commands can be run from system(), just not nmap.
Previous Comments:
[2004-08-03 05:57:51] wfrench at prevailnet dot net
I've had the same problem trying to use unzip.exe on XP with php
4.3.8.
Got some interesting results when I tried the dos batch file wrapper
approach...
When I use the batch:
-
@echo hello world
-
it works like a champ.
but when I change the file thusly:
-
unzip
@echo hello world
-
if prints the following:
-
c:\inetpub\wwwroot\svgwork>unzip hello world
-
Obviously it has prepended my command (unzip) with my web directory.
Not so obvious perhaps is what the '>' character is doing in there.
[2004-04-28 20:00:19] clubland at gmx dot net
Hi all,
Platform:
IIS 6.0 / Windows 2003 Server
Problem:
shell_exec etc `s not working
Solution:
check rights on %SYS32%\cmd.exe
Chris
[2003-06-03 17:52:16] spoon at nexdot dot net
This seems very close to what im experiencing.
I am using php 5.0.0-dev (updated about 2 weeks ago), but the problem
has occured for me on 4.x.x versions. I use Windows XP Pro/Windows 2000
Server with my 5.0.0-dev. Apache 2 24
When i use ANY of the MANY methods for passing a system call
System
Shell_exec
Exec
`` (backtick)
Passthru
they all act the same (in this case, as a passthru), UNLESS with a
native dos command (which i tried after reading this bug post).
The functions such as the 2 exec ones and the backticks should not
output anything. I do this:
$string=exec/shell_exec/``;
when calling something such as ping/dir/echo, or any normal dos
command, they work as expected... nothing is output to the browser (or
above the php header have you) unless i do an
echo $string;
When i try to call a program such as gzip, $string has a length of 0
(or null) and the the output from the command appears in my browser (or
above PHP headers if run from command line) without echo'ing. Other
special parts of each system call functions also do not work, such as
exec's array output, which is null unless a native dos command.
[2003-03-15 03:42:47] pjaleysen at hotmail dot com
Executing Windows-based applications work alright, but not the ones
running in DOS. e.g. I am using winzip now instead of pkzip.exe for dos.
Because I have to use windows application, it will mke the php code
less portable, since I have to use installed software
[2003-03-13 06:33:40] pjaleysen at hotmail dot com
Nope, paths, all of that excluded.I tried to put some details below,
comming from http://forums.devshed.com/t55038/s.html (which also deals
with the various path issues. Many others also had a look at it).
At the very end of the forum there is an assumption that it is a WinXP
problem, since win2000 works fine.
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/22662
--
Edit this bug report at http://bugs.php.net/?id=22662&edit=1
#48861 [NEW]: Problem in compiling php on solaris 10 with oracle
From: jpmendoza at pldt dot com dot ph Operating system: Solaris 10 PHP version: 5.2.10 PHP Bug Type: LDAP related Bug description: Problem in compiling php on solaris 10 with oracle Description: Hi I'm trying to install php on solaris 10 with oracle. I'am able to finish ./configure but when I'm going to do a make command it gets an error Reproduce code: --- ./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php/lib --with-libxml-dir=/usr/local --with-zlib=/usr/local --with-xpm-dir=/usr/local --with-mysql=/ramsys_db/mysql4.1 --enable-sigchild --with-mysqli=/ramsys_db/mysql4.1/bin/mysql_config --with-apxs2=/usr/local/apache2/bin/apxs --without-pgsql --with-jpeg-dir=/usr/local/lib --with-zlib-dir=/usr/local/lib --with-gd=/usr/local --enable-mbstring --enable-exif --enable-force-cgi-redirect --with-png-dir=/usr/local/lib --with-curl=/usr/local --with-ldap=/usr/local --with-openssl=/usr/local/ssl --with-gettext --with-pcre-dir=/usr/local --with-freetype-dir=/usr/local/lib --with-mssql=/usr/local/freetds --with-oci8=instantclient,/oracle/app/oracle/product/10.2.0/instantclient_10_2 Actual result: -- main/internal_functions_cli.lo -lrt -lmysqlclient -lsybdb -lldap -llber -liconv -lintl -lgd -lfreetype -lX11 -lXpm -lpng -lz -ljpeg -lcurl -lz -lssl -lcrypto -lresolv -lm -lnsl -lsocket -lgcc -lxml2 -lz -liconv -lm -lsocket -lnsl -lcurl -lidn -lssl -lcrypto -lrt -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz -lxml2 -lz -liconv -lm -lsocket -lnsl -lmysqlclient -lz -lposix4 -lgen -lsocket -lnsl -lm -lclntsh -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl -o sapi/cli/php libtool: link: warning: library `/usr/local/lib/libfreetype.la' was moved. libtool: link: warning: library `/usr/local/lib/libfreetype.la' was moved. ld: fatal: library -lnet: not found ld: fatal: File processing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php' -- Edit bug report at http://bugs.php.net/?id=48861&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48861&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48861&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48861&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48861&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48861&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48861&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48861&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48861&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48861&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48861&r=support Expected behavior: http://bugs.php.net/fix.php?id=48861&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48861&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48861&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48861&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48861&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48861&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48861&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48861&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48861&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48861&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48861&r=mysqlcfg
#22662 [Opn->Bgs]: shell_exec not working on windows XP
ID: 22662
Updated by: paj...@php.net
Reported By: pjaleysen at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 4.3.2-RC
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2009-07-09 01:17:46] bmcclory at gmail dot com
Can someone tell me why the following code will not work in Windows:
system("nmap $host");
Driving me nuts. It works fine on apache servers and apparantly other
IIS servers. I don't know if i'm missing something in php.ini or what.
Other commands can be run from system(), just not nmap.
[2004-08-03 05:57:51] wfrench at prevailnet dot net
I've had the same problem trying to use unzip.exe on XP with php
4.3.8.
Got some interesting results when I tried the dos batch file wrapper
approach...
When I use the batch:
-
@echo hello world
-
it works like a champ.
but when I change the file thusly:
-
unzip
@echo hello world
-
if prints the following:
-
c:\inetpub\wwwroot\svgwork>unzip hello world
-
Obviously it has prepended my command (unzip) with my web directory.
Not so obvious perhaps is what the '>' character is doing in there.
[2004-04-28 20:00:19] clubland at gmx dot net
Hi all,
Platform:
IIS 6.0 / Windows 2003 Server
Problem:
shell_exec etc `s not working
Solution:
check rights on %SYS32%\cmd.exe
Chris
[2003-06-03 17:52:16] spoon at nexdot dot net
This seems very close to what im experiencing.
I am using php 5.0.0-dev (updated about 2 weeks ago), but the problem
has occured for me on 4.x.x versions. I use Windows XP Pro/Windows 2000
Server with my 5.0.0-dev. Apache 2 24
When i use ANY of the MANY methods for passing a system call
System
Shell_exec
Exec
`` (backtick)
Passthru
they all act the same (in this case, as a passthru), UNLESS with a
native dos command (which i tried after reading this bug post).
The functions such as the 2 exec ones and the backticks should not
output anything. I do this:
$string=exec/shell_exec/``;
when calling something such as ping/dir/echo, or any normal dos
command, they work as expected... nothing is output to the browser (or
above the php header have you) unless i do an
echo $string;
When i try to call a program such as gzip, $string has a length of 0
(or null) and the the output from the command appears in my browser (or
above PHP headers if run from command line) without echo'ing. Other
special parts of each system call functions also do not work, such as
exec's array output, which is null unless a native dos command.
[2003-03-15 03:42:47] pjaleysen at hotmail dot com
Executing Windows-based applications work alright, but not the ones
running in DOS. e.g. I am using winzip now instead of pkzip.exe for dos.
Because I have to use windows application, it will mke the php code
less portable, since I have to use installed software
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/22662
--
Edit this bug report at http://bugs.php.net/?id=22662&edit=1
#48862 [NEW]: reload() function for included files
From: php at drinkproject dot com Operating system: All PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: reload() function for included files Description: It would be nice if there were a way to reload included files in scripts the way python can reload includes. I'm not sure if its a complicated endeavor but the ability to do it would be much nicer than restarting the script or re-including and overriding functions at runtime. -- Edit bug report at http://bugs.php.net/?id=48862&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48862&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48862&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48862&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48862&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48862&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48862&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48862&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48862&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48862&r=support Expected behavior: http://bugs.php.net/fix.php?id=48862&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48862&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48862&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48862&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48862&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48862&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48862&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48862&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48862&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48862&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48862&r=mysqlcfg
#48863 [NEW]: Fatal error on main/internal_functions_cli.lo
From: jpmendoza at pldt dot com dot ph Operating system: Solaris 10 PHP version: 5.2.10 PHP Bug Type: Compile Failure Bug description: Fatal error on main/internal_functions_cli.lo Description: Hi I'm trying to install php on solaris 10 with oracle. I'am able to finish ./configure but when I'm going to do a make command it gets an error Reproduce code: --- /configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php/lib --with-libxml-dir=/usr/local --with-zlib=/usr/local --with-xpm-dir=/usr/local --with-mysql=/ramsys_db/mysql4.1 --enable-sigchild --with-mysqli=/ramsys_db/mysql4.1/bin/mysql_config --with-apxs2=/usr/local/apache2/bin/apxs --without-pgsql --with-jpeg-dir=/usr/local/lib --with-zlib-dir=/usr/local/lib --with-gd=/usr/local --enable-mbstring --enable-exif --enable-force-cgi-redirect --with-png-dir=/usr/local/lib --with-curl=/usr/local --with-ldap=/usr/local --with-openssl=/usr/local/ssl --with-gettext --with-pcre-dir=/usr/local --with-freetype-dir=/usr/local/lib --with-mssql=/usr/local/freetds --with-oci8=instantclient,/oracle/app/oracle/product/10.2.0/instantclien t_10_2 Actual result: -- main/internal_functions_cli.lo -lrt -lmysqlclient -lsybdb -lldap -llber -liconv -lintl -lgd -lfreetype -lX11 -lXpm -lpng -lz -ljpeg -lcurl -lz -lssl -lcrypto -lresolv -lm -lnsl -lsocket -lgcc -lxml2 -lz -liconv -lm -lsocket -lnsl -lcurl -lidn -lssl -lcrypto -lrt -lsocket -lnsl -lssl -lcrypto -lsocket -lnsl -ldl -lz -lxml2 -lz -liconv -lm -lsocket -lnsl -lmysqlclient -lz -lposix4 -lgen -lsocket -lnsl -lm -lclntsh -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl -o sapi/cli/php libtool: link: warning: library `/usr/local/lib/libfreetype.la' was moved. libtool: link: warning: library `/usr/local/lib/libfreetype.la' was moved. ld: fatal: library -lnet: not found ld: fatal: File processing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php' -- Edit bug report at http://bugs.php.net/?id=48863&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48863&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48863&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48863&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48863&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48863&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48863&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48863&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48863&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48863&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48863&r=support Expected behavior: http://bugs.php.net/fix.php?id=48863&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48863&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48863&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48863&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48863&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48863&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48863&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48863&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48863&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48863&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48863&r=mysqlcfg
#48852 [Fbk->Opn]: php windows save file to remote share strange access denied
ID: 48852 User updated by: trutas dot ctx at gmail dot com Reported By: trutas dot ctx at gmail dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows Server 2003 x64 IIS6.0 PHP Version: 5.3.0 New Comment: i have installed and configured as recommended at http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/ can i further configure the FastCGI/PHP user anywhere else? IIS user is configured correctly (- home directory with Run as trustedDomain\iisuser) and the destination folder has trustedDomain\iisuser modify and everyone modify . Regards, Previous Comments: [2009-07-08 15:18:27] paj...@php.net Be sure that you configured the user correctly or that the user has the correct access. [2009-07-08 15:15:19] trutas dot ctx at gmail dot com FastCGI [2009-07-08 15:13:50] trutas dot ctx at gmail dot com Note: test.php is located at \\share\intraroot$\site\ i've just tested it further and tryed a few workarounds: - it doesn't work with relative path (since both files are within the same share) "..\\folder\\file.txt"; - it doesn't work with dirname(__FILE__)."\\..\\folder\\file.txt"; - does not work with forward slashes //share/... - the error is "permission denied" even if the destination folder doesn't exist - i've found this because at a time i had wrongly typed share\\intraroot$folder\\file.txt - that does not exist; I'm guessing it has something to do with the home directory in IIS being on a remote share - the production servers are clustered... Every other technology (vbscript, .NET) on IIS accesses the shares normally. [2009-07-08 15:03:05] paj...@php.net How did you install php? FCGI or ISAPI? [2009-07-08 14:01:20] trutas dot ctx at gmail dot com Description: Access denied on a simple file_put_contents - the strange thing is vbscript test file on the same folder works - destination has everyone->modify/read/write. localhost/test.asp localhost/test.php i think it is not relevant but test.php and test.asp are located on the same \\share that we're trying to save the file to (but on a different folder). Apparently it works if we map this share to a local drive and use the local path (eg. E:\ ); file_get_contents works fine. We are using Windows 2003 Server x64, IIS 6.0, PHP 5.3RC04 x64 via MS FastCGI . Reproduce code: --- Expected result: file saved with content "..." Actual result: -- PHP Warning: file_put_contents(\\share\intraroot$\folder\file.txt): failed to open stream: Permission denied in ... -- Edit this bug report at http://bugs.php.net/?id=48852&edit=1
#48864 [NEW]: Fails to "pear upgrade PEAR"
From: hoge at hoge dot jp Operating system: CentOS PHP version: 5.3.0 PHP Bug Type: Unknown/Other Function Bug description: Fails to "pear upgrade PEAR" Description: Fails to "pear upgrade PEAR" ~/php/PEAR/Command/Install.php $dorest and $latest are incorrect values. -- Edit bug report at http://bugs.php.net/?id=48864&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48864&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48864&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48864&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48864&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48864&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48864&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48864&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48864&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48864&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48864&r=support Expected behavior: http://bugs.php.net/fix.php?id=48864&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48864&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48864&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48864&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48864&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48864&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48864&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48864&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48864&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48864&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48864&r=mysqlcfg
