#50867 [Opn->Bgs]: json_encode can't handle empty string keys
ID: 50867
Updated by: j...@php.net
Reported By: r at rcrowley dot org
-Status: Open
+Status: Bogus
Bug Type: JSON related
Operating System: Linux
PHP Version: 5.3.1
New Comment:
It can not work in PHP since you can not have empty object property
name.
Previous Comments:
[2010-01-27 22:32:51] r at rcrowley dot org
Description:
The specification outlined at http://json.org/ indicates that the empty
string is a perfectly valid key in a JSON data structure. JSON
implementations in Python and Ruby agree. PHP appears to go out of its
way to handle the empty string as as key in a non-standard way.
Reproduce code:
---
$ php -r 'echo json_encode(json_decode("{\"\":\"foo\"}")), "\n";'
{"_empty_":"foo"}
$
Expected result:
I expect to see exactly the same output from PHP as seen from Ruby and
Python:
$ ruby -rjson -e 'puts JSON.parse("{\"\":\"foo\"}").to_json'
{"":"foo"}
$ python -c 'import json;
print(json.dumps(json.loads("{\"\":\"foo\"}")))'
{"": "foo"}
$
Actual result:
--
$ php -r 'echo json_encode(json_decode("{\"\":\"foo\"}")), "\n";'
{"_empty_":"foo"}
$
--
Edit this bug report at http://bugs.php.net/?id=50867&edit=1
#50865 [Opn->Bgs]: I'm Not able to create a file using fopen
ID: 50865
Updated by: j...@php.net
Reported By: kv_abhiram at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: Leopard 10.6
PHP Version: 5.2.12
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:
[2010-01-27 20:18:32] kv_abhiram at yahoo dot com
Description:
This is my code where i create a new php file using php.
I'm not able to use fopen to create the file. If i use chmod to change
the permissions. It is not allowing me to do that.
Warning: chmod() [function.chmod]: Operation not permitted
This is the error i get if i use chmod
Reproduce code:
---
//chmod("/Library/WebServer/.../", 777);
$create_file = fopen($file, "w");
$content = "1";
$fname = "/Library/WebServer/.../".$seasonx;
if (is_writable($fname)) {
if (!$hand = fopen($name, 'w+')) {
echo "Cannot open ($fname)";
exit;
}
if (fwrite($hand, $content) === FALSE) {
echo "Cannot write to ($fname)";
exit;
}
echo " success";
fclose($hand);
} else {
echo "The file $fname is not writable";
}
Expected result:
success.
[It should also create a file called 5.php where 5 is the value of the
variable $seasonx at that instance
Actual result:
--
The file /Library/WebServer/...5 is not writable
--
Edit this bug report at http://bugs.php.net/?id=50865&edit=1
#50871 [NEW]: SPL: default value of spl_autoload_extensions() configurable in php.ini
From: julesvanvelzen at gmail dot com Operating system: any PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: SPL: default value of spl_autoload_extensions() configurable in php.ini Description: I expected the default value, which is now '.inc,.php', of spl_autoload_extensions() to be configurable in php.ini, just like the include_path. -- Edit bug report at http://bugs.php.net/?id=50871&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50871&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50871&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50871&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50871&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50871&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50871&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50871&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50871&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50871&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50871&r=support Expected behavior: http://bugs.php.net/fix.php?id=50871&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50871&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50871&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50871&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50871&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50871&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50871&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50871&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50871&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50871&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50871&r=mysqlcfg
#50862 [Opn->Bgs]: php timeout < mysql timeout
ID: 50862 Updated by: j...@php.net Reported By: hajo at clansphere dot de -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windows (any) PHP Version: 5.3.2RC1 New Comment: Yes, you can always set them however you wish. There is no bug here. Previous Comments: [2010-01-27 23:01:22] hajo at clansphere dot de well, i've never seen a script with mysql support that doesn't connect to the mysql server at startup (within lets say 5 seconds). even if so, a good script should check for a working connection on startup to not run into any trouble while proceeding a lot of things before this. changing the connection timeout of mysql might not be the only solution. if php can provide a better error message (e.g. that a mysql connection caused the script to reach the max exec time) it would be fine, too. something close to your solution is going to get into the project files i'm working on, but that is - in my opinion - a workaround for a task that php should handle. at least all i care about is debugging, and that needs matching error reports to whatever happened :) [2010-01-27 18:00:30] ninzya at inbox dot lv What if your script is running for already 50 seconds and you try to connect to mysql, which has connection timeout of 20 seconds? The only thing that might be useful is checking if mysql.connect_timeout > max_execution_time. If so, then alert startup error and abort, since such big timeout does not make any sense. But, what about ini_set() then? I wouldn't care so much about this, you should know your configuration before running scripts on it. [2010-01-27 15:29:42] hajo at clansphere dot de example error msg: Fatal error: Maximum execution time of 30 seconds exceeded in ***.php on line *** [2010-01-27 15:23:28] hajo at clansphere dot de white screen of death may also be possible as a current result [2010-01-27 14:33:09] hajo at clansphere dot de Description: does it make sense to have the following values for those two settings in the default configuration? took me some time to figure out this caused some unexpected errors while i had to setup a new php testing environment. please consider changing the default php.ini settings for the production- and development-example shipped with php-downloads. Reproduce code: --- max_execution_time = 30 mysql.connect_timeout = 60 Expected result: the mysql.connect_timeout should be e.g. 10 or 20 seconds. compared to what it is for mssql.connect_timeout (5 by default) that should be enough and show an mysql timeout error. Actual result: -- php errors that inform about a timeout in php error functions / error handler or something similar to this -- Edit this bug report at http://bugs.php.net/?id=50862&edit=1
#50860 [Opn->Bgs]: exec() duplicates last output line
ID: 50860
Updated by: j...@php.net
Reported By: balazs at obiserver dot hu
-Status: Open
+Status: Bogus
-Bug Type: Unknown/Other Function
+Bug Type: Program Execution
Operating System: Debian Linux
PHP Version: 5.2.12
New Comment:
Thank you for not searching the bug database. This has already been
reported and fixed:
http://bugs.php.net/bug.php?id=50732
Previous Comments:
[2010-01-27 12:35:42] balazs at obiserver dot hu
Description:
Special characters, when exec() return duplicated last line:
( ) [ ] { }
Reproduce code:
---
unset($output);
exec('echo "("', $output, $retval);
var_dump($output);
Expected result:
array(1) {
[0]=>
string(1) "("
}
Actual result:
--
array(2) {
[0]=>
string(1) "("
[1]=>
string(1) "("
}
--
Edit this bug report at http://bugs.php.net/?id=50860&edit=1
#50866 [Opn->Fbk]: stream_socket_enable_crypto() hangs for unnegotiable SSL connections for socket
ID: 50866 Updated by: j...@php.net Reported By: nj506 at zepler dot net -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Linux PHP Version: 5.3.1 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-01-27 22:14:18] nj506 at zepler dot net Description: stream_socket_enable_crypto() hangs for unnegotiable SSL connections for sockets connected in asynchronous mode. Whilst I'm not greatly familiar with the PHP source, I believe it is caused by the following line of code in xp_ssl.c: timeout -= (tve.tv_sec + (float) tve.tv_usec / 100) - (tvs.tv_sec + (float) tvs.tv_usec / 100); I'm often seeing no difference in tve.tv_sec and tvs.tv_sec, and the difference between tve.tv_usec and tvs.tv_usec is typically 4/5 microseconds for the particular scenario I've been debugging. 4/100 deduction from the timeout float results in essentially no change. Therefore the code loops for a very long time. In anycase, a printf on the timeout float see's no change after running for a good length of time. Note: I don't believe this is the same issue as #45808, since this affects client connections, not server connections [+ the area of code I believe to be guilty is specific to client connections] I'd also note that stream_set_blocking appears to have no effect on this area of code - but I'm not sure if thats a bug or not. Reproduce code: --- Expected result: 0/false [after "timeout" seconds] Actual result: -- Hangs pretty much forever. -- Edit this bug report at http://bugs.php.net/?id=50866&edit=1
#50737 [Bgs]: stream_set_blocking creates high cpu usage
ID: 50737 Updated by: j...@php.net Reported By: jason at lentink dot net Status: Bogus Bug Type: Streams related Operating System: Linux PHP Version: 5.2.12 New Comment: Stil a FAIL: Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known Previous Comments: [2010-01-15 10:48:09] jason at lentink dot net Then we go back to the first post and there is a 2 line example of the problem. Reproduce code: --- http://www.grasvezel.nl/media/software/cpuload.txt Here is a complete undressed file which only has the problem. [2010-01-14 12:17:19] j...@php.net I asked for small, complete script NOT for a framework. [2010-01-14 12:13:36] jason at lentink dot net I could provide you guys with a small script bug i can also point you to the place where the problem exists since it happens in Zend Framework. http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Queu e/Stomp/Client/Connection.php The function is used at line 79. What i see on my servers is that when there are simultaneous request made to the same script the problem increases more rapidly. 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/50737 -- Edit this bug report at http://bugs.php.net/?id=50737&edit=1
#50856 [Opn->Fbk]: stream_set_blocking doesn't work with fopen
ID: 50856
Updated by: j...@php.net
Reported By: info at netzkontrast dot com
-Status: Open
+Status: Feedback
Bug Type: Streams related
Operating System: Ubuntu/Suse/Linux
PHP Version: 5.3.1
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-01-27 09:32:09] info at netzkontrast dot com
there is a typo in streamFsockTest.php
instead of: fputs($handle, "GET /streamcontent.php HTTP/1.0\r\nHost:
mp.devel\r\nConnection: keep-alive\r\n\r\n");
it should be:
fputs($handle, "GET /streamcontent.php HTTP/1.0\r\nHost:
localhost\r\nConnection: keep-alive\r\n\r\n");
[2010-01-27 09:28:21] info at netzkontrast dot com
Description:
I tried the following code with different PHP-versions (5.3.1 + 5.2.8)
on different Systems (one ubunto-box and a suse-box
i'm totaly stuck, is there anything i'm missing?
-- i have prepared some testscripts
- streamContent.php (used for testoutput)
- streamfiletest.php -> not working
- streamSocketTest.php -> not working
- streamFsockTest.php -> working
Reproduce code:
---
http://localhost/streamContent.php";, "r");
stream_set_blocking($handle, 0);
while(!feof($handle)) {
echo fread($handle, 100);
echo "-";usleep(8);
} ?>
Expected result:
streamfiletest.php: 0
streamSocketTest.php: . ---. . (etc..)
streamFsockTest.php: . ---. . (etc..)
Actual result:
--
streamfiletest.php: 1
streamSocketTest.php: . -. -. -
streamFsockTest.php: . ---. .
--
Edit this bug report at http://bugs.php.net/?id=50856&edit=1
#50852 [Opn->Fbk]: FastCGI Responder's accept_path_info behavior needs to be optional
ID: 50852
Updated by: j...@php.net
Reported By: merlin at merlinsbox dot net
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: linux, unix
PHP Version: 5.*, 6
New Comment:
Wouldn't setting cgi.fix_pathinfo = 0 do the same thing?
Previous Comments:
[2010-01-27 02:13:35] merlin at merlinsbox dot net
Yes, I realize at the top I only mention 5.2.12, and that I posted this
in 5.3.1 -- I also linked to the patch for 5.3.1 (and there is a patch
for 5.2.12 in that directory as well). This is an issue in both
versions and will continue to be in future versions, unless the patch is
accepted.
Apologies for overlooking that first sentence.
[2010-01-27 02:05:53] merlin at merlinsbox dot net
Description:
I setup PHP 5.2.12 and started 5 fastcgi processes on nginx with a
basic location directive dispatching all URIs ending with the PHP
extension to PHP's fastcgi responder daemon. I also configured it to
receive SCRIPT_FILENAME (required by PHP) as a concatenation of
$document_root and the matched URI (which must end in '.php') and
PATH_INFO as the requested URI. No other fastcgi parameters were used.
I created a file in the document root thusly: `echo "" > test.txt`. I requested /test.txt and
was presented with the source code. Next, I requested /test.txt/.php
and the code executed, resulting in the following output (truncated for
relevence):
["SCRIPT_FILENAME"]=>
string(31) "/path/to/document_root/test.txt"
["ORIG_SCRIPT_FILENAME"]=>
string(37) "/path/to/document_root/test.txt/1.php"
Reproduce code:
---
# NginX configuration for PHP extensions
location ~ \.php$ {
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php-responder; # php- replaced with python- for python
}
# PHP code and request
echo "" > test.txt && fetch
http://localhost/test.txt/.php
# Python WSGI app
def simple_app(environ, start_response):
"""Simplest possible application object"""
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['', '\n'.join(['%s: %s' % (k, v) for k,v in
environ.items()]), '']
Expected result:
I expected PHP to return "no input file specified" such as when I
request /1.php on the server (which does not exist). I did not expect
PHP to travel up the path looking for PHP files to execute, and I would
like to disable this feature.
Please consider accepting the patch by Joey Smith located at:
http://patch.joeysmith.com/acceptpathinfo-5.3.1.patch (and other
versions in the root). This patch allows me to turn off this feature
but keeps the current behavior as default, which is surely best for all
parties. The best part is the patch is small, trivial even, so there
should be little to worry about in bringing it in.
PHP's accept_path_info behavior makes perfect sense for CGI, where it
is implicit that there is a direct relationship between a URI location
and a file. PHP now is a FastCGI responder, and I hear doesn't even
support plain CGI any longer. FastCGI is not a direct analogue of CGI,
though it may emulate it in the responder role. At any rate, though
FastCGI extends CGI, and some FastCGI apps *can* run in CGI, FastCGI is
not being used these days as a direct analogue of CGI by other
languages. SCRIPT_FILENAME is a PHP-specific FastCGI parameter not
mentioned anywhere in the FastCGI specification (because it is not
required that a file be executed by a responder). Furthermore, while I
understand that FastCGI and Apache have some history, many other servers
have also implemented FastCGI support and they do not necessarily make
the same assumptions Apache does. Relying on the webserver to stat URIs
in a CGI environment makes perfect sense; however, if your webserver
doesn't support CGI at all, but only FastCGI, it makes none.
To illustrate this point, I created a simple python fastcgi responder
using flup and the hello world WSGI application modified to output the
environment (provided below). Then, instead of passing php extensions
to PHP's fastcgi, I passed it to my python application along with
SCRIPT_FILENAME as before. My python application successfully returns
to me the unchanged SCRIPT_FILENAME from its environment, because
neither my webserver nor my responder make any assumptions about URLs
corresponding to files.
Actual result:
--
To sum up, forcing my webserver to treat PHP's FastCGI responder
differently from other FastCGI responders is distasteful, and whether
you agree with my needs or not, there is an already completed patch
which maintains backwards compatibility that I and many other people
will be very thankful for. PHP isn't going anywhere and neither is
Nginx (growing
#18590 [Com]: Fatal error: Cannot redeclare upon reload
ID: 18590
Comment by: krajicek at centrum dot sk
Reported By: armageddon at raydan dot de
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WinXP Pro
PHP Version: 5.0.0-dev
New Comment:
confirming the same (similar) issue - if file with function definition
is included twice (via include) in the script run it throws Fatal Error
- Cannot redeclare functionXY. on reload the Fatal Error is gone. on any
change to script or PHP related server config is error back again. fix
for the error message is to use include_once instead of include.
but this can cause problems by not displaying error messages all the
times.
OS: FreeBSD 6.3-STABLE-20080418.1500
Apache 2.0 Handler (20051115)
PHP Version 5.2.12
Previous Comments:
[2009-02-04 20:44:55] greg at pwsdb dot com
Tenative Conclusion: php has already loaded and defined everything.
pear should not be re-loading or re-defining anything.
this is the conflict.
[the possibility of any exception(s) is the source of the conflict]
[2009-02-04 17:31:51] greg at pwsdb dot com
system notes:
zencart Version 1.3.8a
Server OS: Linux 2.6.18-53.1.14.el5.centos.plus
HTTP Server: Apache/2.2.3 (CentOS)
PHP Version: 5.1.6 (Zend: 2.1.0)
[2009-02-04 17:22:29] greg at pwsdb dot com
PPS
I now remember a few months ago I added code to a pgm I had written
to access another $_POST variable. I also moved the call to my program
(in includes/modules/pages/checkout_confirmation/header_php.php) down
past some error checking. I immediately started getting "Fatal
error:"
messages about things being defined twice throughout many (untouched)
zc pgms.:
i 'undid' things but could not stop it until I had changed all the
require() calls to require_once()
Fatal error: Cannot redeclare class order in
/.../includes/classes/order.php on line 1018
Fatal error: Cannot redeclare class shipping in
/.../includes/classes/shipping.php on line 178
Fatal error: Cannot redeclare class order_total in
/.../includes/classes/order_total.php on line 232
Fatal error: Cannot redeclare class payment in
/.../includes/classes/payment.php on line 255
Fatal error: Cannot redeclare class cc_validation in
/.../includes/classes/cc_validation.php on line 184
and more.
again, it has to be "php vs. pear" (?)
this was in "PHP Version 5.1.6". From the comments above, it must
still be in Ver. 5.2.4
[2009-02-04 05:22:00] greg at pwsdb dot com
PPS
no, it is not working in the login page now, either.
Same experience as the others above?:
"First it works, then it doesn't."
[2009-02-04 03:46:35] greg at pwsdb dot com
PS
This only happened within a checkout page of ZenCart ("part 3 of 3")
and not another (not the login page) ... I don't know enough about zc
to know what the significant difference is.
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/18590
--
Edit this bug report at http://bugs.php.net/?id=18590&edit=1
#50873 [NEW]: Undocumented incompatible change in ip2long()
From: rthompson at mx dot itmedia dot co dot jp
Operating system: Fedora
PHP version: 5.2.12
PHP Bug Type: Network related
Bug description: Undocumented incompatible change in ip2long()
Description:
Through at least version 5.2.9, ip2long() returned the input value
unchanged for valid integer IP address inputs.
Since at least version 5.2.11, ip2long() returns "false" for all
integer IP address inputs. (5.2.12 and 5.2.11 tested, 5.2.10
untested).
Our application has been utilizing this function for the past three
years, originally deployed on 5.1.(6?). Since both string and long IP
addresses returned valid long results, the function returned valid
results regardless of the format. This is useful when importing from
data sources containing inconsistent representations.
The specification of the function's valid input and outputs has been
changed and made more restrictive, yet there is no changelog entry
documenting this incompatible change.
Reproduce code:
---
---
>From manual page: function.ip2long#Changelog
---
echo ip2long("73.150.2.210");
echo ip2long(1234567890);
Expected result:
Expected return value (through 5.2.9) is the integer "1234567890" for
both inputs.
Actual result:
--
Actual return value (since 5.2.11 or .10) is "false" for the long input,
correct for the string input.
--
Edit bug report at http://bugs.php.net/?id=50873&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50873&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50873&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50873&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50873&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50873&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50873&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50873&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50873&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50873&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50873&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50873&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50873&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50873&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50873&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50873&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50873&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50873&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50873&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50873&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50873&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50873&r=mysqlcfg
#45577 [Com]: Integer overflow connecting to https soap service
ID: 45577
Comment by: sgbeal at googlemail dot com
Reported By: contact at reubidium dot com
Status: No Feedback
Bug Type: SOAP related
Operating System: Mac OS X 10.5.4
PHP Version: 5.2.6
New Comment:
i'm seeing this same problem on Linux:
Linux myhostname 2.6.18-164.9.1.el5xen #1 SMP Wed Dec 9 03:35:42 EST
2009 x86_64 x86_64 x86_64 GNU/Linux
but the allocation value varies from the original report:
"PHP Fatal error: Uncaught SoapFault exception: [Client] Possible
integer overflow in memory allocation (2781995460 * 4 + 0)"
that happens on each call to the SoapClient ctor.
My app runs just fine via the CLI, but not from under Apache. i'm
trying to port a CLI app to an AJAX interface, and this bug is making
that impossible.
~> php --version
PHP 5.1.6 (cli) (built: Feb 26 2009 07:01:12)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
~> free
free
total used free sharedbuffers
cached
Mem: 1433600052649049071096 0 676488
1421936
-/+ buffers/cache:3166480 11169520
Swap: 2097144 02097144
Previous Comments:
[2008-07-30 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-07-22 22:34:11] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-07-21 10:02:55] contact at reubidium dot com
I also added this as a bug over at MacPorts.org:
https://trac.macports.org/ticket/16036
[2008-07-21 09:55:59] contact at reubidium dot com
Description:
With version 5.2.6 of PHP installed from MacPorts, I was saddened to
find that all the SOAP calls in my application were suddenly broken,
kicking up the following PHP Fatal error:
Uncaught SoapFault exception: [Client] Possible integer overflow in
memory allocation (3819152321 * 4 + 0)
This app was working fine in my Entropy PHP 5.2.5 package, and
switching back to that all my soap calls were once again working fine.
Since all the calls were via https, I thought this would be a good
first thing to try changing. so I found a public http soap service and
ran a quick test, and things worked just fine then.
I should mention that I have the max memory setting in my php.ini set
at 256M currently, but I had tried increasing it to 512M with no
effect.. not that that should matter, this is a small soap request I am
dealing with.
Reproduce code:
---
$client = new
SoapClient('https://api.store.sinatra.iventa.com/UserService.asmx?WSDL');
Expected result:
A valid SOAP client object
Actual result:
--
PHP Fatal error: Uncaught SoapFault exception: [Client] Possible
integer overflow in memory allocation (3819152321 * 4 + 0)
--
Edit this bug report at http://bugs.php.net/?id=45577&edit=1
#50856 [Com]: stream_set_blocking doesn't work with fopen
ID: 50856
Comment by: info at netzkontrast dot com
Reported By: info at netzkontrast dot com
Status: Feedback
Bug Type: Streams related
Operating System: Ubuntu/Suse/Linux
PHP Version: 5.3.1
New Comment:
fopen is still blocking with
local files ('wrapper_type' => string 'plainfile'
and URL's 'wrapper_type' => string 'cURL'
looks like stream_set_blocking gets totaly ignored from fopen
while non_blocking reads still work with fsockopen, and reading from
STDIN
Previous Comments:
[2010-01-28 08:45:08] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-01-27 09:32:09] info at netzkontrast dot com
there is a typo in streamFsockTest.php
instead of: fputs($handle, "GET /streamcontent.php HTTP/1.0\r\nHost:
mp.devel\r\nConnection: keep-alive\r\n\r\n");
it should be:
fputs($handle, "GET /streamcontent.php HTTP/1.0\r\nHost:
localhost\r\nConnection: keep-alive\r\n\r\n");
[2010-01-27 09:28:21] info at netzkontrast dot com
Description:
I tried the following code with different PHP-versions (5.3.1 + 5.2.8)
on different Systems (one ubunto-box and a suse-box
i'm totaly stuck, is there anything i'm missing?
-- i have prepared some testscripts
- streamContent.php (used for testoutput)
- streamfiletest.php -> not working
- streamSocketTest.php -> not working
- streamFsockTest.php -> working
Reproduce code:
---
http://localhost/streamContent.php";, "r");
stream_set_blocking($handle, 0);
while(!feof($handle)) {
echo fread($handle, 100);
echo "-";usleep(8);
} ?>
Expected result:
streamfiletest.php: 0
streamSocketTest.php: . ---. . (etc..)
streamFsockTest.php: . ---. . (etc..)
Actual result:
--
streamfiletest.php: 1
streamSocketTest.php: . -. -. -
streamFsockTest.php: . ---. .
--
Edit this bug report at http://bugs.php.net/?id=50856&edit=1
#18590 [Com]: Fatal error: Cannot redeclare upon reload
ID: 18590 Comment by: krajicek at centrum dot sk Reported By: armageddon at raydan dot de Status: No Feedback Bug Type: Scripting Engine problem Operating System: WinXP Pro PHP Version: 5.0.0-dev New Comment: ...adding some more comments to my above. here is the simplest sample i've created: redeclare_issue_main.php: - - redeclare_issue_test.inc.php: - - running the redeclare_issue_main.php code after any change (e.g. add blank line) to redeclare_issue_test.inc.php will bring up: Fatal error: Cannot redeclare sendmail1() in redeclare_issue_test.inc.php on line 2 upon browser reload the error is gone. cannot confirm my previous assumption that also change in PHP related server config cause that the error reappears. OS: FreeBSD 6.3-STABLE-20080418.1500 Apache 2.0 Handler (20051115) PHP Version 5.2.12 Previous Comments: [2010-01-28 09:27:38] krajicek at centrum dot sk confirming the same (similar) issue - if file with function definition is included twice (via include) in the script run it throws Fatal Error - Cannot redeclare functionXY. on reload the Fatal Error is gone. on any change to script or PHP related server config is error back again. fix for the error message is to use include_once instead of include. but this can cause problems by not displaying error messages all the times. OS: FreeBSD 6.3-STABLE-20080418.1500 Apache 2.0 Handler (20051115) PHP Version 5.2.12 [2009-02-04 20:44:55] greg at pwsdb dot com Tenative Conclusion: php has already loaded and defined everything. pear should not be re-loading or re-defining anything. this is the conflict. [the possibility of any exception(s) is the source of the conflict] [2009-02-04 17:31:51] greg at pwsdb dot com system notes: zencart Version 1.3.8a Server OS: Linux 2.6.18-53.1.14.el5.centos.plus HTTP Server: Apache/2.2.3 (CentOS) PHP Version: 5.1.6 (Zend: 2.1.0) [2009-02-04 17:22:29] greg at pwsdb dot com PPS I now remember a few months ago I added code to a pgm I had written to access another $_POST variable. I also moved the call to my program (in includes/modules/pages/checkout_confirmation/header_php.php) down past some error checking. I immediately started getting "Fatal error:" messages about things being defined twice throughout many (untouched) zc pgms.: i 'undid' things but could not stop it until I had changed all the require() calls to require_once() Fatal error: Cannot redeclare class order in /.../includes/classes/order.php on line 1018 Fatal error: Cannot redeclare class shipping in /.../includes/classes/shipping.php on line 178 Fatal error: Cannot redeclare class order_total in /.../includes/classes/order_total.php on line 232 Fatal error: Cannot redeclare class payment in /.../includes/classes/payment.php on line 255 Fatal error: Cannot redeclare class cc_validation in /.../includes/classes/cc_validation.php on line 184 and more. again, it has to be "php vs. pear" (?) this was in "PHP Version 5.1.6". From the comments above, it must still be in Ver. 5.2.4 [2009-02-04 05:22:00] greg at pwsdb dot com PPS no, it is not working in the login page now, either. Same experience as the others above?: "First it works, then it doesn't." 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/18590 -- Edit this bug report at http://bugs.php.net/?id=18590&edit=1
#50875 [NEW]: Objects loaded using PDO are *empty* when the __construct method is called
From: contact at weirdog dot com
Operating system: Linux
PHP version: 5.2.12
PHP Bug Type: PDO related
Bug description: Objects loaded using PDO are *empty* when the __construct
method is called
Description:
Objects loaded using PDO are *empty* (as in "they have no properties")
when the __construct() method is called.
This was not the case before version 5.2.12. Usualy, properties loaded
from the database where already applyed when the __construct() method was
called.
This is really annoying since further initialisation during the
__construct() method is now impossible.
Reproduce code:
---
class WdActiveRecord
{
public function __construct()
{
var_dump($this);
}
}
$stmt = $db->query('SELECT * FROM nodes WHERE nid = 498');
$stmt->fetchObject('WdActiveRecord');
Expected result:
object(site_pages_WdActiveRecord)[68]
public 'nid' => string '498' (length=3)
public 'parentid' => string '0' (length=1)
public 'pattern' => string 'about' (length=5)
public 'weight' => string '9' (length=1)
public 'layout' => string 'page' (length=5)
public 'location' => string '' (length=22)
public 'is_navigation_excluded' => string '0' (length=1)
public 'is_restricted' => string '0' (length=1)
public 'uid' => string '9' (length=1)
public 'title' => string 'À propos' (length=16)
public 'slug' => string 'apropos' (length=15)
public 'created' => string '2009-11-29 18:13:17' (length=19)
public 'modified' => string '2009-11-29 18:17:29' (length=19)
public 'constructor' => string 'site.pages' (length=10)
public 'is_online' => string '1' (length=1)
public 'language' => string '' (length=0)
public 'tnid' => string '0' (length=1)
public 'is_translation_deprecated' => string '0' (length=1)
Actual result:
--
object(site_pages_WdActiveRecord)#68 (0) { }
--
Edit bug report at http://bugs.php.net/?id=50875&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50875&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50875&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50875&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50875&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50875&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50875&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50875&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50875&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50875&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50875&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50875&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50875&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50875&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50875&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50875&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50875&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50875&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50875&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50875&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50875&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50875&r=mysqlcfg
#44093 [NoF->Opn]: ignore_user_abort() sometimes do not work !
ID: 44093 User updated by: max at tehnomir dot com dot ua Reported By: max at tehnomir dot com dot ua -Status: No Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.6.20.2 PHP Version: 5.2.5 New Comment: Two years past. no result :( Previous Comments: [2008-09-18 07:53:03] taworn at yahoo dot com I can confirm this bug, too. Even with ignore_user_abort(TRUE). However, after I changed from using PHP as CGI to Apache module, its work. Taworn T. [2008-07-17 12:16:32] marcus dot mueller at grintsch dot com I can confirm this bug still being reproducible in PHP 5.2.6 on Linux 2.6.24 and above. Any news? [2008-04-26 13:50:13] pcdinh at gmail dot com This bug remains still. I can reproduce it on PHP 5.2.5 and latest PHP 5.3dev (Windows XP SP2) Maximum execution time of 60 seconds exceeded in D:\webroot\bugs\44093.php [2008-04-02 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-03-25 14:01:43] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi 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/44093 -- Edit this bug report at http://bugs.php.net/?id=44093&edit=1
#50852 [Com]: FastCGI Responder's accept_path_info behavior needs to be optional
ID: 50852
Comment by: merlin at merlinsbox dot net
Reported By: merlin at merlinsbox dot net
Status: Feedback
Bug Type: CGI related
Operating System: linux, unix
PHP Version: 5.*, 6
New Comment:
Yes, thanks jani; 'cgi.fix_pathinfo = 0' is the behavior we're looking
for, apparently; however, I am confused at least by the explanation for
it because in no case whatsoever did I pass anything except
SCRIPT_FILENAME to PHP.
Two days in ##php, a patch, and two bug reports before someone knew.
Thanks again!
Curious if this patch provided above has any merit on its own. I
imagine it accomplishes the same thing as cgi.fix_pathinfo in another
place in the code (or the author would have said OH here is the
setting). Perhaps it is in a better place (or perhaps a worse one!).
Previous Comments:
[2010-01-28 08:58:19] j...@php.net
Wouldn't setting cgi.fix_pathinfo = 0 do the same thing?
[2010-01-27 02:13:35] merlin at merlinsbox dot net
Yes, I realize at the top I only mention 5.2.12, and that I posted this
in 5.3.1 -- I also linked to the patch for 5.3.1 (and there is a patch
for 5.2.12 in that directory as well). This is an issue in both
versions and will continue to be in future versions, unless the patch is
accepted.
Apologies for overlooking that first sentence.
[2010-01-27 02:05:53] merlin at merlinsbox dot net
Description:
I setup PHP 5.2.12 and started 5 fastcgi processes on nginx with a
basic location directive dispatching all URIs ending with the PHP
extension to PHP's fastcgi responder daemon. I also configured it to
receive SCRIPT_FILENAME (required by PHP) as a concatenation of
$document_root and the matched URI (which must end in '.php') and
PATH_INFO as the requested URI. No other fastcgi parameters were used.
I created a file in the document root thusly: `echo "" > test.txt`. I requested /test.txt and
was presented with the source code. Next, I requested /test.txt/.php
and the code executed, resulting in the following output (truncated for
relevence):
["SCRIPT_FILENAME"]=>
string(31) "/path/to/document_root/test.txt"
["ORIG_SCRIPT_FILENAME"]=>
string(37) "/path/to/document_root/test.txt/1.php"
Reproduce code:
---
# NginX configuration for PHP extensions
location ~ \.php$ {
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php-responder; # php- replaced with python- for python
}
# PHP code and request
echo "" > test.txt && fetch
http://localhost/test.txt/.php
# Python WSGI app
def simple_app(environ, start_response):
"""Simplest possible application object"""
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['', '\n'.join(['%s: %s' % (k, v) for k,v in
environ.items()]), '']
Expected result:
I expected PHP to return "no input file specified" such as when I
request /1.php on the server (which does not exist). I did not expect
PHP to travel up the path looking for PHP files to execute, and I would
like to disable this feature.
Please consider accepting the patch by Joey Smith located at:
http://patch.joeysmith.com/acceptpathinfo-5.3.1.patch (and other
versions in the root). This patch allows me to turn off this feature
but keeps the current behavior as default, which is surely best for all
parties. The best part is the patch is small, trivial even, so there
should be little to worry about in bringing it in.
PHP's accept_path_info behavior makes perfect sense for CGI, where it
is implicit that there is a direct relationship between a URI location
and a file. PHP now is a FastCGI responder, and I hear doesn't even
support plain CGI any longer. FastCGI is not a direct analogue of CGI,
though it may emulate it in the responder role. At any rate, though
FastCGI extends CGI, and some FastCGI apps *can* run in CGI, FastCGI is
not being used these days as a direct analogue of CGI by other
languages. SCRIPT_FILENAME is a PHP-specific FastCGI parameter not
mentioned anywhere in the FastCGI specification (because it is not
required that a file be executed by a responder). Furthermore, while I
understand that FastCGI and Apache have some history, many other servers
have also implemented FastCGI support and they do not necessarily make
the same assumptions Apache does. Relying on the webserver to stat URIs
in a CGI environment makes perfect sense; however, if your webserver
doesn't support CGI at all, but only FastCGI, it makes none.
To illustrate this point, I created a simple python fastcgi responder
using flup and the hello world WSGI application modified to output the
environment (provided below). Then, instead of passing php extensions
t
#50852 [Fbk->Csd]: FastCGI Responder's accept_path_info behavior needs to be optional
ID: 50852
User updated by: merlin at merlinsbox dot net
Reported By: merlin at merlinsbox dot net
-Status: Feedback
+Status: Closed
Bug Type: CGI related
Operating System: linux, unix
PHP Version: 5.*, 6
New Comment:
Feature exists, no one, not even Rasmus, knew, except jani. Jani for
President.
Previous Comments:
[2010-01-28 22:29:56] merlin at merlinsbox dot net
Yes, thanks jani; 'cgi.fix_pathinfo = 0' is the behavior we're looking
for, apparently; however, I am confused at least by the explanation for
it because in no case whatsoever did I pass anything except
SCRIPT_FILENAME to PHP.
Two days in ##php, a patch, and two bug reports before someone knew.
Thanks again!
Curious if this patch provided above has any merit on its own. I
imagine it accomplishes the same thing as cgi.fix_pathinfo in another
place in the code (or the author would have said OH here is the
setting). Perhaps it is in a better place (or perhaps a worse one!).
[2010-01-28 08:58:19] j...@php.net
Wouldn't setting cgi.fix_pathinfo = 0 do the same thing?
[2010-01-27 02:13:35] merlin at merlinsbox dot net
Yes, I realize at the top I only mention 5.2.12, and that I posted this
in 5.3.1 -- I also linked to the patch for 5.3.1 (and there is a patch
for 5.2.12 in that directory as well). This is an issue in both
versions and will continue to be in future versions, unless the patch is
accepted.
Apologies for overlooking that first sentence.
[2010-01-27 02:05:53] merlin at merlinsbox dot net
Description:
I setup PHP 5.2.12 and started 5 fastcgi processes on nginx with a
basic location directive dispatching all URIs ending with the PHP
extension to PHP's fastcgi responder daemon. I also configured it to
receive SCRIPT_FILENAME (required by PHP) as a concatenation of
$document_root and the matched URI (which must end in '.php') and
PATH_INFO as the requested URI. No other fastcgi parameters were used.
I created a file in the document root thusly: `echo "" > test.txt`. I requested /test.txt and
was presented with the source code. Next, I requested /test.txt/.php
and the code executed, resulting in the following output (truncated for
relevence):
["SCRIPT_FILENAME"]=>
string(31) "/path/to/document_root/test.txt"
["ORIG_SCRIPT_FILENAME"]=>
string(37) "/path/to/document_root/test.txt/1.php"
Reproduce code:
---
# NginX configuration for PHP extensions
location ~ \.php$ {
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php-responder; # php- replaced with python- for python
}
# PHP code and request
echo "" > test.txt && fetch
http://localhost/test.txt/.php
# Python WSGI app
def simple_app(environ, start_response):
"""Simplest possible application object"""
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['', '\n'.join(['%s: %s' % (k, v) for k,v in
environ.items()]), '']
Expected result:
I expected PHP to return "no input file specified" such as when I
request /1.php on the server (which does not exist). I did not expect
PHP to travel up the path looking for PHP files to execute, and I would
like to disable this feature.
Please consider accepting the patch by Joey Smith located at:
http://patch.joeysmith.com/acceptpathinfo-5.3.1.patch (and other
versions in the root). This patch allows me to turn off this feature
but keeps the current behavior as default, which is surely best for all
parties. The best part is the patch is small, trivial even, so there
should be little to worry about in bringing it in.
PHP's accept_path_info behavior makes perfect sense for CGI, where it
is implicit that there is a direct relationship between a URI location
and a file. PHP now is a FastCGI responder, and I hear doesn't even
support plain CGI any longer. FastCGI is not a direct analogue of CGI,
though it may emulate it in the responder role. At any rate, though
FastCGI extends CGI, and some FastCGI apps *can* run in CGI, FastCGI is
not being used these days as a direct analogue of CGI by other
languages. SCRIPT_FILENAME is a PHP-specific FastCGI parameter not
mentioned anywhere in the FastCGI specification (because it is not
required that a file be executed by a responder). Furthermore, while I
understand that FastCGI and Apache have some history, many other servers
have also implemented FastCGI support and they do not necessarily make
the same assumptions Apache does. Relying on the webserver to stat URIs
in a CGI environment makes perfect sense; however, if your webserver
doesn't support CGI at all, but only FastCG
#49267 [Com]: Linking fails for iconv: "Undefined symbols: _libiconv"
ID: 49267 Comment by: yux87 at hotmail dot com Reported By: s dot rost at ewerk dot com Status: No Feedback Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: Okay, here's the result how I made it work against my environment and php version after a few times of failure in compiling: -- Steps -- 1. The only thing I tried to make it work was to hack the iconv.c as the patch above. ie. manually remove the #ifdef HAVE_LIBICONV, etc. lines. 2. Do a re-configure, re-make. - Result - ./configure --with-iconv-dir=/usr [Pass] ./make [Pass] ./make test [Okay, didn't notice any fail with iconv, not sure it's been tested though] -- Configuration -- Snow Leopard, with XCode. I did a fresh install rather than upgrade from the old 10.5 version, so I guess it could be the reason I didn't suffer the multiple iconv lib problem as some descriptions above. PHP version: 5.3.1 - 19 Nov 2009 release from the download page So I think the problem here is just some need to change the iconv.c code a bit. Hope this works for you, too. I also tried compiling with my macport iconv library(coz this'd be the actual one I'm going to use), there's no problem working with it too. Previous Comments: [2010-01-03 11:48:35] iongion at yahoo dot com My system is a SNOW LEOPARD 10.6.2 I think we have a final solution. All these problems are generated because the Makefile is confused by the existence of multiple iconv library installations, but not only this. Fixing iconv (please note that these are pretty subjective, but they are a good start) Needed elements: 1) gettext - http://ftp.gnu.org/pub/gnu/gettext/gettext-0.17.tar.gz 2) iconv - http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz Unpack both libraries, before running configure, prepare your environment as follows: (i assume you have latest xcode) export MACOSX_DEPLOYMENT_TARGET=10.6; export CFLAGS="-arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"; export CCFLAGS="-arch i386 -arch x86_64 -g -Os -pipe"; export CXXFLAGS="-arch i386 -arch x86_64 -g -Os -pipe" LDFLAGS="-arch i386 -arch x86_64 -bind_at_load" and then run configure in gettext, leave prefix as it is, make & make install; NOW, building iconv will replace existing iconv from apple(it shouldn't break anything) ./configure --prefix=/usr --enable-shared --enable-static then: make sudo make install This did it, what i managed to achieve: 1) Replace php 5.3.0 that comes with Snow Leopard, with php 5.3.1 2) Replace php 5.3.0 that comes with Snow Leopard, with php 5.2.12 Managed to install pecl extensions, apc, xdebug, uploadprogress, ming I am now on php 5.2.12 as i do drupal development and there are some module issues with php 5.3, but you could easily replace Snow Leo's php 5.3.0 with 5.3.1 and have your own pecl extensions/features enables Bellow are build scripts that i use to compile php 5.3.1 and php 5.2.12 1) 5.2.12 -> http://dpaste.com/hold/140511/ 2) 5.3.1 -> http://dpaste.com/hold/140512/ Good luck and hopefully php will get some better less confused build scripts. This the link that made me think and search more http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-compiling-php-528/ I have a little more than 0 knowledge of unix build tools, make, conf, gcc ... i am a php developer, excuse the non-initiated terms. [2010-01-02 13:41:56] iongion at yahoo dot com This is the output of make at its last step before throwing the hell http://dpaste.com/hold/140147/ [2010-01-02 13:36:06] iongion at yahoo dot com It does not work for me, same Snow Leopard I've added all possible combination of fixes Using the latest php snapshot php5.3-201001012330 http://www.opensource.apple.com/source/apache_mod_php/apache_mod_php- 53/patches/iconv.patch Here is the build script ./configure \ '--with-iconv-dir=/usr' \ '--prefix=/usr' \ '--mandir=/usr/share/man' \ '--infodir=/usr/share/info' \ '--sysconfdir=/private/etc' \ '--with-apxs2=/usr/sbin/apxs' \ '--enable-cli' \ '--with-config-file-path=/etc' \ '--with-libxml-dir=/usr' \ '--with-openssl=/usr' \ '--with-kerberos=/usr' \ '--with-zlib=/usr' \ '--enable-bcmath' \ '--with-bz2=/usr' \ '--enable-calendar' \ '--with-curl=/usr' \ '--enable-exif' \ '--enable-ftp' \ '--with-gd' \ '--with-jpeg-dir=/usr/local' \ '--with-png-dir=/usr/local' \ '--enable-gd-native-ttf' \ '--with-ldap=/usr' \ '--with-ldap-sasl=/usr' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--with-pdo-mysql=mysqlnd' \ '--with-iodbc=/usr' \ '--enable-shmop' \ '--with-snmp=/usr' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sy
#50416 [Com]: PROCEDURE db.myproc can't return a result set in the given context
ID: 50416 Comment by: ermesto_vargas at yahoo dot com Reported By: ernesto_vargas at yahoo dot com Status: Assigned Bug Type: MySQL related Operating System: * PHP Version: 5.3, 6 Assigned To: mysql New Comment: Any news on these bug? Previous Comments: [2010-01-12 21:11:41] ermesto_vargas at yahoo dot com Any ETA on when this issue will be review? j...@php.net have clearly assert that the error occur on PHP 5.3+ [2010-01-07 10:16:34] j...@php.net Uwe, please notice my comment: It _works_ with PHP 5.2.x but NOT with 5.3, ergo, there's a bug in _PHP_ mysql stuff.. [2010-01-05 14:53:47] ernesto_vargas at yahoo dot com @u...@php.net; The store procedure code is a simple Hello World. Code is below. DELIMITER $$ CREATE PROCEDURE `myproc`() BEGIN SELECT 'it works!'; END$$ [2010-01-04 10:51:19] u...@php.net This may be a valid error message, http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html . What's the code of the SP? [2009-12-17 08:23:52] j...@php.net Works with latest PHP 5.2, fails with 5.3+. 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/50416 -- Edit this bug report at http://bugs.php.net/?id=50416&edit=1
#50852 [Csd]: FastCGI Responder's accept_path_info behavior needs to be optional
ID: 50852
Updated by: j...@php.net
Reported By: merlin at merlinsbox dot net
Status: Closed
Bug Type: CGI related
Operating System: linux, unix
PHP Version: 5.*, 6
New Comment:
For the record, I saw cgi.fix_pathinfo but didn't really understand
the documentation on it - probably my fault. The patch was thrown
together mainly as a personal exercise in understanding the problem
these folks were reporting - I see no reason it should be accepted
into the mainline.
Previous Comments:
[2010-01-28 22:47:20] merlin at merlinsbox dot net
Feature exists, no one, not even Rasmus, knew, except jani. Jani for
President.
[2010-01-28 22:29:56] merlin at merlinsbox dot net
Yes, thanks jani; 'cgi.fix_pathinfo = 0' is the behavior we're looking
for, apparently; however, I am confused at least by the explanation for
it because in no case whatsoever did I pass anything except
SCRIPT_FILENAME to PHP.
Two days in ##php, a patch, and two bug reports before someone knew.
Thanks again!
Curious if this patch provided above has any merit on its own. I
imagine it accomplishes the same thing as cgi.fix_pathinfo in another
place in the code (or the author would have said OH here is the
setting). Perhaps it is in a better place (or perhaps a worse one!).
[2010-01-28 08:58:19] j...@php.net
Wouldn't setting cgi.fix_pathinfo = 0 do the same thing?
[2010-01-27 02:13:35] merlin at merlinsbox dot net
Yes, I realize at the top I only mention 5.2.12, and that I posted this
in 5.3.1 -- I also linked to the patch for 5.3.1 (and there is a patch
for 5.2.12 in that directory as well). This is an issue in both
versions and will continue to be in future versions, unless the patch is
accepted.
Apologies for overlooking that first sentence.
[2010-01-27 02:05:53] merlin at merlinsbox dot net
Description:
I setup PHP 5.2.12 and started 5 fastcgi processes on nginx with a
basic location directive dispatching all URIs ending with the PHP
extension to PHP's fastcgi responder daemon. I also configured it to
receive SCRIPT_FILENAME (required by PHP) as a concatenation of
$document_root and the matched URI (which must end in '.php') and
PATH_INFO as the requested URI. No other fastcgi parameters were used.
I created a file in the document root thusly: `echo "" > test.txt`. I requested /test.txt and
was presented with the source code. Next, I requested /test.txt/.php
and the code executed, resulting in the following output (truncated for
relevence):
["SCRIPT_FILENAME"]=>
string(31) "/path/to/document_root/test.txt"
["ORIG_SCRIPT_FILENAME"]=>
string(37) "/path/to/document_root/test.txt/1.php"
Reproduce code:
---
# NginX configuration for PHP extensions
location ~ \.php$ {
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php-responder; # php- replaced with python- for python
}
# PHP code and request
echo "" > test.txt && fetch
http://localhost/test.txt/.php
# Python WSGI app
def simple_app(environ, start_response):
"""Simplest possible application object"""
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['', '\n'.join(['%s: %s' % (k, v) for k,v in
environ.items()]), '']
Expected result:
I expected PHP to return "no input file specified" such as when I
request /1.php on the server (which does not exist). I did not expect
PHP to travel up the path looking for PHP files to execute, and I would
like to disable this feature.
Please consider accepting the patch by Joey Smith located at:
http://patch.joeysmith.com/acceptpathinfo-5.3.1.patch (and other
versions in the root). This patch allows me to turn off this feature
but keeps the current behavior as default, which is surely best for all
parties. The best part is the patch is small, trivial even, so there
should be little to worry about in bringing it in.
PHP's accept_path_info behavior makes perfect sense for CGI, where it
is implicit that there is a direct relationship between a URI location
and a file. PHP now is a FastCGI responder, and I hear doesn't even
support plain CGI any longer. FastCGI is not a direct analogue of CGI,
though it may emulate it in the responder role. At any rate, though
FastCGI extends CGI, and some FastCGI apps *can* run in CGI, FastCGI is
not being used these days as a direct analogue of CGI by other
languages. SCRIPT_FILENAME is a PHP-specific FastCGI parameter not
mentioned anywhere in the FastCGI specification (because it is not
required that a file be execut
#50877 [NEW]: Provide javascript equivalent of arguments.callee (closures)
From: giorgio dot liscio at email dot it
Operating system: all
PHP version: 5.3.1
PHP Bug Type: Feature/Change Request
Bug description: Provide javascript equivalent of arguments.callee (closures)
Description:
hi, in future i hope to can get the callee of an anonymous function... for
example:
Reproduce code:
---
function(&$count) use (0)
{
echo $count++;
if($count<100)
{func_get_callee()}($count);
}
--
Edit bug report at http://bugs.php.net/?id=50877&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50877&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50877&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50877&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50877&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50877&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50877&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50877&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50877&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50877&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50877&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50877&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50877&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50877&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50877&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50877&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50877&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50877&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50877&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50877&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50877&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50877&r=mysqlcfg
