Bug #51856 [Opn->Bgs]: php-cgi 5.3.2-1 pg_connect() error
Edit report at http://bugs.php.net/bug.php?id=51856&edit=1 ID: 51856 Updated by: ahar...@php.net Reported by: 6uhere at gmail dot com Summary: php-cgi 5.3.2-1 pg_connect() error -Status: Open +Status: Bogus Type: Bug Package: CGI related Operating System: ubuntu 10.04 PHP Version: 5.3.2 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-05-19 07:50:04] 6uhere at gmail dot com Description: php-cgi 5.3.2-1 pg_connect() error PHP Version 5.3.2-1 PostgreSQL(libpq) Version 8.4.3 Multibyte character support enabled SSL support enabled Active Persistent Links 0 Active Links0 Directive Local Value Master Value pgsql.allow_persistent On On pgsql.auto_reset_persistent Off Off pgsql.ignore_notice Off Off pgsql.log_noticeOff Off pgsql.max_links Unlimited Unlimited pgsql.max_persistentUnlimited Unlimited PHP: http://bugs.php.net/bug.php?id=51856&edit=1
Bug #50405 [Ver->Wfx]: SimpleXML __get and __set are not invoked
Edit report at http://bugs.php.net/bug.php?id=50405&edit=1 ID: 50405 Updated by: m...@php.net Reported by: babooka at hotmail dot com Summary: SimpleXML __get and __set are not invoked -Status: Verified +Status: Wont fix Type: Bug Package: SimpleXML related Operating System: * PHP Version: 5.*, 6 Previous Comments: [2010-05-19 08:26:16] m...@php.net SimpleXML is already the magicians nipple, and needs to handle get/set property operations itself. [2009-12-08 03:14:55] babooka at hotmail dot com Description: Related to: http://bonsai.php.net/bug.php?id=45971 SimpleXML magic __get / __set elements are not called, as a result you can not extend the XML parsing and in addition to that SoapClient's classmap becomes useless, they are not called there either. Reproduce code: --- '); // __set $element->child1 = 1; // __get $element->child2; // __call $element->method(); Expected result: __set child1 __get child2 __call method Actual result: -- __call method -- Edit this bug report at http://bugs.php.net/bug.php?id=50405&edit=1
Bug #50405 [Ver]: SimpleXML __get and __set are not invoked
Edit report at http://bugs.php.net/bug.php?id=50405&edit=1 ID: 50405 Updated by: m...@php.net Reported by: babooka at hotmail dot com Summary: SimpleXML __get and __set are not invoked Status: Verified Type: Bug Package: SimpleXML related Operating System: * PHP Version: 5.*, 6 New Comment: SimpleXML is already the magicians nipple, and needs to handle get/set property operations itself. Previous Comments: [2009-12-08 03:14:55] babooka at hotmail dot com Description: Related to: http://bonsai.php.net/bug.php?id=45971 SimpleXML magic __get / __set elements are not called, as a result you can not extend the XML parsing and in addition to that SoapClient's classmap becomes useless, they are not called there either. Reproduce code: --- '); // __set $element->child1 = 1; // __get $element->child2; // __call $element->method(); Expected result: __set child1 __get child2 __call method Actual result: -- __call method -- Edit this bug report at http://bugs.php.net/bug.php?id=50405&edit=1
[PHP-BUG] Bug #51856 [NEW]: php-cgi 5.3.2-1 pg_connect() error
From: Operating system: ubuntu 10.04 PHP version: 5.3.2 Package: CGI related Bug Type: Bug Bug description:php-cgi 5.3.2-1 pg_connect() error Description: php-cgi 5.3.2-1 pg_connect() error PHP Version 5.3.2-1 PostgreSQL(libpq) Version 8.4.3 Multibyte character support enabled SSL support enabled Active Persistent Links 0 Active Links0 Directive Local Value Master Value pgsql.allow_persistent On On pgsql.auto_reset_persistent Off Off pgsql.ignore_notice Off Off pgsql.log_noticeOff Off pgsql.max_links Unlimited Unlimited pgsql.max_persistentUnlimited Unlimited PHP: http://bugs.php.net/bug.php?id=51856&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51856&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51856&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51856&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51856&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51856&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51856&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51856&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51856&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51856&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51856&r=support Expected behavior: http://bugs.php.net/fix.php?id=51856&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51856&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51856&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51856&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51856&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51856&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51856&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51856&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51856&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51856&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51856&r=mysqlcfg
Bug #51763 [Asn]: SplFileInfo::getType()
Edit report at http://bugs.php.net/bug.php?id=51763&edit=1 ID: 51763 Updated by: ka...@php.net Reported by: v-sumada at microsoft dot com Summary: SplFileInfo::getType() Status: Assigned Type: Bug Package: SPL related Operating System: All windows OS PHP Version: 5.3.2 Assigned To: pajoye New Comment: As noted, the issue here is within php_stat() and its way to detect links. php_stat() uses the S_ISLNK() macro to check if the stat.st_mode have the bits for a like, as on Unix. What we probably need to do is to use GetFileAttributes() and check for: FILE_ATTRIBUTE_REPARSE_POINT. After some further debugging it seems that the php_stream_stat_path_ex() function makes the fail. I only tried with symbolic-linked directories, but I would assume the cause would be the same on files. Which brings us to the point where the bug must be located within the url_stat function within the fopen() wrapper. Previous Comments: [2010-05-08 05:07:06] cataphr...@php.net The comment should read "information is NOT conveyed in the stat structure". [2010-05-08 05:05:38] cataphr...@php.net This is unrelated to Spl. is_link/etc. are all also windows symbolic link agnostic. The problem here is that this information is conveyed in the stat structure. Strictly speaking, the return of getType is not completely incorrect -- the file type _S_IFREG and symbolic links are in fact files or (empty) directories with reparse point data. Maybe the best thing to do would be to change the stat function returned on windows so that the file type is replaced with _S_IFLNK when the directory is a junction/symlink or the file is a symlink. [2010-05-07 03:36:11] v-sumada at microsoft dot com Description: The SplFileInfo::getType() For Symbolic link returns "dir" which in turn should return "link" .This happens to be in 5.3.2 and occurs on all windows OS. It Correctly returns the type of file referenced which is for Dir and File . getType()); ?> Expected result :string(4)"Link" Actual result : string(3) "dir" Test script: --- getType()); ?> Expected result: string(4)"Link" Actual result: -- string(3) "dir" -- Edit this bug report at http://bugs.php.net/bug.php?id=51763&edit=1
Bug #33957 [Com]: gmdate('W')/date('W') sometimes returns wrong week number.
Edit report at http://bugs.php.net/bug.php?id=33957&edit=1
ID: 33957
Comment by: wps at wwe dot com
Reported by: paul at stunning-stuff dot com
Summary: gmdate('W')/date('W') sometimes returns wrong week
number.
Status: Closed
Type: Bug
Package: Date/time related
Operating System: *
PHP Version: 5CVS-2005-08-02
Assigned To: derick
New Comment:
date('W', $timestamp) fails to return "01" for some January 1st years on
PHP version 5.3.2 and 5.2.8 on CentOS and Windows.
$year = 1970;
$month = 1;
$day = 1;
while ($year <= 2028) {
$timestamp = mktime(12, 0, 0, $month, $day, $year);
print $year . " :: " . date('W', $timestamp). " :: " . date('D',
$timestamp) . "\n";
$year++;
}
Expect 01 for every year
but instead get
1970 :: 01 :: Thu
1971 :: 53 :: Fri
1972 :: 52 :: Sat
1973 :: 01 :: Mon
1974 :: 01 :: Tue
1975 :: 01 :: Wed
1976 :: 01 :: Thu
1977 :: 53 :: Sat
1978 :: 52 :: Sun
...
2020 :: 01 :: Wed
2021 :: 53 :: Fri
2022 :: 52 :: Sat
2023 :: 52 :: Sun
2024 :: 01 :: Mon
2025 :: 01 :: Wed
2026 :: 01 :: Thu
2027 :: 53 :: Fri
2028 :: 52 :: Sat
1st falling on Friday returns 53
1st falling on Saturday/Sunday return 52
Checked dates using
http://www.tuxgraphics.org/toolbox/cal_year.html
Warwick Shaw
Previous Comments:
[2005-08-31 16:31:52] der...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-08-02 16:45:08] paul at stunning-stuff dot com
Thanks for your quick reply and thanks for doing such a great job on
PHP. You dev's really make this the best open source language today.
I hope you are able to solve this problem (I'm sure you will). One more
note though: This problem should reoccur every 28 years before and after
1992. This might help you in your testing.
Thanks,
Paul van der Maas
---
www.stunning-stuff.com
[2005-08-02 16:22:09] der...@php.net
Indeed a bug, will have a look at it - thanks for the reproducable case.
[2005-08-02 16:19:09] paul at stunning-stuff dot com
Here is some example code to reproduce the problem:
';
$timestamp = gmmktime(12, 0, 0, 12, 29, 1992);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 30, 1992);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 31, 1992);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 28, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 29, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 30, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 31, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
?>
Expected result:
Week number for Mon Dec 28, 1992 12:00:00: 53
Week number for Tue Dec 29, 1992 12:00:00: 53
Week number for Wed Dec 30, 1992 12:00:00: 53
Week number for Thu Dec 31, 1992 12:00:00: 53
Week number for Mon Dec 28, 2020 12:00:00: 53
Week number for Tue Dec 29, 2020 12:00:00: 53
Week number for Wed Dec 30, 2020 12:00:00: 53
Week number for Thu Dec 31, 2020 12:00:00: 53
Actual result:
Week number for Mon Dec 28, 1992 12:00:00: 1
Week number for Tue Dec 29, 1992 12:00:00: 1
Week number for Wed Dec 30, 1992 12:00:00: 1
Week number for Thu Dec 31, 1992 12:00:00: 1
Week number for Mon Dec 28, 2020 12:00:00: 1
Week number for Tue Dec 29, 2020 12:00:00: 1
Week number for Wed Dec 30, 2020 12:00:00: 1
Week number for Thu Dec 31, 2020 12:00:00: 1
Check
http://www.timeanddate.com/calendar/custom.html?year=1992&month=12&typ=1&display=1&wno=1
and
http://www.timeanddate.com/calendar/custom.html?year=2020&month=12&typ=1&display=1&wno=1
to see these expected results confirmed.
Sorry for the bulky post, but this way there is no room for
misinterpretation.
Thanks,
Paul van der Maas
---
www.stunning-stuff.com
[2005-08-02 03:27:51] paul at stunning-stuff d
Req #51855 [Opn]: Optional tuning parameter for get_defined_functions and get_defined_constants
Edit report at http://bugs.php.net/bug.php?id=51855&edit=1
ID: 51855
User updated by: a at b dot c dot de
Reported by: a at b dot c dot de
Summary: Optional tuning parameter for get_defined_functions
and get_defined_constants
Status: Open
Type: Feature/Change Request
Package: Unknown/Other Function
Operating System: Irrelevant
PHP Version: 5.3.2
New Comment:
Oh, one other thing ... the optional parameter to
get_defined_constants() would be of type mixed: give it true and it
behaves as it does currently, give it a string and it will restrict its
results to the extension with the given name.
Previous Comments:
[2010-05-19 02:02:51] a at b dot c dot de
Description:
get_defined_constants() offers an optional parameter which, when passed
true, categorises the constants by extension.
get_defined_functions() returns a list of function names categorised by
whether they are "user" or "internal".
Both could benefit from being able to specify an actual category,
instead of just that the returned list be categorised. For example,
get_defined_functions('internal') would return a one-dimensional
numerically-indexed array of internally-defined functions.
It's mainly for convenience: avoiding the extra variable, and depending
on the internals some work collating the data.
Since the list of extensions is so variable from configuration to
configuration, it would be infeasible to
define("DEFINED_CONSTANTS_PCRE", "pcre") and so forth.
If the syntax engine could be convinced then this suggestion would be
redundant, since it could then be achieved as
get_defined_functions()['internal'].
Test script:
---
print_r(get_defined_functions('internal'));
Equivalent to:
$functions = get_defined_functions();
print_r($functions['internal']);
Expected result:
Array(
[0] => zend_version
[1] => func_num_args
[2] => func_get_arg
[3] => func_get_args
[4] => strlen
)
Actual result:
--
A Warning is triggered stating that get_defined_functions() expects
exactly 0 parameters, not the 1 that it was given. print_r() outputs
null.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51855&edit=1
[PHP-BUG] Req #51855 [NEW]: Optional tuning parameter for get_defined_functions and get_defined_constants
From:
Operating system: Irrelevant
PHP version: 5.3.2
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:Optional tuning parameter for get_defined_functions and
get_defined_constants
Description:
get_defined_constants() offers an optional parameter which, when passed
true, categorises the constants by extension.
get_defined_functions() returns a list of function names categorised by
whether they are "user" or "internal".
Both could benefit from being able to specify an actual category, instead
of just that the returned list be categorised. For example,
get_defined_functions('internal') would return a one-dimensional
numerically-indexed array of internally-defined functions.
It's mainly for convenience: avoiding the extra variable, and depending on
the internals some work collating the data.
Since the list of extensions is so variable from configuration to
configuration, it would be infeasible to define("DEFINED_CONSTANTS_PCRE",
"pcre") and so forth.
If the syntax engine could be convinced then this suggestion would be
redundant, since it could then be achieved as
get_defined_functions()['internal'].
Test script:
---
print_r(get_defined_functions('internal'));
Equivalent to:
$functions = get_defined_functions();
print_r($functions['internal']);
Expected result:
Array(
[0] => zend_version
[1] => func_num_args
[2] => func_get_arg
[3] => func_get_args
[4] => strlen
)
Actual result:
--
A Warning is triggered stating that get_defined_functions() expects exactly
0 parameters, not the 1 that it was given. print_r() outputs null.
--
Edit bug report at http://bugs.php.net/bug.php?id=51855&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51855&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51855&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51855&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51855&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51855&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51855&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51855&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51855&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51855&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51855&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51855&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51855&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51855&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51855&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51855&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51855&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51855&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51855&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51855&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51855&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51855&r=mysqlcfg
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Comment by: mailnew2ster at mail dot ru Reported by: procyonar at gmail dot com Summary: curl extension slows down PHP Status: No Feedback Type: Bug Package: cURL related Operating System: win32 only - Windows 7 PHP Version: 5.2.11 New Comment: The same thing happens on my system. Windows 7 x86, PHP 5.3 (5.3.2) VC9 x86 Thread Safe (2010-Mar-04 20:11:10) After some debugging of php I found out that the RAND_screen() function in libeay32.dll is responsible for slowing down the execution. I've patched the function out, and it really became fast again. I don't use SSL stuff so I don't care how this affects security. The patch is 0xE8 -> 0xC3 on offset 0x0003EE10, you can use it as a temporary solution (patch it with any hex editor). Cheers! Previous Comments: [2010-02-18 10:31:00] raul dot valge at gmail dot com I am using PHP as embedded in another Win application. I can confirm that the issue occurs both from cli and embed sapi. I have tried different versions and also found that the issue started with 5.2.11 and is present up to 5.3.1 [2010-01-15 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-01-13 02:00:23] wzed dot php at gmail dot com I'm not the original reporter, but I cannot confirm that the bug affects requests when running PHP as an Apache 2.2 module, only that Apache start/restart is noticeably slower with curl enabled. Is there more initialization code now than there was in 5.2.10? I ran a diff of /ext/curl/* between 5.2.10 and 5.2.12 and didn't see anything significant. I just tested PHP 5.3.1 and sadly the bug exists there too. :( (I'm calling it a bug because the cause of the delay is still unknown) [2010-01-06 03:23:25] paj...@php.net I don't think it happens during all requests but when you start apache (as running CLI). Can you confirm that the slowdown happens on all requests and not only on apache start? PHP's curl does some initialization, just like many other exts. [2010-01-06 03:00:51] wzed dot php at gmail dot com I'm also having this problem, with a freshly-extracted copy of php-5.2.12-Win32.zip (php.ini edited to enable curl). In my case the CPU spike lasts about 2 seconds (just running php.exe -v), but that's a significant delay for someone who runs CLI scripts often. It seems to only affect PHP 5.2.11 and 5.2.12, as I wasn't able to reproduce it with 5.2.10 using the exact same php.ini file. Confirmed on Windows 7 and XP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1
Bug #51854 [Opn->Csd]: stream_set_read_buffer() not working as expected
Edit report at http://bugs.php.net/bug.php?id=51854&edit=1
ID: 51854
Updated by: paj...@php.net
Reported by: datib...@php.net
Summary: stream_set_read_buffer() not working as expected
-Status: Open
+Status: Closed
Type: Bug
Package: Streams related
-Operating System: Linux
+Operating System: *
PHP Version: Irrelevant
-Assigned To:
+Assigned To: pajoye
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-05-18 21:39:41] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=299466
Log: - #51854, fix logic (patch by Tjerk)
[2010-05-18 19:57:36] datib...@php.net
Description:
Recently, the stream_set_read_buffer() was introduced; it's signature
suggests that a buffer size can be set.
However, when passing any non-zero value, the stream becomes
unbuffered.
This is because of a missing check inside _php_stream_set_option():
if (value == PHP_STREAM_BUFFER_NONE) {
stream->flags |= PHP_STREAM_FLAG_NO_BUFFER;
} else {
stream->flags ^= PHP_STREAM_FLAG_NO_BUFFER;
}
Test script:
---
Expected result:
Either the read() loads 1024 bytes, which would be ideal, or it should
still load the default buffer size (8192 bytes).
The attached patch addresses the latter behaviour.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51854&edit=1
Bug #48082 [Com]: mysql_connect does not work with named pipes
Edit report at http://bugs.php.net/bug.php?id=48082&edit=1 ID: 48082 Comment by: dex_is_cool at loopmod dot com Reported by: andrew dot answer at gmail dot com Summary: mysql_connect does not work with named pipes Status: Assigned Type: Bug Package: MySQL related Operating System: win32 only - Windows XP PHP Version: 5.3.0RC1 Assigned To: mysql New Comment: I can't get named pipes working. It _always_ falls back to TCP, and fails if it can't get TCP connection. Windows XP sp3 IIS 5.1 FastCGI php-5.3.2-nts-Win32-VC9-x86 Previous Comments: [2010-02-17 20:11:16] quakvorgus at yahoo dot com Confirming what andrew wrote. @kulakov74: Thanks for the information. Setting mysql.default_socket = mysql does not solve the issue for me. Will have to switch to tcp connections instead of using named pipes. Please, the official documentation should be updated about this change from php 5.2 to 5.3. [2010-02-02 07:07:14] peaceable_whale at hotmail dot com I have the same problem using PHP 5.3.1 on IIS 7.5 w/FastCGI and MySQL 5.1.43. Is there any update on this issue? [2009-10-20 19:56:25] kulakov74 at yandex dot ru I confirm this with the just installed PHP 5.3.0 on Win XP, I used to use pipes and had skip-networking in my my.ini, I still can connect with mysql.exe, but PHP does not connect this way any more - I had to comment out skip-networking and set the right port in mysql.default_port = 3306 (PHP used to work without it when I used TCP long ago). Yes, the dot does not work any more, as if it cannot be resolved to localhost. If I have mysql.default_socket = mysql in my php.ini, mysqlnd connects to localhost via UNIX socket, otherwise it uses TCP. I agree these things are not critical, yet they have to be mentioned or explained somewhere. Got some info on pipes here: http://blog.ulf-wendel.de/?p=157 (comments) [2009-06-29 09:43:02] andrew dot answer at gmail dot com http://stackoverflow.com/questions/832714/mysql-named-pipes-on-windows- faster-best-practice-or-bad-idea [2009-06-29 09:40:48] andrew dot answer at gmail dot com regarding performance http://www.google.ru/search? rlz=1C1GGLS_ruRU305RU305&sourceid=chrome&ie=UTF-8&q=named+pipes+speed http://www.mail-archive.com/my...@lists.mysql.com/msg77837.html http://msdn.microsoft.com/en-us/library/aa178138(SQL.80).aspx The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48082 -- Edit this bug report at http://bugs.php.net/bug.php?id=48082&edit=1
[PHP-BUG] Bug #51854 [NEW]: stream_set_read_buffer() not working as expected
From:
Operating system: Linux
PHP version: Irrelevant
Package: Streams related
Bug Type: Bug
Bug description:stream_set_read_buffer() not working as expected
Description:
Recently, the stream_set_read_buffer() was introduced; it's signature
suggests that a buffer size can be set.
However, when passing any non-zero value, the stream becomes unbuffered.
This is because of a missing check inside _php_stream_set_option():
if (value == PHP_STREAM_BUFFER_NONE) {
stream->flags |= PHP_STREAM_FLAG_NO_BUFFER;
} else {
stream->flags ^= PHP_STREAM_FLAG_NO_BUFFER;
}
Test script:
---
Expected result:
Either the read() loads 1024 bytes, which would be ideal, or it should
still load the default buffer size (8192 bytes).
The attached patch addresses the latter behaviour.
--
Edit bug report at http://bugs.php.net/bug.php?id=51854&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51854&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51854&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51854&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51854&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51854&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51854&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51854&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51854&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51854&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51854&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51854&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51854&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51854&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51854&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51854&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51854&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51854&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51854&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51854&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51854&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51854&r=mysqlcfg
Bug #51778 [Opn]: crash on libphp5.so, when running ampache's initial scripts
Edit report at http://bugs.php.net/bug.php?id=51778&edit=1
ID: 51778
User updated by: nkostis at gmail dot com
Reported by: nkostis at gmail dot com
Summary: crash on libphp5.so, when running ampache's initial
scripts
Status: Open
Type: Bug
Package: Apache2 related
Operating System: plugapps (arch linux)
PHP Version: 5.2.13
New Comment:
speaking with others on the plugapps forums, this seems to be only
related with php on arm.
Also, it's not related to apache, for example it crashes with lighttpd
as well.
maybe a newer php wouldn't have the issue, although plugapps devs also
mentioned that they can't get it to compile on arm/openpogo (that's a
different bug though)
Previous Comments:
[2010-05-18 10:30:22] m...@php.net
Nope, sorry. I'm running PHP on 2.6.33-ARCH x86_64 without problems, but
that doesn't mean anything to your problem.
[2010-05-12 19:12:28] nkostis at gmail dot com
Ok, this script works:
while this one crashes apache (with the same stack trace as initially
posted):
Finally if i run the same script without an argument passed for
dirname:
php issues an error, but there's no crash.
This implies stack corruption and compiler problems, but calling:
$row_classes = array('even', 'odd');
doesn't crash apache.
any ideas? is this helpful at all?
[2010-05-12 09:09:38] m...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-05-09 23:06:53] nkostis at gmail dot com
Description:
I get this core dump when running anything from ampache (test.php,
index.php,
install.php, any ampache version):
#0 0x406300a8 in _zval_ptr_dtor () from /etc/httpd/modules/libphp5.so
#1 0x40660624 in zend_do_fcall_common_helper_SPEC () from
/etc/httpd/modules/libphp5.so
#2 0x4065dec8 in execute () from /etc/httpd/modules/libphp5.so
the rest of the stack trace is unknown as LAMP runs on limited hardware
(the
pogoplug) and i have not install debug symbols.
Pogoplug currently runs plugapps, an arm optimized version of Arch
linux. I am
not sure whether this crash is a vanilla php bug or a plugapps php
issue.
A basic "phpinfo()" script runs fine so at least basic php operation is
properly
configured.
Sorry if the bug is not vanilla php and i'm wasting your time.
Test script:
---
any ampache script, i.e. test.php (http://pastebin.com/FXAtKNyJ), run on
plugbox linux (arch 2.6.33 based)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51778&edit=1
Bug #51641 [Opn->Wfx]: Adding namespace with addAttribute() adds spurious xmlns:xmlns attribute
Edit report at http://bugs.php.net/bug.php?id=51641&edit=1
ID: 51641
Updated by: m...@php.net
Reported by: jpatokal at iki dot fi
Summary: Adding namespace with addAttribute() adds spurious
xmlns:xmlns attribute
-Status: Open
+Status: Wont fix
Type: Bug
Package: SimpleXML related
Operating System: All
PHP Version: 5.2.13
New Comment:
As its name implies SimpleXML is for simple access to XML, use a more
sophisticated interface like DOM.
Previous Comments:
[2010-04-23 02:06:09] jpatokal at iki dot fi
Description:
If you add a new namespace to a document root with addAttribute(), the
function incorrectly also tries to add a namespace for the new
namespace, resulting in a spurious "xmlns:xmlns" attribute.
Add attribute called "foo:bar"
xmlns:foo="namespace-url" foo:bar="value" <-- correct
Add attribute called "xmlns:bar"
xmlns:xmlns="namespace-url" xmlns:bar="namespace-url" <-- incorrect
A special case is thus needed to ensure that, if the attribute name
starts with "xmlns:", a namespace is not added for it:
xmlns:bar="namespace-url" <-- correct
Alternatively, a new function for adding namespaces to a document?
Test script:
---
');
$xml->addAttribute('xmlns:ooow', 'http://openoffice.org/2004/writer',
'http://openoffice.org/2004/writer');
echo $xml->asXML();
?>
Expected result:
http://openoffice.org/2004/writer"/>
Actual result:
--
http://openoffice.org/2004/writer";
xmlns:ooow="http://openoffice.org/2004/writer"/>
--
Edit this bug report at http://bugs.php.net/bug.php?id=51641&edit=1
Bug #51846 [Opn]: SimpleXMLElement iterator produces unexpected results
Edit report at http://bugs.php.net/bug.php?id=51846&edit=1 ID: 51846 User updated by: henning at glatter-gotz dot com Reported by: henning at glatter-gotz dot com Summary: SimpleXMLElement iterator produces unexpected results Status: Open Type: Bug Package: SimpleXML related Operating System: windows xp / Linux PHP Version: 5.3.2 New Comment: I agree, it is possible that this is indeed related or even the same problem as 50670. I ran some more test on documents with more than 10k elements and there both of my test cases fail, even the one that works for smaller sets. Did not think to look for issues related to the script Engine, so I did not find that bug. Maybe you can mark this one as a dupe and I will vote on the 50670. Thanks! Previous Comments: [2010-05-18 09:39:55] m...@php.net Probably related to Bug #50670 [2010-05-18 03:15:02] henning at glatter-gotz dot com For windows I downloaded the latest available VC6 x86 Thread Safe (2010-Mar-04 20:11:08) binaries, and tried it (see original report). I cannot build from Source on Linux, I do not have sufficient access to a system to do that. Sorry. But I did test on two different OS' and 3 different versions of PHP. [2010-05-18 02:58:11] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-05-18 02:56:11] henning at glatter-gotz dot com Added Linux (Ubuntu) to the OS field. [2010-05-18 02:53:34] henning at glatter-gotz dot com Now also tested on PHP 5.3.2-1ubuntu4.1 with Suhosin-Patch (cli) (built: May 4 2010 06:56:22). It fails with the same result as on Windows. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51846 -- Edit this bug report at http://bugs.php.net/bug.php?id=51846&edit=1
Bug #51852 [Bgs]: file_get_contents not working with hhtp urls
Edit report at http://bugs.php.net/bug.php?id=51852&edit=1
ID: 51852
User updated by: laurent at roussanne dot com
Reported by: laurent at roussanne dot com
Summary: file_get_contents not working with hhtp urls
Status: Bogus
Type: Bug
Package: Streams related
Operating System: windows server 2008 64 bits
PHP Version: 5.2.13
New Comment:
perhaps a French windows 2008 server OS specific issue ?
The bug appears even with the command line interface.
Previous Comments:
[2010-05-18 16:56:15] paj...@php.net
It is not. It works (win7/2k8/2k8R2, x64 or x86). Please ask further
support on php-windows or php-general mailing list.
[2010-05-18 16:43:18] laurent at roussanne dot com
allow_url_include On On
It is not a network problem because curl based workaround works !
I'm sure it is a windows 64 bits specific problem (2008 server, vista,
or seven).
[2010-05-18 16:38:13] paj...@php.net
Yes, windows is my main platform. Did you allow allow_url_fopen in your
php.ini?
But again: It does work. If it does not, then something is wrong in your
configuation.
[2010-05-18 16:34:53] laurent at roussanne dot com
I worked to find a workaround all the last weekend.
the solution was writing this :
function win64_file_get_contents($url, $timeout=5)
{
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
curl_close($ch);
if (is_bool($file_contents) && ($file_contents == FALSE))
{
return FALSE;
}
else
{
return $file_contents;
}
}
I'm sure you know this code (found on the web).
Do you have a windows 2008 64 test platform ?
[2010-05-18 16:27:20] paj...@php.net
Works just fine. Verify your network connections or whatever you use to
connect to internet. I suppose a simple:
file_get_contents("http://127.0.01/";); will work just fine too for you
(as long as you have 127.0.0.1 define).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51852
--
Edit this bug report at http://bugs.php.net/bug.php?id=51852&edit=1
Bug #51852 [Bgs]: file_get_contents not working with hhtp urls
Edit report at http://bugs.php.net/bug.php?id=51852&edit=1
ID: 51852
Updated by: paj...@php.net
Reported by: laurent at roussanne dot com
Summary: file_get_contents not working with hhtp urls
Status: Bogus
Type: Bug
Package: Streams related
Operating System: windows server 2008 64 bits
PHP Version: 5.2.13
New Comment:
It is not. It works (win7/2k8/2k8R2, x64 or x86). Please ask further
support on php-windows or php-general mailing list.
Previous Comments:
[2010-05-18 16:43:18] laurent at roussanne dot com
allow_url_include On On
It is not a network problem because curl based workaround works !
I'm sure it is a windows 64 bits specific problem (2008 server, vista,
or seven).
[2010-05-18 16:38:13] paj...@php.net
Yes, windows is my main platform. Did you allow allow_url_fopen in your
php.ini?
But again: It does work. If it does not, then something is wrong in your
configuation.
[2010-05-18 16:34:53] laurent at roussanne dot com
I worked to find a workaround all the last weekend.
the solution was writing this :
function win64_file_get_contents($url, $timeout=5)
{
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
curl_close($ch);
if (is_bool($file_contents) && ($file_contents == FALSE))
{
return FALSE;
}
else
{
return $file_contents;
}
}
I'm sure you know this code (found on the web).
Do you have a windows 2008 64 test platform ?
[2010-05-18 16:27:20] paj...@php.net
Works just fine. Verify your network connections or whatever you use to
connect to internet. I suppose a simple:
file_get_contents("http://127.0.01/";); will work just fine too for you
(as long as you have 127.0.0.1 define).
[2010-05-18 16:21:34] laurent at roussanne dot com
Description:
file_get_contents("http://www.php.net";);
reports :
failed to open stream: Une tentative de connexion a échoué car le
parti connecté
n'a pas répondu convenablement au-delà d'une certaine durée ou une
connexion
établie a échoué car l'hôte de connexion n'a pas répondu.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51852&edit=1
Bug #51852 [Bgs]: file_get_contents not working with hhtp urls
Edit report at http://bugs.php.net/bug.php?id=51852&edit=1
ID: 51852
User updated by: laurent at roussanne dot com
Reported by: laurent at roussanne dot com
Summary: file_get_contents not working with hhtp urls
Status: Bogus
Type: Bug
Package: Streams related
Operating System: windows server 2008 64 bits
PHP Version: 5.2.13
New Comment:
allow_url_include On On
It is not a network problem because curl based workaround works !
I'm sure it is a windows 64 bits specific problem (2008 server, vista,
or seven).
Previous Comments:
[2010-05-18 16:38:13] paj...@php.net
Yes, windows is my main platform. Did you allow allow_url_fopen in your
php.ini?
But again: It does work. If it does not, then something is wrong in your
configuation.
[2010-05-18 16:34:53] laurent at roussanne dot com
I worked to find a workaround all the last weekend.
the solution was writing this :
function win64_file_get_contents($url, $timeout=5)
{
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
curl_close($ch);
if (is_bool($file_contents) && ($file_contents == FALSE))
{
return FALSE;
}
else
{
return $file_contents;
}
}
I'm sure you know this code (found on the web).
Do you have a windows 2008 64 test platform ?
[2010-05-18 16:27:20] paj...@php.net
Works just fine. Verify your network connections or whatever you use to
connect to internet. I suppose a simple:
file_get_contents("http://127.0.01/";); will work just fine too for you
(as long as you have 127.0.0.1 define).
[2010-05-18 16:21:34] laurent at roussanne dot com
Description:
file_get_contents("http://www.php.net";);
reports :
failed to open stream: Une tentative de connexion a échoué car le
parti connecté
n'a pas répondu convenablement au-delà d'une certaine durée ou une
connexion
établie a échoué car l'hôte de connexion n'a pas répondu.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51852&edit=1
Bug #51852 [Bgs]: file_get_contents not working with hhtp urls
Edit report at http://bugs.php.net/bug.php?id=51852&edit=1
ID: 51852
Updated by: paj...@php.net
Reported by: laurent at roussanne dot com
Summary: file_get_contents not working with hhtp urls
Status: Bogus
Type: Bug
Package: Streams related
Operating System: windows server 2008 64 bits
PHP Version: 5.2.13
New Comment:
Yes, windows is my main platform. Did you allow allow_url_fopen in your
php.ini?
But again: It does work. If it does not, then something is wrong in your
configuation.
Previous Comments:
[2010-05-18 16:34:53] laurent at roussanne dot com
I worked to find a workaround all the last weekend.
the solution was writing this :
function win64_file_get_contents($url, $timeout=5)
{
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
curl_close($ch);
if (is_bool($file_contents) && ($file_contents == FALSE))
{
return FALSE;
}
else
{
return $file_contents;
}
}
I'm sure you know this code (found on the web).
Do you have a windows 2008 64 test platform ?
[2010-05-18 16:27:20] paj...@php.net
Works just fine. Verify your network connections or whatever you use to
connect to internet. I suppose a simple:
file_get_contents("http://127.0.01/";); will work just fine too for you
(as long as you have 127.0.0.1 define).
[2010-05-18 16:21:34] laurent at roussanne dot com
Description:
file_get_contents("http://www.php.net";);
reports :
failed to open stream: Une tentative de connexion a échoué car le
parti connecté
n'a pas répondu convenablement au-delà d'une certaine durée ou une
connexion
établie a échoué car l'hôte de connexion n'a pas répondu.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51852&edit=1
Bug #51852 [Bgs]: file_get_contents not working with hhtp urls
Edit report at http://bugs.php.net/bug.php?id=51852&edit=1
ID: 51852
User updated by: laurent at roussanne dot com
Reported by: laurent at roussanne dot com
Summary: file_get_contents not working with hhtp urls
Status: Bogus
Type: Bug
Package: Streams related
Operating System: windows server 2008 64 bits
PHP Version: 5.2.13
New Comment:
I worked to find a workaround all the last weekend.
the solution was writing this :
function win64_file_get_contents($url, $timeout=5)
{
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
curl_close($ch);
if (is_bool($file_contents) && ($file_contents == FALSE))
{
return FALSE;
}
else
{
return $file_contents;
}
}
I'm sure you know this code (found on the web).
Do you have a windows 2008 64 test platform ?
Previous Comments:
[2010-05-18 16:27:20] paj...@php.net
Works just fine. Verify your network connections or whatever you use to
connect to internet. I suppose a simple:
file_get_contents("http://127.0.01/";); will work just fine too for you
(as long as you have 127.0.0.1 define).
[2010-05-18 16:21:34] laurent at roussanne dot com
Description:
file_get_contents("http://www.php.net";);
reports :
failed to open stream: Une tentative de connexion a échoué car le
parti connecté
n'a pas répondu convenablement au-delà d'une certaine durée ou une
connexion
établie a échoué car l'hôte de connexion n'a pas répondu.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51852&edit=1
Bug #51852 [Opn->Bgs]: file_get_contents not working with hhtp urls
Edit report at http://bugs.php.net/bug.php?id=51852&edit=1
ID: 51852
Updated by: paj...@php.net
Reported by: laurent at roussanne dot com
Summary: file_get_contents not working with hhtp urls
-Status: Open
+Status: Bogus
Type: Bug
Package: Streams related
Operating System: windows server 2008 64 bits
PHP Version: 5.2.13
New Comment:
Works just fine. Verify your network connections or whatever you use to
connect to internet. I suppose a simple:
file_get_contents("http://127.0.01/";); will work just fine too for you
(as long as you have 127.0.0.1 define).
Previous Comments:
[2010-05-18 16:21:34] laurent at roussanne dot com
Description:
file_get_contents("http://www.php.net";);
reports :
failed to open stream: Une tentative de connexion a échoué car le
parti connecté
n'a pas répondu convenablement au-delà d'une certaine durée ou une
connexion
établie a échoué car l'hôte de connexion n'a pas répondu.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51852&edit=1
Bug #48388 [Asn->Csd]: ArrayObject and __sleep()
Edit report at http://bugs.php.net/bug.php?id=48388&edit=1
ID: 48388
Updated by: m...@php.net
Reported by: david at grudl dot com
Summary: ArrayObject and __sleep()
-Status: Assigned
+Status: Closed
Type: Bug
Package: SPL related
Operating System: *
PHP Version: 5.2.9
Assigned To: colder
New Comment:
Fixed in 5.3.
Previous Comments:
[2009-05-25 15:49:14] david at grudl dot com
Description:
ArrayObject descendants can be forced to serialize
public/protected/private properies using __sleep(), but it produces
E_NOTICE
Reproduce code:
---
class Test extends ArrayObject
{
public $var = 123;
public function __sleep()
{
return array('var');
}
}
$test = new Test;
$s = serialize($test);
Expected result:
none
Actual result:
--
Notice: serialize() [function.serialize]: "var" returned as member
variable from __sleep() but does not exist
--
Edit this bug report at http://bugs.php.net/bug.php?id=48388&edit=1
[PHP-BUG] Bug #51852 [NEW]: file_get_contents not working with hhtp urls
From:
Operating system: windows server 2008 64 bits
PHP version: 5.2.13
Package: Streams related
Bug Type: Bug
Bug description:file_get_contents not working with hhtp urls
Description:
file_get_contents("http://www.php.net";);
reports :
failed to open stream: Une tentative de connexion a échoué car le parti
connecté
n'a pas répondu convenablement au-delà d'une certaine durée ou une
connexion
établie a échoué car l'hôte de connexion n'a pas répondu.
--
Edit bug report at http://bugs.php.net/bug.php?id=51852&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51852&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51852&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51852&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51852&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51852&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51852&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51852&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51852&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51852&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51852&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51852&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51852&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51852&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51852&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51852&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51852&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51852&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51852&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51852&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51852&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51852&r=mysqlcfg
Bug #48387 [Asn->Wfx]: ArrayObject and properties serialization
Edit report at http://bugs.php.net/bug.php?id=48387&edit=1
ID: 48387
Updated by: m...@php.net
Reported by: david at grudl dot com
Summary: ArrayObject and properties serialization
-Status: Assigned
+Status: Wont fix
Type: Bug
Package: SPL related
Operating System: *
PHP Version: 5.2.9
Assigned To: colder
Previous Comments:
[2010-04-18 00:17:31] jhominal at gmail dot com
I believe I had the same problem on PHP 5.2.13, on Debian Lenny (package
provided
by dotdeb)
[2010-02-28 10:55:10] s...@php.net
For what it's worth, the reproduce code works perfectly fine with
php5.3.0
[2009-05-25 15:46:56] david at grudl dot com
Description:
In PHP 5.2.x there are not serialized any public/protected/private
properies of ArrayObject descendants.
Reproduce code:
---
class Test extends ArrayObject
{
public $var;
}
$test = new Test;
$test->var = 'hello';
$dolly = unserialize(serialize($test));
echo $dolly->var;
Expected result:
-> hello
Actual result:
--
none
--
Edit this bug report at http://bugs.php.net/bug.php?id=48387&edit=1
Bug #50000 [Asn->Fbk]: ArrayIterator does not clone itself when referencing itself
Edit report at http://bugs.php.net/bug.php?id=5&edit=1
ID: 5
Updated by: m...@php.net
Reported by: chris42 dot b at googlemail dot com
Summary: ArrayIterator does not clone itself when referencing
itself
-Status: Assigned
+Status: Feedback
Type: Bug
Package: SPL related
Operating System: windows xp
PHP Version: 5.2SVN-2009-10-26 (snap)
Assigned To: colder
New Comment:
So, you say, that the test-case is wrong in the first place?
Previous Comments:
[2009-10-26 13:46:47] chris42 dot b at googlemail dot com
Description:
In test file array_022.phpt we see the clone being changed but this does
not change original, If you clone an ArrayIterator you also clone its
reference.
If you take such a self-wrapping ArrayIterator and clone it, the clone
is no longer self-wrapping: the clone wraps the original. HOWEVER, I
*think* the SPL_ARRAY_IS_SELF flag is being copied to the clone
Therefore, the clone starts to store/retrieve data from itself rather
than from its wrapped container - hence the difference.
Reproduce code:
---
Expected result:
object(MyArrayIterator)#%d (2) {
["bar"]=>
string(3) "baz"
["baz"]=>
string(3) "Foo"
}
object(MyArrayIterator)#%d (2) {
["bar"]=>
string(3) "baz"
["baz"]=>
string(3) "Foo"
}
Actual result:
--
object(MyArrayIterator)#%d (1) {
["bar"]=>
string(3) "baz"
}
object(MyArrayIterator)#%d (2) {
["bar"]=>
string(3) "baz"
["baz"]=>
string(3) "Foo"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
Bug #48386 [Asn->Bgs]: ArrayObject and __wakeup()
Edit report at http://bugs.php.net/bug.php?id=48386&edit=1
ID: 48386
Updated by: m...@php.net
Reported by: david at grudl dot com
Summary: ArrayObject and __wakeup()
-Status: Assigned
+Status: Bogus
Type: Bug
Package: SPL related
Operating System: *
PHP Version: 5.3CVS-2009-05-25 (snap)
Assigned To: colder
New Comment:
For classes implementing the Serializable interface,
$obj->unserialize($serializedData) is called instead of __wakeup():
class Test extends ArrayObject {
function unserialize($serialized) {
echo "Hey!\n";
return parent::unserialize($serialized);
}
}
Previous Comments:
[2009-05-25 15:31:42] david at grudl dot com
Description:
Unserialization of ArrayObject descendants doesn't call __wakeup in PHP
5.3.
Reproduce code:
---
class Test extends ArrayObject
{
public function __wakeup()
{
echo 'hey';
}
}
$test = new Test;
$dolly = unserialize(serialize($test));
Expected result:
-> hey
Actual result:
--
none
--
Edit this bug report at http://bugs.php.net/bug.php?id=48386&edit=1
Bug #49608 [Asn->Fbk]: Using CachingIterator on DirectoryIterator instance segfaults
Edit report at http://bugs.php.net/bug.php?id=49608&edit=1 ID: 49608 Updated by: m...@php.net Reported by: david at grudl dot com Summary: Using CachingIterator on DirectoryIterator instance segfaults -Status: Assigned +Status: Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3SVN-2009-09-20 (snap) Assigned To: colder New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works here on Linux (tm). Previous Comments: [2009-09-20 14:59:56] paj...@php.net Pretty sure it is not a windows only bug either. [2009-09-20 14:59:09] paj...@php.net Backtrace: > php5_debug.dll!zval_delref_p(_zval_struct * pz=0x) Line 385 + 0x3 bytes C php5_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x00c1ebe4, char * __zend_filename=0x10563320, unsigned int __zend_lineno=1407) Line 429 + 0xb bytesC php5_debug.dll!spl_filesystem_dir_it_dtor(_zend_object_iterator * iter=0x02784d10) Line 1407 + 0x17 bytesC php5_debug.dll!spl_dual_it_free_storage(void * _object=0x02785080) Line 1920 + 0x16 bytes C php5_debug.dll!zend_objects_store_del_ref_by_handle_ex(unsigned int handle=2, const _zend_object_handlers * handlers=0x105a6e00) Line 220 + 0x10 bytes C php5_debug.dll!zend_objects_store_del_ref(_zval_struct * zobject=0x02783ad8) Line 172 + 0x10 bytes C php5_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x02783ad8, char * __zend_filename=0x104dea40, unsigned int __zend_lineno=435) Line 52 + 0x11 bytes C php5_debug.dll!_zval_dtor(_zval_struct * zvalue=0x02783ad8, char * __zend_filename=0x104dea40, unsigned int __zend_lineno=435) Line 35 + 0x11 bytes C php5_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x027852a4, char * __zend_filename=0x104e3584, unsigned int __zend_lineno=175) Line 435 + 0x19 bytesC php5_debug.dll!_zval_ptr_dtor_wrapper(_zval_struct * * zval_ptr=0x027852a4) Line 175 + 0x17 bytes C php5_debug.dll!zend_hash_apply_deleter(_hashtable * ht=0x105c0b78, bucket * p=0x02785298) Line 611 + 0x11 bytes C php5_debug.dll!zend_hash_reverse_apply(_hashtable * ht=0x105c0b78, int (void *)* apply_func=0x10283570) Line 760 + 0xd bytes C php5_debug.dll!shutdown_destructors() Line 222 + 0xf bytes C php5_debug.dll!zend_call_destructors() Line 875C php5_debug.dll!php_request_shutdown(void * dummy=0x) Line 1547C php.exe!main(int argc=3, char * * argv=0x00ce1bf0) Line 1371 + 0xa bytes C php.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C php.exe!mainCRTStartup() Line 403 C [2009-09-20 14:33:39] david at grudl dot com Description: This code crashes PHP 5.3.0 - 5.3.2-dev (VC9, TS) Reproduce code: --- $dir = new DirectoryIterator(__DIR__); $iterator = new CachingIterator($dir); foreach ($dir as $val); -- Edit this bug report at http://bugs.php.net/bug.php?id=49608&edit=1
Bug #51837 [Opn->Fbk]: XMLReader cannot store values in arrays
Edit report at http://bugs.php.net/bug.php?id=51837&edit=1
ID: 51837
Updated by: m...@php.net
Reported by: cvb724 at yahoo dot ca
Summary: XMLReader cannot store values in arrays
-Status: Open
+Status: Feedback
Type: Bug
Package: *General Issues
Operating System: CentOS 5
PHP Version: 5.3.2
New Comment:
Works fine here:
$ php -r '$r=new XMLReader();
$r->open("http://www.w3.org/TR/xmldsig-core/signature-example-rsa.xml";);
while($r->read()){ if($r->nodeType==XMLReader::TEXT) $var[] =
$r->value;} print_r($var);'
Array
(
[0] => 60NvZvtdTB+7UnlLp/H24p7h4bs=
[1] =>
juS5RhJ884qoFR8flVXd/rbrSDVGn40CapgB7qeQiT+rr0NekEQ6BHhUA8dT3+BC
TBUQI0dBjlml9lwzENXvS83zRECjzXbMRTUtVZiPZG2pqKPnL2YU3A9645UCjTXU
+jgFumv7k78hieAGDzNci+PQ9KRmm//icT7JaYztgt4=
[2] =>
uCiukpgOaOmrq1fPUTH3CAXxuFmPjsmS4jnTKxrv0w1JKcXtJ2M3akaV1d/karvJ
lmeao20jNy9r+/vKwibjM77F+3bIkeMEGmAIUnFciJkR+ihO7b4cTuYnEi8xHtu4
iMn6GODBoEzqFQYdd8p4vrZBsvs44nTrS8qyyhba648=
[3] =>
AQAB
[4] =>
CN=Merlin Hughes,O=Baltimore Technologies\, Ltd.,ST=Dublin,C=IE
[5] =>
CN=Test RSA CA,O=Baltimore Technologies\, Ltd.,ST=Dublin,C=IE
[6] => 970849928
[7] =>
MIICeDCCAeGgAwIBAgIEOd3+iDANBgkqhkiG9w0BAQQFADBbMQswCQYDVQQGEwJJ
RTEPMA0GA1UECBMGRHVibGluMSUwIwYDVQQKExxCYWx0aW1vcmUgVGVjaG5vbG9n
aWVzLCBMdGQuMRQwEgYDVQQDEwtUZXN0IFJTQSBDQTAeFw0wMDEwMDYxNjMyMDda
Fw0wMTEwMDYxNjMyMDRaMF0xCzAJBgNVBAYTAklFMQ8wDQYDVQQIEwZEdWJsaW4x
JTAjBgNVBAoTHEJhbHRpbW9yZSBUZWNobm9sb2dpZXMsIEx0ZC4xFjAUBgNVBAMT
DU1lcmxpbiBIdWdoZXMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALgorpKY
Dmjpq6tXz1Ex9wgF8bhZj47JkuI50ysa79MNSSnF7SdjN2pGldXf5Gq7yZZnmqNt
Izcva/v7ysIm4zO+xft2yJHjBBpgCFJxXIiZEfooTu2+HE7mJxIvMR7buIjJ+hjg
waBM6hUGHXfKeL62QbL7OOJ060vKssoW2uuPAgMBAAGjRzBFMB4GA1UdEQQXMBWB
E21lcmxpbkBiYWx0aW1vcmUuaWUwDgYDVR0PAQH/BAQDAgeAMBMGA1UdIwQMMAqA
CEngrZIVgu03MA0GCSqGSIb3DQEBBAUAA4GBAHJu4JVq/WnXK2oqqfLWqes5vHOt
fX/ZhCjFyDMhzslI8am62gZedwZ9IIZIwlNRMvEDQB2zds/eEBnIAQPl/yRLCLOf
ZnbA8PXrbFP5igs3qQWScBUjZVjik748HU2sUVZOa90c0mJl2vJs/RwyLW7/uCAf
C/I/k9xGr7fneoIW
)
Previous Comments:
[2010-05-17 10:14:45] cvb724 at yahoo dot ca
Description:
I have tried every way possible to store the values from an XML sheet
using XMLReader in an array. The XML sheet is valid. I have tried this
on two systems now, both with the same problem. Colleagues cannot find
anything wrong either. Example code is below:
CODE:
$reader = new XMLReader();
$url = 'http://xml.com/info.php'; // not a real URL
$reader->open($url);
$i = 0;
$j = 0;
while ($reader->read())
{
if ($reader->nodeType == XMLReader::ELEMENT)
{
$attr[$i] = $reader->getAttribute("name"); // does not store
anything
$attr .= $reader->getAttribute("name"); // stores
perfectly
i++;
}
if ($reader->nodeType == XMLReader::TEXT)
{
$val[$j] = $reader->value; // performs the same as above
$val .= $reader->value;
$j++;
}
}
Test script:
---
$reader = new XMLReader();
$url = 'http://xml.com/info.php'; // insert a real URL to test
$reader->open($url);
$i = 0;
while ($reader->read())
{
if ($reader->nodeType == XMLReader::TEXT)
{
$val[$i] = $reader->value; // does not work
//$val .= $reader->value; // for demonstration only, works
properly
$i++;
}
}
print_r($val);
Expected result:
When using a valid URL and XML sheet, "print_r" should print an array of
all values stored.
Actual result:
--
Instead, the entire array is empty. As soon as you use .= instead of
storing in an array, everything is printed fine simply using "echo".
--
Edit this bug report at http://bugs.php.net/bug.php?id=51837&edit=1
Bug #51836 [Opn->Bgs]: proc_get_status() caused child process exit
Edit report at http://bugs.php.net/bug.php?id=51836&edit=1
ID: 51836
Updated by: m...@php.net
Reported by: pcdinh at gmail dot com
Summary: proc_get_status() caused child process exit
-Status: Open
+Status: Bogus
Type: Bug
Package: Program Execution
Operating System: CentOS 5.4
PHP Version: 5.2.13
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
As you keep no reference to the opened pipes of the child, you close
it's stdin/stdout, which causes the child to exit because you do not set
ignore_user_abort() in the child.
Previous Comments:
[2010-05-17 09:40:29] pcdinh at gmail dot com
Re-categorised
PCNTL => Program Execution
[2010-05-17 08:54:22] pcdinh at gmail dot com
I am sorry, just submit too fast
The expected result should read as follows:
Expected result:
[r...@clipserver test]# ./test3.php
Parent process ID: 30283
Started process Id
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process 30284 is running
Process 30284 is running
Process 30284 is running
Process 30284 is running
Process 30284 is running
Child process 30284 should run in 100 seconds before it can exit.
[2010-05-17 08:51:20] pcdinh at gmail dot com
Description:
I write a script that is able to launch another process which runs in
100 seconds
The master process will check the child process in a loop to see if it
is still running.
The child process is able to launch and run correctly. However, when I
asign the resource returned by proc_get_status() to an array and return
that array from a function, proc_get_status() does not work correctly
any more. It caused the child process exit right after the first call.
Called in the same scope
$process = proc_open('/usr/local/php5-fcgi/bin/php process1.php',
$descriptors, $pipes);
// $process and proc_get_status() in same scope ==> OK
$status = proc_get_status($process);
if (true === $status['running'])
{
echo "Started process Id\n";
}
else
{
echo "Unable to start a process\n";
}
Called from different scope and against a reference
===
Return from a function
==
return array(
'pid' => $status['pid'],
'handle' => $process
);
Called against a reference
==
foreach ($running as $pid => $info)
{
// first call will cause child process exit after that
$status = proc_get_status($info['handle']);
sleep(1);
}
Test script:
---
You can read the sample code here: http://gist.github.com/403467
It contains 2 files: a master process named test3.php and a child
process named process1.php
Expected result:
[r...@clipserver test]# ./test3.php
Parent process ID: 30283
Started process Id
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process Id 30284 is running
Command used /usr/local/php5-fcgi/bin/php process1.php
Process 30284 is running
Bug #17738 [Opn]: SSL support for LDAP
Edit report at http://bugs.php.net/bug.php?id=17738&edit=1 ID: 17738 Updated by: m...@php.net Reported by: benoit at gide dot net Summary: SSL support for LDAP Status: Open Type: Bug Package: LDAP related Operating System: Redhat 6.2 7.1 7.2 PHP Version: 4.2.1 New Comment: Maybe this helps? http://directory.fedoraproject.org/wiki/Howto:SSL#Configure_LDAP_clients Previous Comments: [2010-05-01 19:24:23] geiss...@php.net Here's the bug again. See: http://bugs.debian.org/560161 [2006-10-02 02:28:20] michael at akatose dot de Ok, this problem vanished, as soon as I replaced the wildcard-certificate at the LDAP server (CN=*.example.com) with a "simple" certificate (CN=ldap.example.com). I double-checked this with another wildcard-certificate, which is also accepted by the command line utilities. Again, PHP's ldap_start_tls() returns false and gives its warning "Unable to start TLS: Connect error". A capture of the network traffic to the LDAP server reveals, that even though ldap_start_tls() returns false, the connection is encrypted afterwards. So it seems, that the handling of the return code is wrong, when using wildcard-certificates. [2006-10-01 02:35:13] michael at akatose dot de This error not only happens with SSL (ldaps), but also when using StartTLS. On my system, the correct CA certificate is referenced in /etc/ldap/ldap.conf and command line utilities can connect without problems: ~# ldapsearch -v -x -ZZ "(objectClass=*)" ldap_initialize( ) filter: (objectClass=*) requesting: ALL # extended LDIF # ... But the following PHP script fails (on PHP-5.1.2 from Ubuntu-6.06): ldap://ldap.example.com";); ldap_set_option($server, LDAP_OPT_PROTOCOL_VERSION, 3); $result = ldap_read($server, "dc=example,dc=com", "(objectclass=*)"); $entry = ldap_get_entries($server, $result); print_r($entry); // everything works fine up to this point // no network problems, we are really talking to the server ldap_start_tls($server); // this fails: // Warning: ldap_start_tls() [function.ldap-start-tls]: // Unable to start TLS: Connect error in /var/www/ldaptest.php on line 10 ldap_close($server); ?> As you can see a "Connect error" is returned, altough this seems to be an error while checking the server certificate. I can get the command line utilities to throw the same error by making the CA certificate unreadable: ~# ldapsearch -v -x -ZZ "(objectClass=*)" ldap_initialize( ) ldap_start_tls: Connect error (-11) The PHP script will work, if I disable the verification of the server certificate by putting the already mentioned "TLS_REQCERT never" in /etc/ldap/ldap.conf [2004-12-09 09:54:25] sami at sipponen dot com "phpdeveloper at chinese dot university dot hk"'s problem seems to be related an issue with PHP Windows build's "not so good documented features"... See the link below: http://www.ldaphelp.com/viewtopic.php?t=6 It seems that there are some hard coded config file issues with PHP's ldap extension. Copy&paste from the site which link is above: create the directory: C:\OpenLDAP\sysconf\ and put there a ldap.conf file which contains in its first line: TLS_REQCERT never [2003-07-19 00:18:04] phpdeveloper at chinese dot university dot hk i am using IIS+windows xp+php4.3.2.2 facing the same problem and can not connect to the ldap except using ldaps://host:636/ but success using ldap://host/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=17738 -- Edit this bug report at http://bugs.php.net/bug.php?id=17738&edit=1
Bug #51847 [Fbk->Opn]: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale
Edit report at http://bugs.php.net/bug.php?id=51847&edit=1 ID: 51847 User updated by: php-bugs-2010 at ryandesign dot com Reported by: php-bugs-2010 at ryandesign dot com Summary: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale -Status: Feedback +Status: Open Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.3 x86_64 PHP Version: 5.2.13 New Comment: php 5.3.2 builds fine with gettext 0.17 and 0.18. This issue only appears to affect php 5.2.x. Adding '#include "ext/standard/php_string.h"' to ext/standard/basic_functions.c does not change the error message. Previous Comments: [2010-05-18 10:04:40] ka...@php.net Hi Does this happen with 5.3 aswell? Does adding the following include after including 'ext/standard/php_uuencode.h' work: #include "ext/standard/php_string.h" [2010-05-18 05:09:31] php-bugs-2010 at ryandesign dot com Modify summary. [2010-05-18 05:07:58] php-bugs-2010 at ryandesign dot com Description: Hello, I'm the maintainer of the php packages in MacPorts, and it seems that php 5.2.13 doesn't build with gettext 0.18 (at least not on Mac OS X 10.6.3 x86_64). It fails with: Undefined symbols: "_zif_setlocale", referenced from: _basic_functions in basic_functions.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 php 5.2.13 builds fine with gettext 0.17, and php 5.3.2 builds fine with gettext 0.17 and 0.18. Here's the bug report that was submitted to us: http://trac.macports.org/ticket/24934 -- Edit this bug report at http://bugs.php.net/bug.php?id=51847&edit=1
Req #50826 [Opn->Asn]: GD: Add the "get values" function
Edit report at http://bugs.php.net/bug.php?id=50826&edit=1 ID: 50826 Updated by: paj...@php.net Reported by: pcfrr at yopmail dot com Summary: GD: Add the "get values" function -Status: Open +Status: Assigned Type: Feature/Change Request Package: GD related Operating System: * PHP Version: 5.3.1 -Assigned To: +Assigned To: pajoye New Comment: Have a slightly different patch, will apply it soonish to trunk. Previous Comments: [2010-05-18 10:48:32] ka...@php.net I would suggest we redesigned the GD extension instead of having alot getters and setters but perhaps something more abstract like: imageset($im, IMAGE_THICKNESS, 5); echo imageget($im, IMAGE_THICKNESS); /* 5 */ [2010-01-22 17:13:45] pcfrr at yopmail dot com Description: Hi, I 'spoke' with Pierre in libgd's chat. I answered if exist the function to GET the values of thickness, color, size, but maybe this isn´t. He 'said' me put the bug here. Reproduce code: --- If imagesetthickness($this->im, 2); after how I can GET the thickness? maybe this function not exist. -- Edit this bug report at http://bugs.php.net/bug.php?id=50826&edit=1
Bug #51850 [Com]: look
Edit report at http://bugs.php.net/bug.php?id=51850&edit=1 ID: 51850 Comment by: heinz50 at hotmail dot com Reported by: heinz50 at hotmail dot com Summary: look Status: Bogus Type: Bug Package: *General Issues Operating System: every PHP Version: Irrelevant New Comment: So with Ctrl+u i can see the output, but not the outout on the screen.. and if you use website with lotÃs of echo and there is http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". hey my first time to make a bug report.. and you can describe better , but i hope you try it out .. so easy make a file and put the code in it and try it... so it is a very big bug every thing with http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2010-05-18 11:03:06] heinz50 at hotmail dot com Description: pleae try this :) after echo
Bug #51850 [Fbk->Bgs]: look
Edit report at http://bugs.php.net/bug.php?id=51850&edit=1 ID: 51850 Updated by: johan...@php.net Reported by: heinz50 at hotmail dot com Summary: look -Status: Feedback +Status: Bogus Type: Bug Package: *General Issues Operating System: every PHP Version: Irrelevant New Comment: You're most likely using the web browser to view the result. Use the "View source" feature of the browser (often Ctrl+u) to see your broken HTML. Previous Comments: [2010-05-18 11:15:27] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2010-05-18 11:03:06] heinz50 at hotmail dot com Description: pleae try this :) after echo
Bug #51850 [Opn->Fbk]: look
Edit report at http://bugs.php.net/bug.php?id=51850&edit=1 ID: 51850 Updated by: m...@php.net Reported by: heinz50 at hotmail dot com Summary: look -Status: Open +Status: Feedback Type: Bug Package: *General Issues Operating System: every PHP Version: Irrelevant New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2010-05-18 11:03:06] heinz50 at hotmail dot com Description: pleae try this :) after echo
Bug #51832 [Opn->Bgs]: Setting session.gc_maxlifetime but still default value of 1440
Edit report at http://bugs.php.net/bug.php?id=51832&edit=1 ID: 51832 Updated by: m...@php.net Reported by: info at 619cloud dot com Summary: Setting session.gc_maxlifetime but still default value of 1440 -Status: Open +Status: Bogus Type: Bug Package: Session related Operating System: CentOS 5.5 PHP Version: 5.3.2 New Comment: Nevermind. Previous Comments: [2010-05-18 10:44:01] info at 619cloud dot com PROBLEM FOUND. I had a single typo 's' before the opening of the php configuration file, leading to the entire config file not being loaded. I feel silly and stupid. Thanks. [2010-05-18 10:16:46] m...@php.net Not reproducible. Please check that you load the correct php.ini. [2010-05-16 08:42:24] info at 619cloud dot com Description: Just upgraded PHP from 5.2.6 to 5.3.2. I have my session.gc_maxlifetime set to 3 hours, so: session.gc_maxlifetime = 10800 This worked in 5.2.6, verified in phpinfo(), but now when I go into phpinfo() in 5.3.2 it is the default value of 1440. I have gone into the /etc/php.ini and confirmed that session.gc_maxlifetime is indeed still set to 10800. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=51832&edit=1
Bug #48507 [Ver->Bgs]: fgetcsv() ignoring special characters
Edit report at http://bugs.php.net/bug.php?id=48507&edit=1
ID: 48507
Updated by: m...@php.net
Reported by: krynble at yahoo dot com dot br
Summary: fgetcsv() ignoring special characters
-Status: Verified
+Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Unix
PHP Version: 5.*
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Quote from the docs:
Note: Locale setting is taken into account by this function. If LANG is
e.g. en_US.UTF-8, files in one-byte encoding are read wrong by this
function.
Previous Comments:
[2009-12-12 11:40:29] pahan at hubbitus dot spb dot su
Sorry for duplicate (#50456 is my), but in it, additionally to there
described problem in fgetcsv I also suggest fix fputcvs to allow [force]
enclosing single words in field.
Off course it does *not* solve this problem of incorrect fgetcsv
parsing, because RFC allow not quoted values (
http://www.faqs.org/rfcs/rfc4180.html , section 2.5 ), but, it is make
pair fputcsv/fgetcsv as minimum compatible in PHP implementation.
[2009-12-12 01:33:51] j...@php.net
See also bug #50456
[2009-09-22 15:09:20] phofstetter at sensational dot ch
below you'll find a small script which shows how to implement a user
filter that can be used to on-the-fly utf8-encode the data so that
fgetcsv is happy and returns correct output even if the first character
in a field has its high-bit set and is not valid utf-8:
Remember: This is a workaround and impacts performance. This is not a
valid fix for the bug.
I didn't yet have time to deeply look into the C implementation for
fgetcsv, but all these calls to php_mblen() feel suspicious to me.
I'll try and have a look into this later today, but for now, I'm just
glad I have this workaround (quickly hacked together - keep that in
mind):
is_utf8($bucket->data))
$bucket->data = utf8_encode($bucket->data);
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register("utf8encode", "utf8encode_filter")
or die("Failed to register filter");
$fp = fopen($_SERVER['argv'][1], "r");
/* Attach the registered filter to the stream just opened */
stream_filter_prepend($fp, "utf8encode");
while($data = fgetcsv($fp, 0, ';', '"'))
print_r($data);
fclose($fp);
[2009-09-22 14:45:22] phofstetter at sensational dot ch
I was looking into this (after having been bitten by it) and I can add
another tidbit that might help tracking this down:
The bug doesn't happen if the file fgetcsv() is reading is in
UTF-8-format.
I have created a test-file in ISO-8859-1 and then used
file_put_contents(utf8encode(file_get_contents())) to create the
UTF8-version of it (explaining this here because I'm not sure whether
this would write a BOM or not - probably not though).
That version could be read correctly.
I'm now writing a stream filter that does the UTF-8 conversion on the
fly to hook that in between the file and fgetcsv() - while I would lose
a bit of performance, in my case, this is the cleanest workaround.
[2009-09-21 18:11:47] dmulryan at calendarwiz dot com
Note: Previous comment has error where URL is shown in array element.
This is not a bug but my error in the example. Bug is in special
characters.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=48507
--
Edit this bug report at http://bugs.php.net/bug.php?id=48507&edit=1
[PHP-BUG] Bug #51850 [NEW]: look
From: Operating system: every PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:look Description: pleae try this :) after echo
Req #50826 [Opn]: GD: Add the "get values" function
Edit report at http://bugs.php.net/bug.php?id=50826&edit=1 ID: 50826 Updated by: ka...@php.net Reported by: pcfrr at yopmail dot com Summary: GD: Add the "get values" function Status: Open Type: Feature/Change Request Package: GD related Operating System: * PHP Version: 5.3.1 New Comment: I would suggest we redesigned the GD extension instead of having alot getters and setters but perhaps something more abstract like: imageset($im, IMAGE_THICKNESS, 5); echo imageget($im, IMAGE_THICKNESS); /* 5 */ Previous Comments: [2010-01-22 17:13:45] pcfrr at yopmail dot com Description: Hi, I 'spoke' with Pierre in libgd's chat. I answered if exist the function to GET the values of thickness, color, size, but maybe this isn´t. He 'said' me put the bug here. Reproduce code: --- If imagesetthickness($this->im, 2); after how I can GET the thickness? maybe this function not exist. -- Edit this bug report at http://bugs.php.net/bug.php?id=50826&edit=1
Req #51793 [Opn->Asn]: Add alpha argument to imagecolorset
Edit report at http://bugs.php.net/bug.php?id=51793&edit=1 ID: 51793 Updated by: ka...@php.net Reported by: Anders dot Nilsson at noaa dot gov Summary: Add alpha argument to imagecolorset -Status: Open +Status: Assigned Type: Feature/Change Request Package: GD related Operating System: linux PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye New Comment: Pierre, can you please review my patch and if needed approve it for trunk? Previous Comments: [2010-05-18 10:44:37] ka...@php.net The following patch has been added/updated: Patch Name: imagecolorset-alpha Revision: 1274172277 URL: http://bugs.php.net/patch-display.php?bug=51793&patch=imagecolorset-alpha&revision=1274172277 [2010-05-11 16:01:23] Anders dot Nilsson at noaa dot gov Description: Imagecolorset currently has no argument to set the alpha color component in an indexed color image. This capability would be very useful. (Especially when dealing with functions that use antialiasing but don't handle alpha transparency well). Change to: void imagecolorset ( resource $image, int $index, int $red, int $green, int $blue [, int $alpha ] ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51793&edit=1
Req #51793 [PATCH]: Add alpha argument to imagecolorset
Edit report at http://bugs.php.net/bug.php?id=51793&edit=1 ID: 51793 Patch added by: ka...@php.net Reported by: Anders dot Nilsson at noaa dot gov Summary: Add alpha argument to imagecolorset Status: Open Type: Feature/Change Request Package: GD related Operating System: linux PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: imagecolorset-alpha Revision: 1274172277 URL: http://bugs.php.net/patch-display.php?bug=51793&patch=imagecolorset-alpha&revision=1274172277 Previous Comments: [2010-05-11 16:01:23] Anders dot Nilsson at noaa dot gov Description: Imagecolorset currently has no argument to set the alpha color component in an indexed color image. This capability would be very useful. (Especially when dealing with functions that use antialiasing but don't handle alpha transparency well). Change to: void imagecolorset ( resource $image, int $index, int $red, int $green, int $blue [, int $alpha ] ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51793&edit=1
Bug #51832 [Fbk->Opn]: Setting session.gc_maxlifetime but still default value of 1440
Edit report at http://bugs.php.net/bug.php?id=51832&edit=1 ID: 51832 User updated by: info at 619cloud dot com Reported by: info at 619cloud dot com Summary: Setting session.gc_maxlifetime but still default value of 1440 -Status: Feedback +Status: Open Type: Bug Package: Session related Operating System: CentOS 5.5 PHP Version: 5.3.2 New Comment: PROBLEM FOUND. I had a single typo 's' before the opening of the php configuration file, leading to the entire config file not being loaded. I feel silly and stupid. Thanks. Previous Comments: [2010-05-18 10:16:46] m...@php.net Not reproducible. Please check that you load the correct php.ini. [2010-05-16 08:42:24] info at 619cloud dot com Description: Just upgraded PHP from 5.2.6 to 5.3.2. I have my session.gc_maxlifetime set to 3 hours, so: session.gc_maxlifetime = 10800 This worked in 5.2.6, verified in phpinfo(), but now when I go into phpinfo() in 5.3.2 it is the default value of 1440. I have gone into the /etc/php.ini and confirmed that session.gc_maxlifetime is indeed still set to 10800. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=51832&edit=1
Bug #51778 [Opn]: crash on libphp5.so, when running ampache's initial scripts
Edit report at http://bugs.php.net/bug.php?id=51778&edit=1
ID: 51778
Updated by: m...@php.net
Reported by: nkostis at gmail dot com
Summary: crash on libphp5.so, when running ampache's initial
scripts
Status: Open
Type: Bug
Package: Apache2 related
Operating System: plugapps (arch linux)
PHP Version: 5.2.13
New Comment:
Nope, sorry. I'm running PHP on 2.6.33-ARCH x86_64 without problems, but
that doesn't mean anything to your problem.
Previous Comments:
[2010-05-12 19:12:28] nkostis at gmail dot com
Ok, this script works:
while this one crashes apache (with the same stack trace as initially
posted):
Finally if i run the same script without an argument passed for
dirname:
php issues an error, but there's no crash.
This implies stack corruption and compiler problems, but calling:
$row_classes = array('even', 'odd');
doesn't crash apache.
any ideas? is this helpful at all?
[2010-05-12 09:09:38] m...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-05-09 23:06:53] nkostis at gmail dot com
Description:
I get this core dump when running anything from ampache (test.php,
index.php,
install.php, any ampache version):
#0 0x406300a8 in _zval_ptr_dtor () from /etc/httpd/modules/libphp5.so
#1 0x40660624 in zend_do_fcall_common_helper_SPEC () from
/etc/httpd/modules/libphp5.so
#2 0x4065dec8 in execute () from /etc/httpd/modules/libphp5.so
the rest of the stack trace is unknown as LAMP runs on limited hardware
(the
pogoplug) and i have not install debug symbols.
Pogoplug currently runs plugapps, an arm optimized version of Arch
linux. I am
not sure whether this crash is a vanilla php bug or a plugapps php
issue.
A basic "phpinfo()" script runs fine so at least basic php operation is
properly
configured.
Sorry if the bug is not vanilla php and i'm wasting your time.
Test script:
---
any ampache script, i.e. test.php (http://pastebin.com/FXAtKNyJ), run on
plugbox linux (arch 2.6.33 based)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51778&edit=1
Bug #51832 [Opn->Fbk]: Setting session.gc_maxlifetime but still default value of 1440
Edit report at http://bugs.php.net/bug.php?id=51832&edit=1 ID: 51832 Updated by: m...@php.net Reported by: info at 619cloud dot com Summary: Setting session.gc_maxlifetime but still default value of 1440 -Status: Open +Status: Feedback Type: Bug Package: Session related Operating System: CentOS 5.5 PHP Version: 5.3.2 New Comment: Not reproducible. Please check that you load the correct php.ini. Previous Comments: [2010-05-16 08:42:24] info at 619cloud dot com Description: Just upgraded PHP from 5.2.6 to 5.3.2. I have my session.gc_maxlifetime set to 3 hours, so: session.gc_maxlifetime = 10800 This worked in 5.2.6, verified in phpinfo(), but now when I go into phpinfo() in 5.3.2 it is the default value of 1440. I have gone into the /etc/php.ini and confirmed that session.gc_maxlifetime is indeed still set to 10800. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=51832&edit=1
Bug #49200 [Opn->Bgs]: stream bindto context generates an error
Edit report at http://bugs.php.net/bug.php?id=49200&edit=1
ID: 49200
Updated by: m...@php.net
Reported by: jeremy at ssnet dot ca
Summary: stream bindto context generates an error
-Status: Open
+Status: Bogus
Type: Bug
Package: Streams related
Operating System: FreeBSD 7.2-STABLE
PHP Version: 6SVN-2009-08-09 (SVN)
New Comment:
Not reproducible, I get
Warning: file_get_contents(http://php.net): failed to open stream:
Invalid argument
unless I specify an IP address connected to the outside world.
Previous Comments:
[2009-08-09 09:40:08] jeremy at ssnet dot ca
Description:
Specifying any IP address for bindto in stream_context_set_option()
produces an error "(local_addr context option is not a string.)"
Reproduce code:
---
$context = stream_context_create ();
stream_context_set_option ($context, 'socket', 'bindto',
'127.0.0.1:0');
$contents = file_get_contents ("http://php.net";, FALSE, $context);
Expected result:
Should return the contents of php.net
Actual result:
--
Warning: file_get_contents(http://php.net/): failed to open stream:
local_addr context option is not a string.
--
Edit this bug report at http://bugs.php.net/bug.php?id=49200&edit=1
[PHP-BUG] Req #51848 [NEW]: Non-object method call errors should be catchable with set_error_handler()
From: Operating system: N/A PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:Non-object method call errors should be catchable with set_error_handler() Description: Calling member functions on non-object variables fails with a fatal error. This error is not catchable using PHP's internal error handling configured using set_error_handler(). See the test script below for an example. I think error handlers should be able to catch this problem. We use a lot of ORM in our applications which involves a lot of object getting, and sometimes we forget to check whether we really have an object. We rely on PHP's error handling to tell us exactly what's going on but cannot use this functionality at this moment. I believe some errors are not handled by the custom handler because of the unknown or unstable state the engine resides in after the the error. For this case, it's true as the desired method execution / code jump never takes place. I think this can be solved (for this particular error) by stopping execution after calling the custom handler. Bug #12136 (closed) describes this problem but describes it as a design feature. I think this design can be improved a bit. Test script: --- nonExistingMethod(); Expected result: The custom error handler function arguments as per print_r(func_get_args()). Actual result: -- Fatal error: Call to a member function nonExistingMethod() on a non-object in fatalErrorHandling.php on line 11 -- Edit bug report at http://bugs.php.net/bug.php?id=51848&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51848&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51848&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51848&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51848&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51848&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51848&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51848&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51848&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51848&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51848&r=support Expected behavior: http://bugs.php.net/fix.php?id=51848&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51848&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51848&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51848&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51848&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51848&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51848&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51848&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51848&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51848&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51848&r=mysqlcfg
Bug #51847 [Opn->Fbk]: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale
Edit report at http://bugs.php.net/bug.php?id=51847&edit=1 ID: 51847 Updated by: ka...@php.net Reported by: php-bugs-2010 at ryandesign dot com Summary: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale -Status: Open +Status: Feedback Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.3 x86_64 PHP Version: 5.2.13 Previous Comments: [2010-05-18 10:04:40] ka...@php.net Hi Does this happen with 5.3 aswell? Does adding the following include after including 'ext/standard/php_uuencode.h' work: #include "ext/standard/php_string.h" [2010-05-18 05:09:31] php-bugs-2010 at ryandesign dot com Modify summary. [2010-05-18 05:07:58] php-bugs-2010 at ryandesign dot com Description: Hello, I'm the maintainer of the php packages in MacPorts, and it seems that php 5.2.13 doesn't build with gettext 0.18 (at least not on Mac OS X 10.6.3 x86_64). It fails with: Undefined symbols: "_zif_setlocale", referenced from: _basic_functions in basic_functions.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 php 5.2.13 builds fine with gettext 0.17, and php 5.3.2 builds fine with gettext 0.17 and 0.18. Here's the bug report that was submitted to us: http://trac.macports.org/ticket/24934 -- Edit this bug report at http://bugs.php.net/bug.php?id=51847&edit=1
Bug #51847 [Opn]: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale
Edit report at http://bugs.php.net/bug.php?id=51847&edit=1 ID: 51847 Updated by: ka...@php.net Reported by: php-bugs-2010 at ryandesign dot com Summary: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale Status: Open Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.3 x86_64 PHP Version: 5.2.13 New Comment: Hi Does this happen with 5.3 aswell? Does adding the following include after including 'ext/standard/php_uuencode.h' work: #include "ext/standard/php_string.h" Previous Comments: [2010-05-18 05:09:31] php-bugs-2010 at ryandesign dot com Modify summary. [2010-05-18 05:07:58] php-bugs-2010 at ryandesign dot com Description: Hello, I'm the maintainer of the php packages in MacPorts, and it seems that php 5.2.13 doesn't build with gettext 0.18 (at least not on Mac OS X 10.6.3 x86_64). It fails with: Undefined symbols: "_zif_setlocale", referenced from: _basic_functions in basic_functions.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 php 5.2.13 builds fine with gettext 0.17, and php 5.3.2 builds fine with gettext 0.17 and 0.18. Here's the bug report that was submitted to us: http://trac.macports.org/ticket/24934 -- Edit this bug report at http://bugs.php.net/bug.php?id=51847&edit=1
Bug #51749 [Opn]: header("Location:") changing HTTP status
Edit report at http://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Updated by: m...@php.net
Reported by: theimp at iinet dot net dot au
Summary: header("Location:") changing HTTP status
Status: Open
Type: Bug
Package: HTTP related
Operating System: Debian Lenny
PHP Version: 5.3.2
New Comment:
Maybe, but header("HTTP/1.1 XXX") is just a hack and I see no hard
reason to introduce other hacks to support a hack in the first place.
You are writing *pages* about code that's *years* old and worked that
way for a long long time, and there's very little chance to become that
changed. You know, PHP is an acronym for BC, or was it the other way
round...
Previous Comments:
[2010-05-12 14:19:48] theimp at iinet dot net dot au
@ mike at php dot net
I did more testing, and yes, if you use the additional parameters on the
occasion that you send the location header, the special handling of the
Location header does not override the explicit behavior.
So:
header("HTTP/1.1 503 Service Unavailable", true, 503);
header("Location: http://www.php.net/";);
Does not work; but:
header("HTTP/1.1 503 Service Unavailable");
header("Location: http://www.php.net/";, true, 503);
Does work.
Obvious, in hindsight. But very confusing at first. The documentation
for http_response_code simply says: "Forces the HTTP response code to
the specified value"; I read that as forcing the response code
irrespective of any other later action other than another
http_response_code. It's not quite a documentation bug, since it's not
strictly wrong, but it should probably be changed, because it is easy to
read other than as intended. I would accept changing this bug to a
documentation bug.
@ aharvey at php dot net
The functionality I expected exists; I simply did not understand it. But
I do agree with what you say also; it is questionable whether it should
behave the way that it does even aside from other functionality.
To really know how this should be treated requires, I think,
consideration of the points I have previously mentioned. Presumably,
this specific behavior was put into PHP for a reason, and it was not
changed much when the opportunity last arose. I do not know the specific
goals of the PHP project in this respect.
I would not have written this bug report if I had realized the correct
way to use the http_response_code parameter.
Also, the workaround mentioned in bug #25044 is still possible.
Finally, I had not properly considered RFC 3875 when I first created
this bug report. If I had, I would probably have decided that the
behavior is deliberate and was not expected to be fixed.
The http_response_code is confusing, since it can be set on unrelated
headers, making it difficult to track down the code that sets it since
it could be a place other than where you set the Response Line itself
(in principle, any header; practically, any Location header in addition
to the Response Line header).
Also, the HTTP Response Code that you want to set must be known at the
time you want to set the Location header, which might not be known at
that time. It might have already been set in another function; there is
no way to retrieve the response code that you have set, so you have to
remember it yourself by assigning it to a variable and re-using that
variable at the time you set the Location header.
For example:
...
if ($_SERVER["HTTPS"] != "on") {
setstatus(426);
setlocation("https");
}
...
function setstatus($status)
{
switch ($status)
{
...
case 426:
header("HTTP/1.1 426 Upgrade Required");
break;
...
}
}
...
function setlocation($scheme)
{
switch ($scheme)
{
...
case "https":
header('Location: $scheme://$url');
break;
...
}
}
A better solution may have been, rather than to add the
http_response_code parameter, to have added a force_response() function
to optionally set the HTTP Response Code, which would not be
overwritten. But we are long past the point that it makes sense to add
such a function; it would add no new functionality and would deprecate
existing uses of unrelated code.
While I do think that PHP should not set the Response Code after a
Location header, there are still reasons to consider this behavior
appropriate (standards compliance and backwards-compatibility), which I
have already discussed at length.
On the other hand; fixing this "bug" in a way similar to the one I
suggested would make PHP more robust and make it much more likely that
people get the behavior that they expect after they read all of the
relevant documentation. It may also help with bug-finding in the case of
incorrect header output, and simplify some functions, depending on how
they have been designe
Bug #51846 [Opn]: SimpleXMLElement iterator produces unexpected results
Edit report at http://bugs.php.net/bug.php?id=51846&edit=1
ID: 51846
Updated by: m...@php.net
Reported by: henning at glatter-gotz dot com
Summary: SimpleXMLElement iterator produces unexpected results
Status: Open
Type: Bug
Package: SimpleXML related
Operating System: windows xp / Linux
PHP Version: 5.3.2
New Comment:
Probably related to Bug #50670
Previous Comments:
[2010-05-18 03:15:02] henning at glatter-gotz dot com
For windows I downloaded the latest available VC6 x86 Thread Safe
(2010-Mar-04
20:11:08) binaries, and tried it (see original report).
I cannot build from Source on Linux, I do not have sufficient access to
a system
to do that. Sorry.
But I did test on two different OS' and 3 different versions of PHP.
[2010-05-18 02:58:11] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-05-18 02:56:11] henning at glatter-gotz dot com
Added Linux (Ubuntu) to the OS field.
[2010-05-18 02:53:34] henning at glatter-gotz dot com
Now also tested on PHP 5.3.2-1ubuntu4.1 with Suhosin-Patch (cli) (built:
May 4 2010 06:56:22). It fails with the same result as on Windows.
[2010-05-18 02:37:26] henning at glatter-gotz dot com
Description:
When loading an xml document with simplexml_load_string() that contains
2500 or
more child elements, iterating over these
with a foreach loop and pushing results into an array results in 4998
array
entries, when only 2500 are expected. See sample
code for the exact conditions under which this occurs.
There are two foreach loops, the first behaves as expected and results
in an
array of exactly 2500 objects of type A,
whereas the second foreach loop that instantiates an object of type B in
each
iteration ends up being of size 4998.
Note that the object B takes two parameters in the constructor. This
behavior is
only exhibited if both parameters are
arrays. If one is changed to an int for example the code runs as
expected.
Also, if the xml files contains 2499 elements or less, the code also
works as
expected.
Executed on the command line in the following environments:
1) Windows XP, PHP 5.3.1 (cli) (built: Nov 20 2009 17:26:32) -> FAIL
2) Windows XP, PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13) -> FAIL
3) PHP 5.2.10-2ubuntu6.4 with Suhosin-Patch 0.9.7 (cli) (built: Jan 6
2010
22:56:44) -> SUCCESS
Setups 1 and 3 are production environments and have slightly modified
php.ini
files. Setup 2 is an "out of the box" download
of VC6 x86 Thread Safe (2010-Mar-04 20:11:08) from
http://windows.php.net/download/. No changes were made to it.
Test script:
---
class A
{}
class B
{
protected $v1;
protected $v2;
public function __construct($v1, $v2) {
$this->v1 = $v1;
$this->v2 = $v2;
}
}
$xml_string = "";
for ($i = 0; $i < 2500; ++$i) {
$xml_string .= "bla";
}
$xml_string .= "";
$xml = simplexml_load_string($xml_string);
$a1 = array();
$a2 = array();
foreach ($xml->row as $r) {
$a1[] = new A();
}
foreach ($xml->row as $r) {
$val1 = array();
$val2 = array();
$a2[] = new B($val1, $val2);
}
echo 'count(a1) = '.count($a1).PHP_EOL;
echo 'count(a2) = '.count($a2).PHP_EOL;
Expected result:
count(a1) = 2500
count(a2) = 2500
Actual result:
--
count(a1) = 2500
count(a2) = 4998
--
Edit this bug report at http://bugs.php.net/bug.php?id=51846&edit=1
Bug #49819 [Opn->Csd]: STDOUT losing data with posix_isatty()
Edit report at http://bugs.php.net/bug.php?id=49819&edit=1 ID: 49819 Updated by: m...@php.net Reported by: cschneid at cschneid dot com Summary: STDOUT losing data with posix_isatty() -Status: Open +Status: Closed Type:Bug Package: Streams related PHP Version: 5.2, 5.3, 6 -Assigned To: +Assigned To: mike New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-05-18 09:25:31] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=299437 Log: * fixed bug #49819: STDOUT losing data with posix_isatty() [2009-10-11 09:41:07] sjo...@php.net Could reproduce with PHP 5.3-HEAD. [2009-10-09 12:54:53] cschneid at cschneid dot com --- sapi/cli/php_cli.c (revision 289412) +++ sapi/cli/php_cli.c (working copy) @@ -565,6 +565,10 @@ s_err->flags |= PHP_STREAM_FLAG_NO_CLOSE; #endif + s_in->flags |= PHP_STREAM_FLAG_NO_SEEK; + s_out->flags |= PHP_STREAM_FLAG_NO_SEEK; + s_err->flags |= PHP_STREAM_FLAG_NO_SEEK; + s_in_process = s_in; php_stream_to_zval(s_in, zin); [2009-10-09 12:50:19] cschneid at cschneid dot com Description: The PHP streams for stdin, stdout and stderr are seekable which results in php_stream_flush() and seek being called on it. For some reason php_stream_flush() fails to actually write the data while still calling seek and resetting the stream position. Suggested solution: - Find out why php_stream_flush() fails and fix it (I don't know enough about it) - Mark (some? all?) stdio streams as PHP_STREAM_FLAG_NO_SEEK in sapi/cli/php_cli.c (see patch) - Mark stdio streams as PHP_STREAM_FLAG_NO_SEEK in ext/standard/php_fopen_wrapper.c Reproduce code: --- php -r 'echo "hello1\n"; posix_isatty(STDOUT); echo "hello2\n";' >out; cat out Expected result: hello1 hello2 Actual result: -- hello2 -- Edit this bug report at http://bugs.php.net/bug.php?id=49819&edit=1
Bug #51631 [Com]: MySQLi query result depend on browser
Edit report at http://bugs.php.net/bug.php?id=51631&edit=1 ID: 51631 Comment by: evgpanchenko at gmail dot com Reported by: evgpanchenko at gmail dot com Summary: MySQLi query result depend on browser Status: Feedback Type: Bug Package: MySQLi related Operating System: Windows/Linux PHP Version: 5.3.2 New Comment: same code, different results. log to file gave the same result: 12,00 in Opera and Chrome 12,00 in mozilla and IE Previous Comments: [2010-05-11 12:07:17] and...@php.net Please check what the source of the page you are receiving. Is it the same? If yes, then the browser is the problem. [2010-04-22 11:50:22] evgpanchenko at gmail dot com Description: I have in MySQL Table with columns price DECIMAL(6,2), issm tinyint, cnt int When I run request SELECT IF(issm=1, ROUND(price/cnt, 6), price) AS price, issm with mysqli i get 12,00 1 12,00 0 in Opera and Chrome but i get 12,00 1 12,00 0 in mozilla and IE -- Edit this bug report at http://bugs.php.net/bug.php?id=51631&edit=1
