#48867 [Opn]: Casting 0xffffffffffffffff to int does not returns -1
ID: 48867 Updated by: magical...@php.net Reported By: magical...@php.net Status: Open Bug Type: Scripting Engine problem Operating System: Linux x86_64 PHP Version: 5.2.10 New Comment: uname -a of test machines: Linux Memol.ooKoo.org 2.6.28-gentoo-r3-tux #1 SMP Thu Mar 12 22:09:11 CET 2009 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux Linux localhost 2.6.30-gentoo-r1 #1 SMP Tue Jun 30 14:06:51 Local time zone must be set--see zic x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux Previous Comments: [2009-07-09 11:40:55] magical...@php.net Description: Casting hexadecimal representation of -1 to int is supposed to return -1 in php. It seems to not reproduce on sunOS. sapi/cli/php -r 'var_dump((int)0x);' int(-1) SunOS t2000-010131 5.11 snv_101 sun4v sparc SUNW,Sun-Fire-T200 Solaris It was reproduced on the following distro of Linux: Gentoo, Arch It was also reproduced on a self-compiled version of PHP 5.2.10 Reproduce code: --- magical...@memol ~ $ php -r 'var_dump((int)0x);' Expected result: int(-1) Actual result: -- int(0) -- Edit this bug report at http://bugs.php.net/?id=48867&edit=1
#48867 [Opn]: Casting 0xffffffffffffffff to int does not returns -1
ID: 48867 Updated by: magical...@php.net Reported By: magical...@php.net Status: Open Bug Type: Scripting Engine problem Operating System: Linux x86_64 PHP Version: 5.2.10 New Comment: Reproduced on 5.2.9: Kaze ~ # php -v PHP 5.2.9-pl2-gentoo (cli) (built: May 11 2009 19:07:50) (DEBUG) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Kaze ~ # php -r 'var_dump((int)0x);' int(0) Kaze ~ # uname -a Linux Kaze 2.6.29-gentoo-tux #1 SMP PREEMPT Fri Apr 17 00:36:53 CEST 2009 x86_64 Intel(R) Core(TM)2 CPU U7500 @ 1.06GHz GenuineIntel GNU/Linux Previous Comments: [2009-07-09 11:45:56] c dot robin at smartphp dot org Reproduced on ArchLinux ( both compiled package and custom compiled PHP with no patches ). Uname: Linux devrobin 2.6.30-ARCH #1 SMP PREEMPT Sat Jul 4 02:24:43 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz GenuineIntel GNU/Linux [2009-07-09 11:44:21] magical...@php.net uname -a of test machines: Linux Memol.ooKoo.org 2.6.28-gentoo-r3-tux #1 SMP Thu Mar 12 22:09:11 CET 2009 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux Linux localhost 2.6.30-gentoo-r1 #1 SMP Tue Jun 30 14:06:51 Local time zone must be set--see zic x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux [2009-07-09 11:40:55] magical...@php.net Description: Casting hexadecimal representation of -1 to int is supposed to return -1 in php. It seems to not reproduce on sunOS. sapi/cli/php -r 'var_dump((int)0x);' int(-1) SunOS t2000-010131 5.11 snv_101 sun4v sparc SUNW,Sun-Fire-T200 Solaris It was reproduced on the following distro of Linux: Gentoo, Arch It was also reproduced on a self-compiled version of PHP 5.2.10 Reproduce code: --- magical...@memol ~ $ php -r 'var_dump((int)0x);' Expected result: int(-1) Actual result: -- int(0) -- Edit this bug report at http://bugs.php.net/?id=48867&edit=1
#49204 [Opn]: Late Static Binding class name problem
ID: 49204 Updated by: magical...@php.net Reported By: magical...@php.net Status: Open Bug Type: Scripting Engine problem Operating System: Linux x86_64 PHP Version: 5.3.0 New Comment: I tried duplicating the base "Singleton" class into "Singleton2", and make C extend Singleton2, and the problem still happens. Fatal error: Call to protected C::__construct() from context 'Singleton' in /home/magicaltux/foo.php on line 9 The right context is called (class "Singleton") but get_called_class() still returns "C" instead of "B". Previous Comments: [2009-08-10 06:14:07] magical...@php.net Description: In some cases the class name as returned by get_called_class() is incorrect. Can't explain this clearly without more sleep, but the following reproduction code should help understanding the problem. I tried to simplify the code, but the bug disappears in this case. Expected behaviour is to have class C constructed, then class B constructed, with a nice "Here is B\n" displayed. In reality the B::getInstance() static call done from C::__construct doesn't change the classname for LSB, meaning that when Singleton::getInstance() will call get_called_class() it will receive "C" (and letting us enter into an infinite recursion). Reproduce code: --- http://bugs.php.net/?id=49204&edit=1
#49203 [Opn]: call_user_func_array when calling a parent constructor not from a user class
ID: 49203
Updated by: magical...@php.net
Reported By: magical...@php.net
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
Ok, mysqli's contructor is not named "__construct"
Method [ public method mysqli ] {
}
Still, one would expect that calling
call_user_func_array(array('parent', '__construct'), ...) acts the same
as parent::__construct(...) (which works). I guess somewhere the call to
__construct must be redirected to the ctor...
Previous Comments:
[2009-08-10 07:48:18] col...@php.net
The problem is not about internal classes, but classes not defining a
__construct:
class A {
}
class B extends A {
public function __construct() {
echo "here\n";
call_user_func(array('parent', '__construct'));
}
}
$x = new B;
seems like is_callable() returns true on array('parent', '__construct')
and shouldn't.
[2009-08-10 03:57:09] magical...@php.net
Description:
When using:
call_user_func_array(array('parent', '__construct'), $var);
This works if the parent is a user-defined class, but not if it's an
extension-provided class (the extended constructor gets called twice).
This is not easy to explain, see attached reproduce code for more
details.
My initial code was (in a class extending mysqli):
private function __construct($params) {
call_user_func_array(array('parent', '__construct'),
$params);
$this->set_charset('utf8');
}
Using this instead awfully fixes the problem:
parent::__construct($params[0], $params[1], $params[2], $params[3]);
Note that this wasn't possible in PHP 5.2.x
Warning: call_user_func_array(): First argument is expected to be a
valid callback, 'parent::__construct' was given in foo.php on line 5
Reproduce code:
---
http://bugs.php.net/?id=49203&edit=1
#45037 [Opn->Bgs]: wddx_add_vars() does not convert variable names to UTF8
ID: 45037
Updated by: [EMAIL PROTECTED]
Reported By: JeanLuc dot TRIPLET at yahoo dot fr
-Status: Open
+Status: Bogus
Bug Type: WDDX related
Operating System: Windows
PHP Version: 5.2.6
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
Previous Comments:
[2008-11-16 10:17:53] mark at hell dot ne dot jp
This report is bogus, as WDDX is not supposed to convert content to
UTF-8 either.
Please see bug #46496 for more infos.
[2008-09-02 10:19:03] JeanLuc dot TRIPLET at yahoo dot fr
Modifying wddx.c as below solves the problem (php_wddx_serialize_var
also encode parameter names in addition to parameter values) :
Original wddx.c :
void php_wddx_serialize_var(wddx_packet *packet, zval *var, char *name,
int name
_len TSRMLS_DC)
{
char *tmp_buf;
char *name_esc;
int name_esc_len;
HashTable *ht;
if (name) {
name_esc = php_escape_html_entities(name, name_len,
&name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
tmp_buf = emalloc(name_esc_len + sizeof(WDDX_VAR_S));
snprintf(tmp_buf, name_esc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, name_esc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
}
Mofified wddx.c :
void php_wddx_serialize_var(wddx_packet *packet, zval *var, char *name,
int name
_len TSRMLS_DC)
{
char *tmp_buf;
char *enc;
char *name_esc;
int name_esc_len;
int enc_len;
HashTable *ht;
if (name) {
name_esc = php_escape_html_entities(name, name_len,
&name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
enc = xml_utf8_encode(name_esc, name_esc_len, &enc_len,
"ISO-8859-1");
tmp_buf = emalloc(enc_len + sizeof(WDDX_VAR_S));
snprintf(tmp_buf, enc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, enc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
efree(enc);
Could you, please, include some modification like this one in future
versions.
Thanks in advance.
[2008-05-19 10:13:11] JeanLuc dot TRIPLET at yahoo dot fr
Description:
wddx_add_vars() correctly converts values to UTF-8, but doesn't convert
var names to UTF-8, so wddx_deserialize() return an empty array as XML
packet contains var names with accent.
below is a script showing that string values are converted to UTF-8 by
wddx_add_vars, but var names are not converted. It also show that
wddx_deserialize() works fine when input packet contains UTF_8 encoded
var names manually, but doesn't work when var names are let accentuated
by wddx_add_vars().
Could you please, modify wddx_add_vars, to UTF_8 encode var names as
already done for string values ?
Thank for your help.
Reproduce code:
---
PHPvalue
é";
var_dump ($packet);
$result = wddx_deserialize($packet);
var_dump ($result);
?>
Expected result:
string(159) "value é"
array(1) { ["varname"]=> string(7) "value é" }
string(160) "value é"
array(1) { ["varnameé"]=> string(7) "value é" }
string(161) "value é"
array(1) { ["varnameé"]=> string(7) "value é" }
Actual result:
--
string(159) "value é"
array(1) { ["varname"]=> string(7) "value é" }
string(160) "value é"
array(0) { }
string(161) "value é"
array(1) { ["varnameé"]=> string(7) "value é" }
--
Edit this bug report at http://bugs.php.net/?id=45037&edit=1
#45314 [Opn->Bgs]: wddx_serialize_value() does not handle unicode properly
ID: 45314 Updated by: [EMAIL PROTECTED] Reported By: mikx at mikx dot de -Status: Open +Status: Bogus Bug Type: WDDX related Operating System: * PHP Version: 5.2.6 New Comment: This problem has been resolved with bug #46496 in CVS, and will not appear in next versions of PHP. Thanks for your interest in PHP. Previous Comments: [2008-11-16 10:20:12] mark at hell dot ne dot jp This bug is related to bug #46496. Bug #37571 indeed seems to be at the origin of the problem. [2008-07-22 22:50:54] [EMAIL PROTECTED] I guess (!) the fix for bug #37571 caused this problem. [2008-06-19 12:48:52] mikx at mikx dot de Description: wddx_serialize_value does not deal as expected with unicode characters in PHP 5.2.x or PHP 5.3.x. The function worked differently in PHP 5.1.6. When serializing a string or a more complex objects any unicode characters get again utf8 encoded - instead of getting in as is. Reproduce code: --- Demo (some chinese character) "; echo utf8_encode($_GET["utf8"]).""; echo wddx_serialize_value($_GET["utf8"]).""; } ?> Expected result: The demo code is a little script that outputs the given query parameter "utf8" in three way: 1. Directly as recieved 2. utf8_encoded 3. serialized via wddx_serialize_value In <= 5.1.6 the resulting WDDX contained the utf8 characters excatly as given. In >= 5.2.0 the string gets UTF8 encoded again, just as if you would have valled utf8_encode on it. Actual result: -- While the new behavior might make sense for data going forward (although i am not sure what the expected behavior by WDDX spec is) this breaks backward compatibility with old data. As we have millons of database rows in unicode WDDX data this is a huge issue (at least to us). Can you please clarify if this is a bug, the expected behavior going forward and how to deal with backward compatibility issues (maybe an additional parameter to control the behavior)? This might be related to bug #41722 -- Edit this bug report at http://bugs.php.net/?id=45314&edit=1
#46404 [Opn->Bgs]: request for magic method __toNative()
ID: 46404 Updated by: [EMAIL PROTECTED] Reported By: info at netmosfera dot it -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: irrelevant PHP Version: 5.2.6 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Previous Comments: [2008-10-27 19:15:19] info at netmosfera dot it ~same request http://bugs.php.net/bug.php?id=46128 [2008-10-27 16:42:50] info at netmosfera dot it Description: hello, i'm asking for a new php magic method __toNative() useful for -a better type hinting -user defined implementations of native types -a better way to extend native types without global scope functions or class static functions Reproduce code: --- just a feature request: http://rafb.net/p/qJ97Gf69.html -- Edit this bug report at http://bugs.php.net/?id=46404&edit=1
#46711 [Opn]: cUrl leaks memory
ID: 46711
Updated by: [EMAIL PROTECTED]
Reported By: thomas at koch dot ro
Status: Open
Bug Type: cURL related
Operating System: Debian Lenny
PHP Version: 5.3CVS-2008-11-28 (CVS)
New Comment:
Just for info, I believe there's a bug somewhere.
After the foreach() loop, $opt looks like this:
array(2) {
[58]=>
NULL
[19914]=>
bool(true)
}
Assigning $value by reference in the foreach makes the bug disappear.
I had a look at xml_parser_set_option() (similar function) and tried to
make curl_set_opt() use the same way to get args, it seems to have fixed
the problem (haven't played enough with ZE yet to know for sure if it's
the correct fix).
Patch:
http://ookoo.org/svn/snip/php-5.3.0alpha3_curl_mem_bug.patch
Previous Comments:
[2008-11-28 16:03:14] thomas at koch dot ro
Description:
Setting cURL options in a foreach leaks memory
Reproduce code:
---
$ch = curl_init();
$opt = array(
CURLOPT_AUTOREFERER => TRUE,
CURLOPT_BINARYTRANSFER => TRUE
);
// This works fine:
//curl_setopt( $ch, CURLOPT_AUTOREFERER , TRUE );
//curl_setopt( $ch, CURLOPT_BINARYTRANSFER , TRUE );
// setting the options in a foreach leads to memory leaks
foreach( $opt as $option => $value ) {
curl_setopt( $ch, $option, $value );
}
Expected result:
no output
Actual result:
--
[Fri Nov 28 17:01:18 2008] Script: '/home/ymc-toko/curl_bug.php'
/var/checkouts/php5_3/ext/curl/interface.c(1505) : Freeing 0x030C6BE8
(32 bytes), script=/home/ymc-toko/curl_bug.php
[Fri Nov 28 17:01:18 2008] Script: '/home/ymc-toko/curl_bug.php'
/var/checkouts/php5_3/ext/curl/interface.c(1397) : Freeing 0x030C6C68
(32 bytes), script=/home/ymc-toko/curl_bug.php
=== Total 2 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/?id=46711&edit=1
#46711 [Opn]: cUrl leaks memory
ID: 46711
Updated by: [EMAIL PROTECTED]
Reported By: thomas at koch dot ro
Status: Open
Bug Type: cURL related
Operating System: Debian Lenny
PHP Version: 5.3CVS-2008-11-28 (CVS)
New Comment:
For reference: a test file for this bug (which uses the fact that the
array becomes corrupted).
http://ookoo.org/svn/snip/bug46711.phpt
Previous Comments:
[2008-11-28 17:23:32] [EMAIL PROTECTED]
Just for info, I believe there's a bug somewhere.
After the foreach() loop, $opt looks like this:
array(2) {
[58]=>
NULL
[19914]=>
bool(true)
}
Assigning $value by reference in the foreach makes the bug disappear.
I had a look at xml_parser_set_option() (similar function) and tried to
make curl_set_opt() use the same way to get args, it seems to have fixed
the problem (haven't played enough with ZE yet to know for sure if it's
the correct fix).
Patch:
http://ookoo.org/svn/snip/php-5.3.0alpha3_curl_mem_bug.patch
[2008-11-28 16:03:14] thomas at koch dot ro
Description:
Setting cURL options in a foreach leaks memory
Reproduce code:
---
$ch = curl_init();
$opt = array(
CURLOPT_AUTOREFERER => TRUE,
CURLOPT_BINARYTRANSFER => TRUE
);
// This works fine:
//curl_setopt( $ch, CURLOPT_AUTOREFERER , TRUE );
//curl_setopt( $ch, CURLOPT_BINARYTRANSFER , TRUE );
// setting the options in a foreach leads to memory leaks
foreach( $opt as $option => $value ) {
curl_setopt( $ch, $option, $value );
}
Expected result:
no output
Actual result:
--
[Fri Nov 28 17:01:18 2008] Script: '/home/ymc-toko/curl_bug.php'
/var/checkouts/php5_3/ext/curl/interface.c(1505) : Freeing 0x030C6BE8
(32 bytes), script=/home/ymc-toko/curl_bug.php
[Fri Nov 28 17:01:18 2008] Script: '/home/ymc-toko/curl_bug.php'
/var/checkouts/php5_3/ext/curl/interface.c(1397) : Freeing 0x030C6C68
(32 bytes), script=/home/ymc-toko/curl_bug.php
=== Total 2 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/?id=46711&edit=1
#46727 [Opn]: For loop doesn't work as expected with decimals
ID: 46727
Updated by: [EMAIL PROTECTED]
Reported By: grant at tattomedia dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3CVS-2008-12-01 (snap)
New Comment:
This is because at the last iteration, the value for $val is (at least
on my 5.2.6 test system; php 5.3.0 returns me the same value):
2.000444089209850062616169452667236328125
This is > 2, which means "<= 2" is false.
If I dump the values of $val for each iteration:
0
0.155511151231257827021181583404541015625
0.200011102230246251565404236316680908203125
0.3000444089209850062616169452667236328125
0.40002220446049250313080847263336181640625
0.5
0.59997779553950749686919152736663818359375
0.6999555910790149937383830547332763671875
0.79993338661852249060757458209991455078125
0.899911182158029987476766109466552734375
0.99988897769753748434595763683319091796875
1.0998667732370449812151491641998291015625
1.1999555910790149937383830547332763671875
1.3000444089209850062616169452667236328125
1.4001332267629550187848508358001708984375
1.5002220446049250313080847263336181640625
1.6003108624468950438313186168670654296875
1.7003996802888650563545525074005126953125
1.8004884981308350688777863979339599609375
1.9005773159728050814010202884674072265625
Your "best" option would be to round($val, 1) before checking, but it
might prove to be expensive. This is why it's always tricky to work with
float values.
Previous Comments:
[2008-12-01 21:11:29] grant at tattomedia dot com
Description:
My PHP version is PHP 5.2.5 (cli): This wasn't listed in the select.
It seems that a for loop that deals with floats has bad logic when
evaluating equivalence against another number (in my situation an int).
Reproduce code:
---
$values = array();
for ($val = 0; $val <= 2; $val = $val + .1) {
$values[] = $val;
}
print_r($values);
Expected result:
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 [20] => 2 )
Actual result:
--
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 )
--
Edit this bug report at http://bugs.php.net/?id=46727&edit=1
#46727 [Opn->Bgs]: For loop doesn't work as expected with decimals
ID: 46727
Updated by: [EMAIL PROTECTED]
Reported By: grant at tattomedia dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3CVS-2008-12-01 (snap)
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/en/language.types.float.php and the
instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2008-12-02 05:44:55] [EMAIL PROTECTED]
This is because at the last iteration, the value for $val is (at least
on my 5.2.6 test system; php 5.3.0 returns me the same value):
2.000444089209850062616169452667236328125
This is > 2, which means "<= 2" is false.
If I dump the values of $val for each iteration:
0
0.155511151231257827021181583404541015625
0.200011102230246251565404236316680908203125
0.3000444089209850062616169452667236328125
0.40002220446049250313080847263336181640625
0.5
0.59997779553950749686919152736663818359375
0.6999555910790149937383830547332763671875
0.79993338661852249060757458209991455078125
0.899911182158029987476766109466552734375
0.99988897769753748434595763683319091796875
1.0998667732370449812151491641998291015625
1.1999555910790149937383830547332763671875
1.3000444089209850062616169452667236328125
1.4001332267629550187848508358001708984375
1.5002220446049250313080847263336181640625
1.6003108624468950438313186168670654296875
1.7003996802888650563545525074005126953125
1.8004884981308350688777863979339599609375
1.9005773159728050814010202884674072265625
Your "best" option would be to round($val, 1) before checking, but it
might prove to be expensive. This is why it's always tricky to work with
float values.
[2008-12-01 21:11:29] grant at tattomedia dot com
Description:
My PHP version is PHP 5.2.5 (cli): This wasn't listed in the select.
It seems that a for loop that deals with floats has bad logic when
evaluating equivalence against another number (in my situation an int).
Reproduce code:
---
$values = array();
for ($val = 0; $val <= 2; $val = $val + .1) {
$values[] = $val;
}
print_r($values);
Expected result:
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 [20] => 2 )
Actual result:
--
Array ( [0] => 0 [1] => 0.1 [2] => 0.2 [3] => 0.3 [4] => 0.4 [5] => 0.5
[6] => 0.6 [7] => 0.7 [8] => 0.8 [9] => 0.9 [10] => 1 [11] => 1.1 [12]
=> 1.2 [13] => 1.3 [14] => 1.4 [15] => 1.5 [16] => 1.6 [17] => 1.7 [18]
=> 1.8 [19] => 1.9 )
--
Edit this bug report at http://bugs.php.net/?id=46727&edit=1
#45989 [Opn->Asn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
-Status: Open
+Status: Assigned
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
-Assigned To:
+Assigned To: magicaltux
Previous Comments:
[2008-12-02 18:52:36] steven at acko dot net
till said:
"but it's supposed to return the string as is -- in case it's a literal
type, but why does it in some cases return "null" then?"
What argument is there for having (some) unparseable sequences returned
as is? If json_decode() returns a string, then that should mean that
the
input was a valid JSON encoding of that string, no?
The only literal types JSON allows are numbers and the pre-defined
constants 'true' 'false' and 'null'. Strings must be quote-delimited.
The fact that you can switch between 'return NULL' and 'return the
argument as-is' just by adding/removing a leading space is a pretty big
sign that something is wrong here. To be honest, it seems a bit silly
that this is even an argument.
[2008-12-01 17:16:06] [EMAIL PROTECTED]
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?
For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null
I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as "invalid".
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m
[PHP Modules]
date
json
Reflection
standard
[Zend Modules]
I'm gonna write a test and send it to QA too.
[2008-09-10 01:14:23] steven at acko dot net
Please clarify the bogus classification.
The following each returns NULL, as expected:
var_dump(json_decode('[')); // unmatched bracket
var_dump(json_decode('{')); // unmatched brace
var_dump(json_decode('{}}')); // unmatched brace
var_dump(json_decode('{error error}')); // invalid object key/value
notation
var_dump(json_decode('["\"]')); // unclosed string
var_dump(json_decode('[" \x "]')); // invalid escape code
Yet the following each returns the literal argument as a string:
var_dump(json_decode(' ['));
var_dump(json_decode(' {'));
var_dump(json_decode(' {}}'));
var_dump(json_decode(' {error error}'));
var_dump(json_decode('"\"'));
var_dump(json_decode('" \x "'));
Please examine the examples closely: they are all meaningless, invalid
JSON. Even under the
most widely stretched definition of JSON, the above is not JSON encoded
data. Yet
json_decode() arbitarily returns /some of it/ as a string... and in a
way that looks
suspiciously like a bad parser implementation.
If this was merely a case of json_decode() returning /all/
#45989 [Asn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
Status: Assigned
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
Assigned To: magicaltux
New Comment:
Ok guys, I've had a look at the CVS history for json, and checked why
it was following this weird behaviour (returning what was passed in some
cases, and NULL in other cases).
The CVS commit log message for this relates to bug #38680, however it
seems that the behaviour in parsing strings not handled by json is doing
too much to try to "fix" things and find a way to provide parsed value.
Anyway here's a patch that changes this behaviour to make json_decode()
return NULL when we get invalid JSON data, while still keeping null,
true, false and integers parsing.
Some tests were fixed (the result depended on broken behaviour), and
the other tests still run fine.
The patch itself, against PHP_5_2:
http://ookoo.org/svn/snip/php_5_2-json-returntype-final-fix.patch
If nobody can find anything against this (being a bit more strict with
obviously wrong values) I'll add patchs against HEAD and PHP_5_3.
Previous Comments:
[2008-12-02 18:52:36] steven at acko dot net
till said:
"but it's supposed to return the string as is -- in case it's a literal
type, but why does it in some cases return "null" then?"
What argument is there for having (some) unparseable sequences returned
as is? If json_decode() returns a string, then that should mean that
the
input was a valid JSON encoding of that string, no?
The only literal types JSON allows are numbers and the pre-defined
constants 'true' 'false' and 'null'. Strings must be quote-delimited.
The fact that you can switch between 'return NULL' and 'return the
argument as-is' just by adding/removing a leading space is a pretty big
sign that something is wrong here. To be honest, it seems a bit silly
that this is even an argument.
[2008-12-01 17:16:06] [EMAIL PROTECTED]
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?
For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null
I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as "invalid".
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m
[PHP Modules]
date
json
Reflection
standard
[Zend Modules]
I'm gonna write a test and send it to QA too.
[2008-09-10 01:14:23] steven at acko dot net
Please clarify the bogus classification.
The following each returns NULL, as expected:
var_dump(json_decode('[')); // unmatched bracket
var_dump(json_decode('{')); // unmatched brace
var_dump(json_decode('{}}')); // unmatched brace
var_dump(json_decode('{error error}
#45989 [Asn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
Status: Assigned
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
Assigned To: magicaltux
New Comment:
Just a note for documentation:
http://docs.php.net/json_decode
Right now the documentation says the function returns an object, OR an
array. This is not strictly true as it may return a string, a boolean,
an integer, a double... depending on the input.
Also, the fact json_decode() may return NULL on error isn't explicitly
documented either, instead some examples which happens to return NULL
with the current implementation are provided. I think it would be a good
idea to explicitly document this behavior, if the change I'm proposing
here is accepted.
Previous Comments:
[2008-12-03 21:10:50] [EMAIL PROTECTED]
Ok guys, I've had a look at the CVS history for json, and checked why
it was following this weird behaviour (returning what was passed in some
cases, and NULL in other cases).
The CVS commit log message for this relates to bug #38680, however it
seems that the behaviour in parsing strings not handled by json is doing
too much to try to "fix" things and find a way to provide parsed value.
Anyway here's a patch that changes this behaviour to make json_decode()
return NULL when we get invalid JSON data, while still keeping null,
true, false and integers parsing.
Some tests were fixed (the result depended on broken behaviour), and
the other tests still run fine.
The patch itself, against PHP_5_2:
http://ookoo.org/svn/snip/php_5_2-json-returntype-final-fix.patch
If nobody can find anything against this (being a bit more strict with
obviously wrong values) I'll add patchs against HEAD and PHP_5_3.
[2008-12-02 18:52:36] steven at acko dot net
till said:
"but it's supposed to return the string as is -- in case it's a literal
type, but why does it in some cases return "null" then?"
What argument is there for having (some) unparseable sequences returned
as is? If json_decode() returns a string, then that should mean that
the
input was a valid JSON encoding of that string, no?
The only literal types JSON allows are numbers and the pre-defined
constants 'true' 'false' and 'null'. Strings must be quote-delimited.
The fact that you can switch between 'return NULL' and 'return the
argument as-is' just by adding/removing a leading space is a pretty big
sign that something is wrong here. To be honest, it seems a bit silly
that this is even an argument.
[2008-12-01 17:16:06] [EMAIL PROTECTED]
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?
For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null
I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as "invalid".
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) "'invalid json'"
string(12) "invalid json"
string(2) " {"
string(2) " ["
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configura
#45989 [Asn]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: [EMAIL PROTECTED]
Reported By: steven at acko dot net
Status: Assigned
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
Assigned To: magicaltux
New Comment:
And here are patches against PHP_5_3 and HEAD:
http://ookoo.org/svn/snip/php_5_3-json-returntype-final-fix.patch
http://ookoo.org/svn/snip/php_head-json-returntype-final-fix.patch
Some tests now work on json on HEAD (less failure than what's currently
displayed on gcov.php.net) but still two fails. As those failures are
not within the scope of this bug (and are specific to HEAD) they be
fixed in different patches.
I believe that once this is commited to the CVS, this bug should be
marked as "To be documented". I also believe till wants to submit some
additional tests for those this issue...
Previous Comments:
[2008-12-03 21:17:33] [EMAIL PROTECTED]
Just a note for documentation:
http://docs.php.net/json_decode
Right now the documentation says the function returns an object, OR an
array. This is not strictly true as it may return a string, a boolean,
an integer, a double... depending on the input.
Also, the fact json_decode() may return NULL on error isn't explicitly
documented either, instead some examples which happens to return NULL
with the current implementation are provided. I think it would be a good
idea to explicitly document this behavior, if the change I'm proposing
here is accepted.
[2008-12-03 21:10:50] [EMAIL PROTECTED]
Ok guys, I've had a look at the CVS history for json, and checked why
it was following this weird behaviour (returning what was passed in some
cases, and NULL in other cases).
The CVS commit log message for this relates to bug #38680, however it
seems that the behaviour in parsing strings not handled by json is doing
too much to try to "fix" things and find a way to provide parsed value.
Anyway here's a patch that changes this behaviour to make json_decode()
return NULL when we get invalid JSON data, while still keeping null,
true, false and integers parsing.
Some tests were fixed (the result depended on broken behaviour), and
the other tests still run fine.
The patch itself, against PHP_5_2:
http://ookoo.org/svn/snip/php_5_2-json-returntype-final-fix.patch
If nobody can find anything against this (being a bit more strict with
obviously wrong values) I'll add patchs against HEAD and PHP_5_3.
[2008-12-02 18:52:36] steven at acko dot net
till said:
"but it's supposed to return the string as is -- in case it's a literal
type, but why does it in some cases return "null" then?"
What argument is there for having (some) unparseable sequences returned
as is? If json_decode() returns a string, then that should mean that
the
input was a valid JSON encoding of that string, no?
The only literal types JSON allows are numbers and the pre-defined
constants 'true' 'false' and 'null'. Strings must be quote-delimited.
The fact that you can switch between 'return NULL' and 'return the
argument as-is' just by adding/removing a leading space is a pretty big
sign that something is wrong here. To be honest, it seems a bit silly
that this is even an argument.
[2008-12-01 17:16:06] [EMAIL PROTECTED]
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return "null" then?
For example:
$bad_json = "{ 'bar': 'baz' }";
json_decode($bad_json); // null
I know this is "probably" an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of "NULL", json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that "NULL" is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns "whatever" then the docs should be updated to
tell the u
#46600 [Ver]: "_empty_" key in objects (see #41504)
ID: 46600
Updated by: [EMAIL PROTECTED]
Reported By: Matt at mpcm dot com
Status: Verified
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
I believe this is not a bug, but a feature.
An object *can't* have an empty property (while an array can).
If you want to use json_decode() with json containing empty key, either
access those empty key using special keyword "_empty_", or put the
optionnal $assoc parameter of json_decode() to true to get result as an
array.
If you want objects to support empty keys, I believe this is not going
to happen soon, as this is enforced by a specific error message.
Fatal error: Cannot access empty property in php shell code on line 1
Please note that a property name starting with NULL character won't
work either.
Previous Comments:
[2008-11-18 17:35:30] matt at mpcm dot com
The language seems to create a key that cannot be reached, so even if
this `bug` is fixed, we am still facing a broader issue it seems.
4,"example"=>8);
var_dump($o);
print 'blank key test:' . (isset($o->$key)?'true':'false');
print $o->{$key};
var_dump($o->$key);
?>
output:
object(stdClass)#1 (2) {
[""]=>
int(4)
["example"]=>
int(8)
}
blank key test:false
Fatal error: Cannot access empty property in
PHPDocument1 on line 8
All throws Notice: line 4 - Illegal member variable name
[2008-11-18 15:43:05] matt at mpcm dot com
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as "_empty_" not "". This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
Expected result:
object(stdClass)#1 (1) { [""]=> string(4) "test" }
Actual result:
--
object(stdClass)#2 (1) { ["_empty_"]=> string(4) "test" }
--
Edit this bug report at http://bugs.php.net/?id=46600&edit=1
#46759 [Opn]: magic_quotes_gpc doesn't work
ID: 46759 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Variables related Operating System: Windows PHP Version: 5.2.7 New Comment: Fix for bug #42718 seems at the origin of this bug. If the fix is reverted, magic_quotes_gpc works again as expected. Previous Comments: [2008-12-06 10:03:18] cabel at panic dot com We haven't yet had a chance to addslashes() our input in preparation for PHP 6. So as it stands, this bug -- which we're also seeing with 5.2.7 -- currently means giant scary security holes in our scripts as we were relying on magic_quotes_gpc to make things "safe". Not great... [2008-12-06 01:28:00] brion at pobox dot com This causes downstream MediaWiki bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=16570 Data corruption and failure to properly submit edits when magic_quotes_gpc is enabled. (Workaround: disable magic_quotes_gpc so input doesn't get munged by stripslashes().) Presumably causes similar breakage in every other web app that attempts to correct for magic_quotes_gpc. [2008-12-05 11:52:05] [EMAIL PROTECTED] Description: magic_quotes_gpc doesn't escape $_GET, $_POST, $_COOKIE and $_REQUEST variables. It worked with the same configuration under 5.2.6. I have magic_quotes_gpc set in php.ini. Reproduce code: --- URL: ?q=' http://bugs.php.net/?id=46759&edit=1
#46759 [Opn]: magic_quotes_gpc doesn't work
ID: 46759 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Variables related Operating System: Windows PHP Version: 5.2.7 New Comment: After checking bug #42718 and filter extension's documentation, I believe enabling a filter *should not* disable magic_quotes_gpc (nothing is written in the documentation about this). This patch allows application of magic_quotes_gpc *after* filters execution *if* enabled. http://ookoo.org/svn/snip/php_5_2-broken_filter_and_magic_quotes.patch Previous Comments: [2008-12-06 16:20:04] [EMAIL PROTECTED] Fix for bug #42718 seems at the origin of this bug. If the fix is reverted, magic_quotes_gpc works again as expected. [2008-12-06 10:03:18] cabel at panic dot com We haven't yet had a chance to addslashes() our input in preparation for PHP 6. So as it stands, this bug -- which we're also seeing with 5.2.7 -- currently means giant scary security holes in our scripts as we were relying on magic_quotes_gpc to make things "safe". Not great... [2008-12-06 01:28:00] brion at pobox dot com This causes downstream MediaWiki bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=16570 Data corruption and failure to properly submit edits when magic_quotes_gpc is enabled. (Workaround: disable magic_quotes_gpc so input doesn't get munged by stripslashes().) Presumably causes similar breakage in every other web app that attempts to correct for magic_quotes_gpc. [2008-12-05 11:52:05] [EMAIL PROTECTED] Description: magic_quotes_gpc doesn't escape $_GET, $_POST, $_COOKIE and $_REQUEST variables. It worked with the same configuration under 5.2.6. I have magic_quotes_gpc set in php.ini. Reproduce code: --- URL: ?q=' http://bugs.php.net/?id=46759&edit=1
#42718 [Opn]: FILTER_UNSAFE_RAW not applied when configured as default filter, even with flags
ID: 42718
Updated by: [EMAIL PROTECTED]
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type: Filter related
Operating System: *
PHP Version: 5CVS-2008-11-01
Assigned To: lbarnaud
New Comment:
This is a proposed fix for this bug that will keep old behavior.
Another fix could be simply to test IF_G(default_filter_flags) against
FILTER_FLAG_NO_ENCODE_QUOTES instead of 0.
http://ookoo.org/svn/snip/php_5_2-broken_filter_and_magic_quotes.patch
Previous Comments:
[2008-12-06 17:18:40] [EMAIL PROTECTED]
Reopening, this patch broke magic_quotes_gpc and has been backed out.
[2008-11-02 22:07:23] [EMAIL PROTECTED]
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.
[2008-11-02 13:06:39] [EMAIL PROTECTED]
Arnaud, fix it yourself.
[2007-09-30 06:29:17] [EMAIL PROTECTED]
Pierre, he is right, fix it. :)
[2007-09-29 21:40:46] arnaud dot lb at gmail dot com
Thanks for your reply.
I'm trying to strip low ascii characters from GET/POST/COOKIE using
the filter extension, and the only way to do that is to use the
unsafe_raw filter with the FILTER_FLAG_STRIP_LOW flag.
The string filter can do that with the FILTER_FLAG_STRIP_LOW flag,
but it strips HTML tags too, and I don't want to strip HTML tags.
>From the documentation, about the unsafe_raw filter:
"Do nothing, optionally strip or encode special characters."
It works as expected using filter_var() for example:
filter_var("a \000 c", FILTER_SANITIZE_STRING,
FILTER_FLAG_STRIP_LOW)
=> "a c" (the null char was striped, but the tag too)
filter_var("a \000 c", FILTER_UNSAFE_RAW, FILTER_FLAG_STRIP_LOW)
=> "a c" (only the null char was striped)
But it does not work as a default filter. The bug42718.phpt testcase
demonstrates that.
According to the documentation, I think that the unsafe_raw filter
may not be bypassed when default_flags are != 0. This is the only
change my patch do:
- if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW)) {
+ if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW) ||
IF_G(default_filter_flags) != 0) {
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/42718
--
Edit this bug report at http://bugs.php.net/?id=42718&edit=1
#46756 [Ver]: curl_copy_handle crashes with curl_multi
ID: 46756
Updated by: [EMAIL PROTECTED]
Reported By: kyle at ifixit dot com
Status: Verified
Bug Type: cURL related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-12-08)
New Comment:
I checked the origin of the crash, and it seems that libcurl does NOT
behave good if you duplicate a handle while it's part of a curl_multi.
Calling curl_multi_remove_handle($mh, $conn[$i]); before $conn2[$i] =
curl_copy_handle($conn[$i]); fixes the issue.
Checking curl's documentation, I found it to be quite picky about
processing order. I believe this is either a bug in libcurl, or a
"feature".
libcurl's manpages are not providing exact informations about calling
curl_easy_duphandle() on a curl handle part of a curl_multi.
I'm going to investigate this more and either fix this bug (by
providing a patch) or mark it as bogus (if this is a curl feature).
Previous Comments:
[2008-12-08 11:33:38] [EMAIL PROTECTED]
Verified with latest CVS + Curl 7.18.2
[2008-12-07 16:45:51] kyle at ifixit dot com
Reproducible using libcurl/7.19.2 OpenSSL/0.9.8b zlib/1.2.3
libidn/0.6.5
on kernel 2.6.18-53.1.14.el5. This is not a new bug-- also reproducible
with PHP 5.2.6 and an older version of libcurl.
[2008-12-07 09:54:13] [EMAIL PROTECTED]
I cannot reproduce this on PHP 5.2.7 using Windows Vista
[2008-12-06 15:52:05] crrodriguez at opensuse dot org
VERIFIED, but it is curl_multi_exec() that crashes.
[2008-12-05 06:11:06] kyle at ifixit dot com
Description:
Multicurl crashes when using curl_copy_handle. Setup a multi request
(A), copy the handlers, perform the first multi request (A) and clean
it
up, then perform a second request (B) with the copied handlers. PHP
segfaults (a double free) on one of the handler close calls.
If I don't manually free the multihandle, then the segfault is delayed
until PHP cleans up the objects.
Reproduce code:
---
http://www.google.com/');
curl_setopt($ch, CURLOPT_TIMEOUT, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$conn[$i] = $ch;
curl_multi_add_handle($mh, $ch);
}
// Perform first set of requests
do {
do {
} while (curl_multi_exec($mh, $stillRunning) ===
CURLM_CALL_MULTI_PERFORM);
} while ($stillRunning);
for ($i = 0; $i < $count; $i++) {
// Copy the completed handlers
$conn2[$i] = curl_copy_handle($conn[$i]);
curl_multi_add_handle($mh2, $conn2[$i]);
// Remove the handlers from the first multihandler
curl_multi_remove_handle($mh, $conn[$i]);
curl_close($conn[$i]);
}
curl_multi_close($mh);
echo "Initial requests Finished.\n";
// Perform the second set of requests
do {
do {
} while (curl_multi_exec($mh2, $stillRunning) ===
CURLM_CALL_MULTI_PERFORM);
} while ($stillRunning);
// Remove the second set of completed handlers
for ($i = 0; $i < $count; $i++) {
curl_multi_remove_handle($mh2, $conn2[$i]);
curl_close($conn2[$i]);
}
curl_multi_close($mh2);
echo "Copied requests finished.\n";
?>
Expected result:
Initial requests Finished.
Copied requests finished.
Actual result:
--
*** glibc detected *** php: double free or corruption (out):
0x11e59630 ***
=== Backtrace: =
/lib64/libc.so.6[0x35a906f4f4]
/lib64/libc.so.6(cfree+0x8c)[0x35a9072b1c]
/usr/local/lib/libcurl.so.4(curl_slist_free_all+0x23)[0x2beff893]
php[0x4bd7ee]
php(zend_llist_destroy+0x43)[0x83eb3c]
php(zend_llist_clean+0x15)[0x83eba5]
php[0x4c2094]
php(list_entry_destructor+0x87)[0x85cd84]
php(zend_hash_del_key_or_index+0x218)[0x859e8e]
php(_zend_list_delete+0x69)[0x85c851]
php(_zval_dtor_func+0x142)[0x84934a]
php[0x839385]
php(_zval_ptr_dtor+0x49)[0x8395f2]
php(_zval_ptr_dtor_wrapper+0x21)[0x8496f2]
php(zend_hash_destroy+0x70)[0x859fe1]
php(_zval_dtor_func+0xfb)[0x849303]
php[0x839385]
php(_zval_ptr_dtor+0x49)[0x8395f2]
php(_zval_ptr_dtor_wrapper+0x21)[0x8496f2]
php(zend_hash_clean+0x70)[0x85a133]
php[0x876e58]
php[0x87796d]
php(execute+0x2f4)[0x8764e8]
php[0x876c7c]
php[0x87796d]
php(execute+0x2f4)[0x8764e8]
php[0x876c7c]
php[0x87796d]
php(execute+0x2f4)[0x8764e8]
php[0x876c7c]
php[0x87796d]
php(execute+0x2f4)[0x8764e8]
php[0x876c7c]
php[0x87796d]
php(execute+0x2f4)[0x8764e8]
php[0x876c7c]
php[0x87796d]
php(execute+0x2f4)[0x8764e8]
php(zend_execute_scripts+0x290)[0x84be45]
php(php_execute_script+0x38e)[0x7eb4f4]
php(main+0x143e)[0x8e43d5]
/lib64/libc.so.6(__libc_s
#45161 [Opn]: Reusing a curl handle leaks memory
ID: 45161 Updated by: [EMAIL PROTECTED] Reported By: humbads at alum dot mit dot edu Status: Open Bug Type: cURL related Operating System: * PHP Version: 5CVS, 6CVS (2008-12-08) New Comment: Hi, Managed to get rid of to_free.str, with one exception bugging me: when we call curl_slist_append(), we duplicate the string before, however curl doc says: "curl_slist_append() copies the string." Is this true with all versions of curl? I see nothing written about this in the curl man page. Previous Comments: [2008-10-28 22:25:04] [EMAIL PROTECTED] I have no time to spend on this right now. [2008-08-15 15:37:26] [EMAIL PROTECTED] FYI: This is by design in any resource in PHP. Freeing happens in the request shutdown. Just do unset($ch); in the end of the for loop and $ch = curl_init(); in the start of the loop and you get "static" memory usage. I'm going to only look at what Daniel pointed out and make PHP not duplicate unnecessarily if curl version is >= 7.17.0. [2008-06-22 22:06:30] daniel at haxx dot se I could also add that libcurl does duplicate the input strings since a few versions back (since libcurl 7.17.0), so if such a recent version of libcurl is detected there's no reason at all for PHP to keep copies. This goes for everything except CURLOPT_POSTFIELDS which isn't duplicated for backwards compatiblity reasons, but that one can then be replaced with CURLOPT_COPYPOSTFIELDS which does copy. [2008-06-03 19:24:34] humbads at alum dot mit dot edu I did some more investigation, and found that this is not really a leak as much as it is runaway memory usage. PHP does indeed free the memory eventually. The problem is in interface.c curl_setopt under CURLOPT_URL. The function is making a copy of the string parameter, in this case, the URL, and saving that to the "to_free" list. That list is not freed until sometime later, so repeatedly setting CURLOPT_URL on the same handle will keep using more memory. In the sample code I posted, the memory only increases during the curl_setopt CURLOPT_URL function call. This is just an inefficient design of the PHP curl handle. One way around it is for the code to maintain only one copied string for each CURLOPT string option. If the same CURLOPT string option is set again, it should free the previously created string, and create a new one. At the PHP level, the only workaround for now is to periodically close the handle and then create a new one with curl_init. This seems to cap the memory usage. [2008-06-03 16:07:04] humbads at alum dot mit dot edu Below is the r.php script. When testing this bug report, please use this script (or some other URL) so my poor server does not get hammered. 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/45161 -- Edit this bug report at http://bugs.php.net/?id=45161&edit=1
#46756 [Ver]: curl_copy_handle crashes with curl_multi
ID: 46756 Updated by: [EMAIL PROTECTED] Reported By: kyle at ifixit dot com Status: Verified Bug Type: cURL related Operating System: * PHP Version: 5CVS, 6CVS (2008-12-08) New Comment: This bug has been reproduced without PHP by reproducing the same sequence in C. $ svn co http://ookoo.org/svn/snip/curl_bug ... $ cd curl_bug $ make ... $ gdb ./curl_bug ... #0 0x7f81692626c9 in ?? () from /usr/lib/libcurl.so.4 #1 0x7f8169263ec4 in ?? () from /usr/lib/libcurl.so.4 #2 0x7f816926444c in Curl_connect () from /usr/lib/libcurl.so.4 #3 0x7f81692721ba in ?? () from /usr/lib/libcurl.so.4 #4 0x7f8169272a6e in curl_multi_perform () from /usr/lib/libcurl.so.4 #5 0x00400b34 in main (argc=1, argv=0x7fff716a14d8) at test.c:36 I'll build latest curl with debug mode, check if this can be reproduced, and if so, I'll open a but on libcurl providing more debug informations. Previous Comments: [2008-12-10 19:32:11] [EMAIL PROTECTED] I checked the origin of the crash, and it seems that libcurl does NOT behave good if you duplicate a handle while it's part of a curl_multi. Calling curl_multi_remove_handle($mh, $conn[$i]); before $conn2[$i] = curl_copy_handle($conn[$i]); fixes the issue. Checking curl's documentation, I found it to be quite picky about processing order. I believe this is either a bug in libcurl, or a "feature". libcurl's manpages are not providing exact informations about calling curl_easy_duphandle() on a curl handle part of a curl_multi. I'm going to investigate this more and either fix this bug (by providing a patch) or mark it as bogus (if this is a curl feature). [2008-12-08 11:33:38] [EMAIL PROTECTED] Verified with latest CVS + Curl 7.18.2 [2008-12-07 16:45:51] kyle at ifixit dot com Reproducible using libcurl/7.19.2 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 on kernel 2.6.18-53.1.14.el5. This is not a new bug-- also reproducible with PHP 5.2.6 and an older version of libcurl. [2008-12-07 09:54:13] [EMAIL PROTECTED] I cannot reproduce this on PHP 5.2.7 using Windows Vista [2008-12-06 15:52:05] crrodriguez at opensuse dot org VERIFIED, but it is curl_multi_exec() that crashes. 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/46756 -- Edit this bug report at http://bugs.php.net/?id=46756&edit=1
#46756 [Ver]: curl_copy_handle crashes with curl_multi
ID: 46756 Updated by: [EMAIL PROTECTED] Reported By: kyle at ifixit dot com Status: Verified Bug Type: cURL related Operating System: * PHP Version: 5CVS, 6CVS (2008-12-08) New Comment: Confirmed against curl 7.19.2 and more debug data posted to libcurl's bug tracker. https://sourceforge.net/tracker/index.php?func=detail&aid=2416182&group_id=976&atid=100976 Previous Comments: [2008-12-11 07:18:50] [EMAIL PROTECTED] This bug has been reproduced without PHP by reproducing the same sequence in C. $ svn co http://ookoo.org/svn/snip/curl_bug ... $ cd curl_bug $ make ... $ gdb ./curl_bug ... #0 0x7f81692626c9 in ?? () from /usr/lib/libcurl.so.4 #1 0x7f8169263ec4 in ?? () from /usr/lib/libcurl.so.4 #2 0x7f816926444c in Curl_connect () from /usr/lib/libcurl.so.4 #3 0x7f81692721ba in ?? () from /usr/lib/libcurl.so.4 #4 0x7f8169272a6e in curl_multi_perform () from /usr/lib/libcurl.so.4 #5 0x00400b34 in main (argc=1, argv=0x7fff716a14d8) at test.c:36 I'll build latest curl with debug mode, check if this can be reproduced, and if so, I'll open a but on libcurl providing more debug informations. [2008-12-10 19:32:11] [EMAIL PROTECTED] I checked the origin of the crash, and it seems that libcurl does NOT behave good if you duplicate a handle while it's part of a curl_multi. Calling curl_multi_remove_handle($mh, $conn[$i]); before $conn2[$i] = curl_copy_handle($conn[$i]); fixes the issue. Checking curl's documentation, I found it to be quite picky about processing order. I believe this is either a bug in libcurl, or a "feature". libcurl's manpages are not providing exact informations about calling curl_easy_duphandle() on a curl handle part of a curl_multi. I'm going to investigate this more and either fix this bug (by providing a patch) or mark it as bogus (if this is a curl feature). [2008-12-08 11:33:38] [EMAIL PROTECTED] Verified with latest CVS + Curl 7.18.2 [2008-12-07 16:45:51] kyle at ifixit dot com Reproducible using libcurl/7.19.2 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 on kernel 2.6.18-53.1.14.el5. This is not a new bug-- also reproducible with PHP 5.2.6 and an older version of libcurl. [2008-12-07 09:54:13] [EMAIL PROTECTED] I cannot reproduce this on PHP 5.2.7 using Windows Vista 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/46756 -- Edit this bug report at http://bugs.php.net/?id=46756&edit=1
#45161 [Opn]: Reusing a curl handle leaks memory
ID: 45161 Updated by: [EMAIL PROTECTED] Reported By: humbads at alum dot mit dot edu Status: Open Bug Type: cURL related Operating System: * PHP Version: 5CVS, 6CVS (2008-12-08) New Comment: This patch will get rid of to_free.str if libcurl version is >= 7.17.0 Also: [09:25:46] btw curl doc says: "curl_slist_append() copies the string.", is this true for all versions of libcurl ? [09:26:33] yes So, code duplicating strings before passing them to curl_slist_append() has been completly removed. http://ookoo.org/svn/snip/php_bug45161_curl_textcopy.patch Previous Comments: [2008-12-11 06:03:56] [EMAIL PROTECTED] Hi, Managed to get rid of to_free.str, with one exception bugging me: when we call curl_slist_append(), we duplicate the string before, however curl doc says: "curl_slist_append() copies the string." Is this true with all versions of curl? I see nothing written about this in the curl man page. [2008-10-28 22:25:04] [EMAIL PROTECTED] I have no time to spend on this right now. [2008-08-15 15:37:26] [EMAIL PROTECTED] FYI: This is by design in any resource in PHP. Freeing happens in the request shutdown. Just do unset($ch); in the end of the for loop and $ch = curl_init(); in the start of the loop and you get "static" memory usage. I'm going to only look at what Daniel pointed out and make PHP not duplicate unnecessarily if curl version is >= 7.17.0. [2008-06-22 22:06:30] daniel at haxx dot se I could also add that libcurl does duplicate the input strings since a few versions back (since libcurl 7.17.0), so if such a recent version of libcurl is detected there's no reason at all for PHP to keep copies. This goes for everything except CURLOPT_POSTFIELDS which isn't duplicated for backwards compatiblity reasons, but that one can then be replaced with CURLOPT_COPYPOSTFIELDS which does copy. [2008-06-03 19:24:34] humbads at alum dot mit dot edu I did some more investigation, and found that this is not really a leak as much as it is runaway memory usage. PHP does indeed free the memory eventually. The problem is in interface.c curl_setopt under CURLOPT_URL. The function is making a copy of the string parameter, in this case, the URL, and saving that to the "to_free" list. That list is not freed until sometime later, so repeatedly setting CURLOPT_URL on the same handle will keep using more memory. In the sample code I posted, the memory only increases during the curl_setopt CURLOPT_URL function call. This is just an inefficient design of the PHP curl handle. One way around it is for the code to maintain only one copied string for each CURLOPT string option. If the same CURLOPT string option is set again, it should free the previously created string, and create a new one. At the PHP level, the only workaround for now is to periodically close the handle and then create a new one with curl_init. This seems to cap the memory usage. 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/45161 -- Edit this bug report at http://bugs.php.net/?id=45161&edit=1
#46832 [Opn->Bgs]: memleak on handles duplicated with curl_copy_handle()
ID: 46832 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: cURL related Operating System: Linux PHP Version: 5.2CVS-2008-12-11 (CVS) New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Fix for bug #45161 is likely to fix this issue as well, as long as you have libcurl >= 7.17.0. Thank you for your interest in PHP. Previous Comments: [2008-12-11 05:57:44] [EMAIL PROTECTED] Description: When an handle is copied with curl_copy_handle(), its ability to free memory used by strings is disabled. In ext/curl/interface.c near line 1215 : zend_llist_copy(&dupch->to_free.str, &ch->to_free.str); /* Don't try to free copied strings, they're free'd when the original handle is destroyed */ dupch->to_free.str.dtor = NULL; zend_llist_copy(&dupch->to_free.slist, &ch->to_free.slist); zend_llist_copy(&dupch->to_free.post, &ch->to_free.post); 1. New strings allocated by this new handle will have "NULL" as dtor 2. slist and post will still be free'd on both handles. Freeing one handle first also probably breaks the second handle 3. The copied handle will have unexpected behaviour with libcurl <7.17.0 if the source handle is freed before the copied handle. Two options exists here: 1. Disable this function for people who don't have at least libcurl 7.17.0, and let libcurl handle duplication of strings, etc.. (it now does this automatically, cf bug #45161). 2. Manually duplicate all options that are set in the source curl handle and register them in newly allocated handle on curl_copy_handle(). This can lead to errors as we do not keep record of all set options. Reproduce code: --- http://localhost/test/tset/est'); curl_close($ch2); var_dump(memory_get_usage()); } Expected result: (always the same int dumped) Actual result: -- [...] int(415128) int(415256) int(415384) int(415512) int(415640) int(415768) int(415896) int(416024) int(416152) int(416280) int(416408) int(416536) int(416664) [Thu Dec 11 06:50:37 2008] Script: 'curl_memleak.php' ext/curl/interface.c(1342) : Freeing 0x0198CB78 (31 bytes), script=curl_memleak.php Last leak repeated 2047 times === Total 2048 memory leaks detected === -- Edit this bug report at http://bugs.php.net/?id=46832&edit=1
#46756 [Ver->Csd]: curl_copy_handle crashes with curl_multi
ID: 46756 Updated by: magical...@php.net Reported By: kyle at ifixit dot com -Status: Verified +Status: Closed Bug Type: cURL related Operating System: * PHP Version: 5CVS, 6CVS (2008-12-08) New Comment: This bug has been fixed in libcurl's CVS. Snapshots of libcurl's sources are packaged every day; this change will be in the next snapshot. You can grab the snapshot at http://cool.haxx.se/curl-daily/. Thank you for the report, and for helping us make libcurl and PHP better. Previous Comments: [2008-12-11 07:56:17] magical...@php.net Confirmed against curl 7.19.2 and more debug data posted to libcurl's bug tracker. https://sourceforge.net/tracker/index.php?func=detail&aid=2416182&group_id=976&atid=100976 [2008-12-11 07:18:50] magical...@php.net This bug has been reproduced without PHP by reproducing the same sequence in C. $ svn co http://ookoo.org/svn/snip/curl_bug ... $ cd curl_bug $ make ... $ gdb ./curl_bug ... #0 0x7f81692626c9 in ?? () from /usr/lib/libcurl.so.4 #1 0x7f8169263ec4 in ?? () from /usr/lib/libcurl.so.4 #2 0x7f816926444c in Curl_connect () from /usr/lib/libcurl.so.4 #3 0x7f81692721ba in ?? () from /usr/lib/libcurl.so.4 #4 0x7f8169272a6e in curl_multi_perform () from /usr/lib/libcurl.so.4 #5 0x00400b34 in main (argc=1, argv=0x7fff716a14d8) at test.c:36 I'll build latest curl with debug mode, check if this can be reproduced, and if so, I'll open a but on libcurl providing more debug informations. [2008-12-10 19:32:11] magical...@php.net I checked the origin of the crash, and it seems that libcurl does NOT behave good if you duplicate a handle while it's part of a curl_multi. Calling curl_multi_remove_handle($mh, $conn[$i]); before $conn2[$i] = curl_copy_handle($conn[$i]); fixes the issue. Checking curl's documentation, I found it to be quite picky about processing order. I believe this is either a bug in libcurl, or a "feature". libcurl's manpages are not providing exact informations about calling curl_easy_duphandle() on a curl handle part of a curl_multi. I'm going to investigate this more and either fix this bug (by providing a patch) or mark it as bogus (if this is a curl feature). [2008-12-08 11:33:38] j...@php.net Verified with latest CVS + Curl 7.18.2 [2008-12-07 16:45:51] kyle at ifixit dot com Reproducible using libcurl/7.19.2 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 on kernel 2.6.18-53.1.14.el5. This is not a new bug-- also reproducible with PHP 5.2.6 and an older version of libcurl. 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/46756 -- Edit this bug report at http://bugs.php.net/?id=46756&edit=1
#43225 [NoF->Opn]: fputcsv incorrectly handles cells ending in \ followed by "
ID: 43225
Updated by: magical...@php.net
Reported By: ed at bronto dot com
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Centos
PHP Version: 5.2.4
New Comment:
This bug is the same as bug #38918 and bug #38929.
* fputcsv() does escape values (replacing " with "", for example)
* It seems that fgetcsv() accepts two incompatible unescaping methods
Reproduced:
php > $fp = fopen('php://temp', 'r');
php > fputcsv($fp, array('foo', 'bar\\', 'baz'));
php > rewind($fp);
php > echo fgets($fp);
foo,"bar\",baz
php > rewind($fp);
php > var_dump(fgetcsv($fp));
array(2) {
[0]=>
string(3) "foo"
[1]=>
string(10) "bar\",baz
"
}
php > echo PHP_VERSION;
5.2.6-pl7-gentoo
php >
I believe this problem is due to the fact fgetcsv() accept two escaping
methods. An extra argument to fgetcsv() could (maybe?) fix this (and the
extra argument could be added to fputcsv too)
Previous Comments:
[2008-07-22 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-07-14 21:26:41] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-04-17 01:00:55] dan at expireddomain dot com
Same problem on windows XP PHP version 5.2.5 on cells that contain a \
followed by double quotes (")
[2007-11-09 14:59:11] ed at bronto dot com
Description:
Using fputcsv to output a cell that ends with a \ followed by double
quotes (") causes it to not use any escape sequence. Oddly, fgetscsv is
able to parse it correctly. Unlike fgetscsv, I assume fputcsv follows
RFC 4180 and uses " as the escape character.
Reproduce code:
---
$row = array();
$row[] = 'a\\"';
$row[] = 'bbb';
$fp = fopen('test.csv', 'w+');
fputcsv($fp, $row);
fclose($fp);
Expected result:
expected output: "a\""",bbb
Actual result:
--
actual output: "a\"",bbb
--
Edit this bug report at http://bugs.php.net/?id=43225&edit=1
#29479 [Sus]: changing current process name
ID: 29479
Updated by: magical...@php.net
Reported By: black at scene-si dot org
Status: Suspended
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 6CVS
New Comment:
Just for info since a lot of people seems to be looking for this kind
of solution (I'm one of them), I've hosted the proctitle extension on a
SVN repository, updated and fixed.
Available at:
http://ookoo.org/svn/proctitle/
Please let me know if you want to add things to this extension. I
tested it with PHP 5.2.8 and PHP 5.3.0alpha3, without problems.
Previous Comments:
[2008-06-09 22:52:55] lindsay dot snider at gmail dot com
Here is a shorter version based off of xdecock's code which has been
working well. I see value in having this available when using PHP in
CLI mode.
---
#include
#include
#include
#include
static char *argv0 = NULL;
#define MAX_TITLE_LENGTH128
void setproctitle(char *title)
{
charbuffer[MAX_TITLE_LENGTH];
int tlen = strlen(title);
memset(buffer, 0x20, MAX_TITLE_LENGTH);
buffer[MAX_TITLE_LENGTH-1] = '\0';
if( tlen < (MAX_TITLE_LENGTH-1) )
memcpy(buffer, title, tlen);
if( argv0 )
snprintf(argv0, MAX_TITLE_LENGTH, "%s", buffer);
}
void set_proctitle_init()
{
sapi_module_struct *symbol = NULL;
symbol = (sapi_module_struct *)dlsym(NULL, "sapi_module");
if( symbol )
argv0 = symbol->executable_location;
}
PHP_FUNCTION(setproctitle)
{
char*title;
longtlen;
if(zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s",&title,
&tlen) == FAILURE)
RETURN_FALSE;
setproctitle(title);
}
[2007-06-06 12:54:17] xdecock at gmail dot com
I've tried to make a port of the apache thing used for wikipedia to a
more generic one.
If it can be usefull for anyone (only tested it on cli, as i search the
way of doing this for cli primary)
Not sure how good is this method, at first seen, it works
proctitle.h & config.m4 are almost the same (except for MREQUEST_INIT &
MREQUEST_SHUTDOWN), but it is not usefull for CLI
the url for those files:
http://wikipedia.svn.sourceforge.net/viewvc/wikipedia/trunk/extensions/pecl-proctitle/php_proctitle.h?revision=9174&view=markup
#proctitle.c
/*
+--+
| PHP Version 4
|
+--+
| Copyright (c) 1997-2003 The PHP Group
|
+--+
| This source file is subject to version 2.02 of the PHP license,
|
| that is bundled with this package in the file LICENSE, and is
|
| available at through the world-wide-web at
|
| http://www.php.net/license/2_02.txt.
|
| If you did not receive a copy of the PHP license and are unable to
|
| obtain it through the world-wide-web, please send a note to
|
| lice...@php.net so we can mail you a copy immediately.
|
+--+
| Author:
|
+--+
$Id$
*/
#define MAXTITLE 1024
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include "php.h"
#include "php_ini.h"
#include "SAPI.h"
#include "ext/standard/info.h"
#include "php_proctitle.h"
#include
/* If you declare any globals in php_proctitle.h uncomment this:
ZEND_DECLARE_MODULE_GLOBALS(proctitle)
*/
/* True global resources - no need for thread safety here */
static int le_proctitle;
static char *proctitle_argv=NULL;
static char process_base_name[MAXTITLE+1];
#ifndef HAVE_PROCTITLE
void setproctitle(char *title) {
if (proctitle_argv){
sprintf(proctitle_argv,process_base_name,title);
}
}
#endif
/* {{{ proctitle_functions[]
*
* Every user visible function must have an entry in
proctitle_functions[].
*/
function_entry proctitle_functions[] = {
PHP_FE(setproctitle,NULL) /* For testing, remove later. */
{NULL, NULL, NULL} /* Must be the last line in
proctitle_functions[]
*/
};
/* }}} */
/* {{{ proctitle_module_entry
*/
zend_module_entry proctitle_module_entry = {
#if ZEND_MODULE_API_NO >= 20010901
STANDARD_MODULE_HEADER,
#endif
"proctitle",
proctitle_functions,
PHP_MINIT(proctitle),
PHP_MSHUTDOWN(proctitle),
NULL, /* Replac
#29479 [Sus->Csd]: changing current process name
ID: 29479
Updated by: magical...@php.net
Reported By: black at scene-si dot org
-Status: Suspended
+Status: Closed
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 6CVS
New Comment:
This feature is now covered by the proctitle pecl extension, which is
based on code written by the different
http://pecl.php.net/proctitle
I believe this bug can now be closed.
Previous Comments:
[2009-01-21 22:35:47] paj...@php.net
hi!
I would suggest to simply propose it to pecl-dev. That's the place to
discussion proposals for PECL.
cheers,
[2009-01-21 20:56:48] magical...@php.net
Just for info since a lot of people seems to be looking for this kind
of solution (I'm one of them), I've hosted the proctitle extension on a
SVN repository, updated and fixed.
Available at:
http://ookoo.org/svn/proctitle/
Please let me know if you want to add things to this extension. I
tested it with PHP 5.2.8 and PHP 5.3.0alpha3, without problems.
[2008-06-09 22:52:55] lindsay dot snider at gmail dot com
Here is a shorter version based off of xdecock's code which has been
working well. I see value in having this available when using PHP in
CLI mode.
---
#include
#include
#include
#include
static char *argv0 = NULL;
#define MAX_TITLE_LENGTH128
void setproctitle(char *title)
{
charbuffer[MAX_TITLE_LENGTH];
int tlen = strlen(title);
memset(buffer, 0x20, MAX_TITLE_LENGTH);
buffer[MAX_TITLE_LENGTH-1] = '\0';
if( tlen < (MAX_TITLE_LENGTH-1) )
memcpy(buffer, title, tlen);
if( argv0 )
snprintf(argv0, MAX_TITLE_LENGTH, "%s", buffer);
}
void set_proctitle_init()
{
sapi_module_struct *symbol = NULL;
symbol = (sapi_module_struct *)dlsym(NULL, "sapi_module");
if( symbol )
argv0 = symbol->executable_location;
}
PHP_FUNCTION(setproctitle)
{
char*title;
longtlen;
if(zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s",&title,
&tlen) == FAILURE)
RETURN_FALSE;
setproctitle(title);
}
[2007-06-06 12:54:17] xdecock at gmail dot com
I've tried to make a port of the apache thing used for wikipedia to a
more generic one.
If it can be usefull for anyone (only tested it on cli, as i search the
way of doing this for cli primary)
Not sure how good is this method, at first seen, it works
proctitle.h & config.m4 are almost the same (except for MREQUEST_INIT &
MREQUEST_SHUTDOWN), but it is not usefull for CLI
the url for those files:
http://wikipedia.svn.sourceforge.net/viewvc/wikipedia/trunk/extensions/pecl-proctitle/php_proctitle.h?revision=9174&view=markup
#proctitle.c
/*
+--+
| PHP Version 4
|
+--+
| Copyright (c) 1997-2003 The PHP Group
|
+--+
| This source file is subject to version 2.02 of the PHP license,
|
| that is bundled with this package in the file LICENSE, and is
|
| available at through the world-wide-web at
|
| http://www.php.net/license/2_02.txt.
|
| If you did not receive a copy of the PHP license and are unable to
|
| obtain it through the world-wide-web, please send a note to
|
| lice...@php.net so we can mail you a copy immediately.
|
+--+
| Author:
|
+--+
$Id$
*/
#define MAXTITLE 1024
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include "php.h"
#include "php_ini.h"
#include "SAPI.h"
#include "ext/standard/info.h"
#include "php_proctitle.h"
#include
/* If you declare any globals in php_proctitle.h uncomment this:
ZEND_DECLARE_MODULE_GLOBALS(proctitle)
*/
/* True global resources - no need for thread safety here */
static int le_proctitle;
static char *proctitle_argv=NULL;
static char process_base_name[MAXTITLE+1];
#ifndef HAVE_PROCTITLE
void setproctitle(char *title) {
if (proctitle_argv){
sprintf(proctitle_argv,process_base_name,title);
}
}
#endif
/* {{{ proctitle_functions[]
*
* Every user visible function must have an entry in
proctitle_funct
#47396 [Opn]: resource ids get re-used when opening enough files
ID: 47396
Updated by: magical...@php.net
Reported By: cwei...@php.net
Status: Open
Bug Type:Reproducible crash
PHP Version: 5.2.9RC2
New Comment:
I had a look at the problem inside zend, and found the problem most
likely coming from zend_hash.c
if ((long)h >= (long)ht->nNextFreeElement) {
ht->nNextFreeElement = h + 1;
}
If h (the element being inserted) is higher or equal than the current
"nNextFreeElement", we set this to h+1.
This does not handles:
- The fact that we might get back to 0
- The fact that once we get back to 0, the "next free element" might be
non free (and will most likely be for #1 and #2).
Previous Comments:
[2009-02-15 16:02:53] cwei...@php.net
Description:
Using php for long running daemons and opening files in there can lead
to crashes, when resource ids wrap around the integer/long size and come
to 0 at last.
There is no sanity check if a resource is already in use when assigning
it.
This problem is more likely to appear on 32bit systems than on 64,
since it takes ages to overflow that number with 64bit. Still, it is a
problem.
Example:
- Open a file -> resource id is now +1
- Open many files. Eventually, it will reach MAX_INT or whatever number
that is and wrap around to "-" that number, increasing from now on.
- Double the time, and the script reaches an resource id of 0
- Now chances are very high that the an existing resource is at the
same id
- PHP crashes
The problem has been - wrongly - described here:
http://gnuvince.wordpress.com/2008/10/28/php-wrong-for-long-running-processes-wrong-for-america/
The issue is the one I described here
--
Edit this bug report at http://bugs.php.net/?id=47396&edit=1
Bug #51624 [Fbk]: Gallery2 causing segfault when trying to update.
Edit report at http://bugs.php.net/bug.php?id=51624&edit=1
ID: 51624
Updated by: magical...@php.net
Reported by: zulcss at ubuntu dot com
Summary: Gallery2 causing segfault when trying to update.
Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Ubuntu/Linux
PHP Version: 5.3.2
New Comment:
A wild guess based on the comment date: SVN revision 298253
The patch:
http://ookoo.org/svn/snip/php-5.3.2-mysql-badmem-fix.patch
I have applied the patch on my install and asked customers experiencing
problems
to try again. They report that the problem is fixed. I guess this bug
report can
now be closed.
Previous Comments:
[2010-04-22 21:08:57] Fedora at famillecollet dot com
I just try gallery2 with 201004221630 snapshot (5.3.3-dev).
No crash encountered.
Just need to found the fix in subversion.
[2010-04-21 16:52:58] 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-04-21 14:10:18] zulcss at ubuntu dot com
Description:
Hi,
This bug was recently reported on launchpad at
http://bugs.launchpad.net/bugs/567043. I have included the gdb backtrace
with this bug report.
Regards
chuck
Expected result:
Not to crash.
Actual result:
--
#0 0x7fe478493d02 in memcpy () from /lib/libc.so.6
No symbol table info available.
#1 0x00677ff8 in _estrndup (s=0x4d0050 , length=90) at
/usr/include/bits/string3.h:52
No locals.
#2 0x0069459b in _zval_copy_ctor_func (zvalue=0x1f84ca8) at
/build/buildd/php5-5.3.2/Zend/zend_variables.c:126
tmp = 0x1ecb470
original_ht = 0x1ecb470
#3 0x7fe4752b0f68 in zif_mysqli_options (ht=33049848,
return_value=0x1f84c58, return_value_ptr=0x5a, this_ptr=0x4d0050,
return_value_used=17) at
/build/buildd/php5-5.3.2/Zend/zend_variables.h:45
mysql_link = 0x1f84ca8
mysql_value = 0x5
mysql_option = 33049648
l_value = 0
expected_type = 33049848
#4 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x142a390) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x15c7698
should_change_scope = 0 '\000'
#5 0x006bcc70 in execute (op_array=0x11d7080) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x142a390
nested = 0 '\000'
original_in_execution = 1 '\001'
#6 0x0068ab94 in zend_call_function (fci=0x7fff6ab02fd0,
fci_cache=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_execute_API.c:947
i = 17
original_return_value = 0x141f6f0
calling_symbol_table = 0x1938398
original_op_array = 0x19cf630
original_opline_ptr =
current_scope = 0x1db96c0
current_called_scope = 0x1938398
calling_scope = 0x0
called_scope = 0x141f6f0
current_this = 0x0
execute_data = {opline = 0x0, function_state = {function = 0x0,
arguments = 0x1949408}, fbc = 0x141fe68, called_scope = 0x0, op_array =
0x0, object = 0x0, Ts = 0x1956490, CVs = 0x141f938, symbol_table =
0x141f8d8,
prev_execute_data = 0x0, old_error_reporting = 0x141f840,
nested = 0 '\000', original_return_value = 0x1, current_scope =
0x141e228, current_called_scope = 0x1938398, current_this = 0x1938398,
current_object = 0x1db92d0,
call_opline = 0x0}
#7 0x005cd107 in zif_call_user_func_array (ht=33049848,
return_value=0x1db8eb8, return_value_ptr=0x5a, this_ptr=0x1,
return_value_used=17) at
/build/buildd/php5-5.3.2/ext/standard/basic_functions.c:4782
params = 0x0
retval_ptr = 0x141f840
fci = {size = 6082823, function_table = 0x48, function_name =
0x1927c28, symbol_table = 0x1a58120, retval_ptr_ptr = 0x0, param_count =
1789931600, params = 0x3, object_ptr = 0x1da2868, no_separation = 144
'\220'}
fci_cache = {initialized = 176 '\260', function_handler = 0x1,
calling_scope = 0x1949408, called_scope = 0x1927bf8, object_ptr =
0x1927bf8}
#8 0x006e598a in zend_do_fcall_common_helper_SPEC
(execute_data=0x141f840) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x19d4418
should_change_scope = 0 '\000'
#9 0x006bcc70 in execute (op_array=0x19cf630) at
/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
ret = 33049848
execute_data = 0x141f840
nested = 0 '\000'
original_in_execution = 0 '\000'
#10 0x0069499d in zend_execute_scripts (type=0,
retval=0x7fff6ab03210, file_count=3) at
/build/buildd/php5-5.3.2/Zend/zend.c:
Req #51295 [Asn]: SQLite3::busyTimeout not existing
Edit report at http://bugs.php.net/bug.php?id=51295&edit=1 ID: 51295 Updated by: magical...@php.net Reported by: magical...@php.net Summary: SQLite3::busyTimeout not existing Status: Assigned Type: Feature/Change Request Package: SQLite related Operating System: Linux Gentoo 2.6.33 PHP Version: 5.3SVN-2010-03-14 (SVN) Assigned To: scottmac New Comment: Ok, I had some troubles to make a meaningful test for this bug (the php function is just calling the equivalent sqlite function), but in the end I got this. http://ookoo.org/svn/snip/20100607_php_test_bug51295.php (didn't manage to attache this to this bug report, even renamed as .txt) Anyway here it is. It forks, open a sqlite file and locks it, then the other process will try to access it with a 1 second busyTimeout then dumps the waited time and the result (should have failed with a 1 second delay with +/- 10ms) Remaining steps includes converting this test to phpt and run it once to get the "right" output (I'll need to check doc to find the right format for phpt since it's been a while). Previous Comments: [2010-03-14 08:29:39] magical...@php.net Description: In SQLite3, method busyTimeout() is missing, and by default there is no busy handler. In old SQLite extension, a default timeout of 60 seconds was set, and a busyTimeout() method was available to define the timeout. I recently started with SQLite3 to have this kind of errors as load was growing on SELECT statement: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked Some internet research showed that this could be fixed by setting a different busy timeout, and I noticed PHP wasn't setting any on SQLite3. While I'm unsure about setting a default busyTimeout on SQLite3 (it currently have none, but PHP_5_3 is still young enough to change this kind of behaviour) it should be at least possible to set one. Patch to add a SQLite3::busyTimeout() method (same behaviour as old SQLite::busyTimeout() method, with the exception this one has a true/false return value, while sqlite3_busy_timeout will always return SQLITE_OK, it may change in the future). The patch: https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch -- Edit this bug report at http://bugs.php.net/bug.php?id=51295&edit=1
Bug #51680 [Asn->Dup]: Sqlite returns without waiting for timeout
Edit report at http://bugs.php.net/bug.php?id=51680&edit=1 ID: 51680 Updated by: magical...@php.net Reported by: ncoesel at dealogic dot nl Summary: Sqlite returns without waiting for timeout -Status: Assigned +Status: Duplicate Type: Bug Package: SQLite related Operating System: Linux PHP Version: Irrelevant Assigned To: scottmac New Comment: This bug is a duplicate of http://bugs.php.net/51295 (which includes a slightly better way of fixing this). Previous Comments: [2010-04-28 10:49:22] ncoesel at dealogic dot nl Description: Sqlite has a protection mechanism that prevents firing two (or) more queries from the same process and wait for the database to become available. The typical behaviour is that every now and then (depending on the database load) a query exits immediately with "SQLSTATE[HY000]: General error: 5 database is locked". Setting other busy timeout values doesn't help. I've attached a patch that solves the problem unless the database is locked for a very long time (as usual some error . The patch is created for an older version of PHP. I've checked the latest CVS version and I'm quite sure the patch will still apply. -- Edit this bug report at http://bugs.php.net/bug.php?id=51680&edit=1
Bug #51680 [Dup->Opn]: Sqlite returns without waiting for timeout
Edit report at http://bugs.php.net/bug.php?id=51680&edit=1 ID: 51680 Updated by: magical...@php.net Reported by: ncoesel at dealogic dot nl Summary: Sqlite returns without waiting for timeout -Status: Duplicate +Status: Open Type: Bug Package: SQLite related Operating System: Linux PHP Version: Irrelevant Assigned To: scottmac New Comment: Indeed not a duplicate of 51295, went a bit too fast. Sorry. By the way SQLite has its own view on threads: http://www.sqlite.org/faq.html#q6 Especially I do not like the idea of looping until the query suceeds, especially since it may end sleeping quite a long time. My guess is it would be up to the php part to check for BUSY status and do something else (stream_select?) before retrying (or maybe add an option retry_count to query()/exec() with default=0) Anyway that's just my point of view, I'm reopening this bug and letting scottmac do what he deems appropriate. Previous Comments: [2010-06-07 09:13:03] ncoesel at dealogic dot nl I'm sorry but you are mistaken. Sqlite_busytimeout may be ignored by Sqlite when two threads of the same process execute a query. This is documented behaviour of Sqlite. See http://www.sqlite.org/c3ref/busy_handler.html in the 4th paragraph. "The presence of a busy handler does not guarantee that it will be invoked when there is lock contention. If SQLite determines that invoking the busy handler could result in a deadlock, it will go ahead and return SQLITE_BUSY or SQLITE_IOERR_BLOCKED instead of invoking the busy handler." I did very thourough research on this and my patch is a way to solve it altough there is always a chance the database may be locked for too long. If that is a problem one might have exceeded Sqlite's capabilities :-) [2010-06-07 07:10:06] magical...@php.net This bug is a duplicate of http://bugs.php.net/51295 (which includes a slightly better way of fixing this). [2010-04-28 10:49:22] ncoesel at dealogic dot nl Description: Sqlite has a protection mechanism that prevents firing two (or) more queries from the same process and wait for the database to become available. The typical behaviour is that every now and then (depending on the database load) a query exits immediately with "SQLSTATE[HY000]: General error: 5 database is locked". Setting other busy timeout values doesn't help. I've attached a patch that solves the problem unless the database is locked for a very long time (as usual some error . The patch is created for an older version of PHP. I've checked the latest CVS version and I'm quite sure the patch will still apply. -- Edit this bug report at http://bugs.php.net/bug.php?id=51680&edit=1
#51056 [Fbk]: fread() on blocking stream will block even if data is available
ID: 51056
Updated by: magical...@php.net
Reported By: magical...@php.net
Status: Feedback
Bug Type: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
This report looks a bit like bug #50856 (about non-blocking mode), but
it seems to be related to a different part of the streams api (non
blocking mode, fopen wrapper for http, while I'm testing on sockets in
blocking mode).
I'm about to test with vanilla PHP_5_2 and PHP_5_3 from svn (once
compilation completes). In the meantime I could reproduce the problem
on PHP 5.2.12 (gentoo patched version).
Previous Comments:
[2010-02-16 10:56:46] j...@php.net
Isn't this same (or related) as bug #50856 is? Does it happen with
PHP_5_2 ? And I'd guess you have tested latest PHP_5_3 as well?
[2010-02-16 10:34:48] magical...@php.net
Description:
On a blocking stream, a call to fread() will return even if the passed
buffer size has not been reached.
A call to fread() should return immediatly if there is data pending to
be read (buffered by php). Instead of that, php will call poll() on
the stream to wait for more data to arrive, then will return the
previously read data and the new data.
Suggestion: if fread() is called on a blocking stream that already
contains data, PHP should call poll() with a 0 timeout, read any newly
available data and return immediatly.
If no data is currently in PHP's internal buffer, current behaviour
can be kept.
(it is also possible to skip completly the poll() part and directly
return any pending data without checking if the real stream has
anything, but I believe that it might not be as logical, a call to
fread() should read)
Reproduce code:
---
0) {
// parent
fclose($pair[0]);
while(!feof($pair[1])) {
$start = microtime(true);
$data = fread($pair[1], 256);
printf("fread took %01.2fms to read %d bytes\n",
(microtime(true)-$start)*1000, strlen($data));
}
exit;
}
// child
fclose($pair[1]);
while(!feof($pair[0])) {
fwrite($pair[0], "Hello 1\n"); // 8 bytes
usleep(5000);
fwrite($pair[0], str_repeat('a', 300)."\n"); // 301 bytes
sleep(1);
}
Expected result:
Testing PHP version: 5.3.1
fread took 0.09ms to read 8 bytes
fread took 5.08ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.10ms to read 8 bytes
fread took 5.04ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.10ms to read 8 bytes
fread took 5.04ms to read 256 bytes
(etc)
Actual result:
--
Testing PHP version: 5.3.1
fread took 0.09ms to read 8 bytes
fread took 5.08ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.04ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.04ms to read 256 bytes
(etc)
--
Edit this bug report at http://bugs.php.net/?id=51056&edit=1
#51056 [Fbk]: fread() on blocking stream will block even if data is available
ID: 51056
Updated by: magical...@php.net
Reported By: magical...@php.net
Status: Feedback
Bug Type: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
Confirmed with PHP_5_3
Testing PHP version: 5.3.3-dev
fread took 0.07ms to read 8 bytes
fread took 5.06ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.03ms to read 256 bytes
fread took 1000.11ms to read 53 bytes
fread took 5.04ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
I'll need a bit more time for PHP_5_2 as flex-2.5.4 is becoming more
difficult to find.
Previous Comments:
[2010-02-16 11:11:54] magical...@php.net
This report looks a bit like bug #50856 (about non-blocking mode), but
it seems to be related to a different part of the streams api (non
blocking mode, fopen wrapper for http, while I'm testing on sockets in
blocking mode).
I'm about to test with vanilla PHP_5_2 and PHP_5_3 from svn (once
compilation completes). In the meantime I could reproduce the problem
on PHP 5.2.12 (gentoo patched version).
[2010-02-16 10:56:46] j...@php.net
Isn't this same (or related) as bug #50856 is? Does it happen with
PHP_5_2 ? And I'd guess you have tested latest PHP_5_3 as well?
[2010-02-16 10:34:48] magical...@php.net
Description:
On a blocking stream, a call to fread() will return even if the passed
buffer size has not been reached.
A call to fread() should return immediatly if there is data pending to
be read (buffered by php). Instead of that, php will call poll() on
the stream to wait for more data to arrive, then will return the
previously read data and the new data.
Suggestion: if fread() is called on a blocking stream that already
contains data, PHP should call poll() with a 0 timeout, read any newly
available data and return immediatly.
If no data is currently in PHP's internal buffer, current behaviour
can be kept.
(it is also possible to skip completly the poll() part and directly
return any pending data without checking if the real stream has
anything, but I believe that it might not be as logical, a call to
fread() should read)
Reproduce code:
---
0) {
// parent
fclose($pair[0]);
while(!feof($pair[1])) {
$start = microtime(true);
$data = fread($pair[1], 256);
printf("fread took %01.2fms to read %d bytes\n",
(microtime(true)-$start)*1000, strlen($data));
}
exit;
}
// child
fclose($pair[1]);
while(!feof($pair[0])) {
fwrite($pair[0], "Hello 1\n"); // 8 bytes
usleep(5000);
fwrite($pair[0], str_repeat('a', 300)."\n"); // 301 bytes
sleep(1);
}
Expected result:
Testing PHP version: 5.3.1
fread took 0.09ms to read 8 bytes
fread took 5.08ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.10ms to read 8 bytes
fread took 5.04ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.10ms to read 8 bytes
fread took 5.04ms to read 256 bytes
(etc)
Actual result:
--
Testing PHP version: 5.3.1
fread took 0.09ms to read 8 bytes
fread took 5.08ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.04ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.04ms to read 256 bytes
(etc)
--
Edit this bug report at http://bugs.php.net/?id=51056&edit=1
#51056 [Fbk]: fread() on blocking stream will block even if data is available
ID: 51056
Updated by: magical...@php.net
Reported By: magical...@php.net
Status: Feedback
Bug Type: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
I tried to switch to non-blocking mode. This solves this issue with
most sockets, except for SSL sockets when transmitting a lot of data.
This bug is blocking in my case (socket communication transmitting a
lot of data).
Previous Comments:
[2010-02-16 12:19:38] fel...@php.net
Testing PHP version: 5.2.13RC3-dev
fread took 0.04ms to read 8 bytes
fread took 4.88ms to read 256 bytes
fread took 1000.04ms to read 53 bytes
fread took 4.96ms to read 256 bytes
fread took 1000.06ms to read 53 bytes
fread took 4.97ms to read 256 bytes
fread took 1000.06ms to read 53 bytes
(etc)
[2010-02-16 12:00:52] magical...@php.net
Confirmed with PHP_5_3
Testing PHP version: 5.3.3-dev
fread took 0.07ms to read 8 bytes
fread took 5.06ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.03ms to read 256 bytes
fread took 1000.11ms to read 53 bytes
fread took 5.04ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
I'll need a bit more time for PHP_5_2 as flex-2.5.4 is becoming more
difficult to find.
[2010-02-16 11:11:54] magical...@php.net
This report looks a bit like bug #50856 (about non-blocking mode), but
it seems to be related to a different part of the streams api (non
blocking mode, fopen wrapper for http, while I'm testing on sockets in
blocking mode).
I'm about to test with vanilla PHP_5_2 and PHP_5_3 from svn (once
compilation completes). In the meantime I could reproduce the problem
on PHP 5.2.12 (gentoo patched version).
[2010-02-16 10:56:46] j...@php.net
Isn't this same (or related) as bug #50856 is? Does it happen with
PHP_5_2 ? And I'd guess you have tested latest PHP_5_3 as well?
[2010-02-16 10:34:48] magical...@php.net
Description:
On a blocking stream, a call to fread() will return even if the passed
buffer size has not been reached.
A call to fread() should return immediatly if there is data pending to
be read (buffered by php). Instead of that, php will call poll() on
the stream to wait for more data to arrive, then will return the
previously read data and the new data.
Suggestion: if fread() is called on a blocking stream that already
contains data, PHP should call poll() with a 0 timeout, read any newly
available data and return immediatly.
If no data is currently in PHP's internal buffer, current behaviour
can be kept.
(it is also possible to skip completly the poll() part and directly
return any pending data without checking if the real stream has
anything, but I believe that it might not be as logical, a call to
fread() should read)
Reproduce code:
---
0) {
// parent
fclose($pair[0]);
while(!feof($pair[1])) {
$start = microtime(true);
$data = fread($pair[1], 256);
printf("fread took %01.2fms to read %d bytes\n",
(microtime(true)-$start)*1000, strlen($data));
}
exit;
}
// child
fclose($pair[1]);
while(!feof($pair[0])) {
fwrite($pair[0], "Hello 1\n"); // 8 bytes
usleep(5000);
fwrite($pair[0], str_repeat('a', 300)."\n"); // 301 bytes
sleep(1);
}
Expected result:
Testing PHP version: 5.3.1
fread took 0.09ms to read 8 bytes
fread took 5.08ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.10ms to read 8 bytes
fread took 5.04ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.10ms to read 8 bytes
fread took 5.04ms to read 256 bytes
(etc)
Actual result:
--
Testing PHP version: 5.3.1
fread took 0.09ms to read 8 bytes
fread took 5.08ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.04ms to read 256 bytes
fread took 1000.10ms to read 53 bytes
fread took 5.04ms to read 256 bytes
(etc)
--
Edit this bug report at http://bugs.php.net/?id=51056&edit=1
#51056 [Fbk]: fread() on blocking stream will block even if data is available
ID: 51056 Updated by: magical...@php.net Reported By: magical...@php.net Status: Feedback Bug Type: Streams related Operating System: Linux Gentoo 2.6.32 PHP Version: 5.3.1 New Comment: While for file sockets it makes sense when reading data to make sure a buffer gets completly filled until EOF is reached, this is not true for sockets. There is already a condition for "greedy read", but it does not apply when we first restore data from the read buffer. Here is a diff (PHP_5_3) that solves the issue: Index: main/streams/streams.c === --- main/streams/streams.c (révision 295152) +++ main/streams/streams.c (copie de travail) @@ -592,6 +592,10 @@ size -= toread; buf += toread; didread += toread; + + /* avoid trying to read if we already have data to pass */ + if (stream->wrapper != &php_plain_files_wrapper) + break; } /* ignore eof here; the underlying state might have changed */ Test script output: Testing PHP version: 5.3.3-dev fread took 0.07ms to read 8 bytes fread took 5.07ms to read 256 bytes fread took 0.00ms to read 45 bytes fread took 1000.11ms to read 8 bytes fread took 5.02ms to read 256 bytes fread took 0.00ms to read 45 bytes fread took 1000.13ms to read 8 bytes fread took 5.04ms to read 256 bytes Previous Comments: [2010-02-16 13:06:45] magical...@php.net I tried to switch to non-blocking mode. This solves this issue with most sockets, except for SSL sockets when transmitting a lot of data. This bug is blocking in my case (socket communication transmitting a lot of data). [2010-02-16 12:19:38] fel...@php.net Testing PHP version: 5.2.13RC3-dev fread took 0.04ms to read 8 bytes fread took 4.88ms to read 256 bytes fread took 1000.04ms to read 53 bytes fread took 4.96ms to read 256 bytes fread took 1000.06ms to read 53 bytes fread took 4.97ms to read 256 bytes fread took 1000.06ms to read 53 bytes (etc) [2010-02-16 12:00:52] magical...@php.net Confirmed with PHP_5_3 Testing PHP version: 5.3.3-dev fread took 0.07ms to read 8 bytes fread took 5.06ms to read 256 bytes fread took 1000.10ms to read 53 bytes fread took 5.03ms to read 256 bytes fread took 1000.11ms to read 53 bytes fread took 5.04ms to read 256 bytes fread took 1000.10ms to read 53 bytes I'll need a bit more time for PHP_5_2 as flex-2.5.4 is becoming more difficult to find. [2010-02-16 11:11:54] magical...@php.net This report looks a bit like bug #50856 (about non-blocking mode), but it seems to be related to a different part of the streams api (non blocking mode, fopen wrapper for http, while I'm testing on sockets in blocking mode). I'm about to test with vanilla PHP_5_2 and PHP_5_3 from svn (once compilation completes). In the meantime I could reproduce the problem on PHP 5.2.12 (gentoo patched version). [2010-02-16 10:56:46] j...@php.net Isn't this same (or related) as bug #50856 is? Does it happen with PHP_5_2 ? And I'd guess you have tested latest PHP_5_3 as well? 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/51056 -- Edit this bug report at http://bugs.php.net/?id=51056&edit=1
Bug #51056 [Opn]: fread() on blocking stream will block even if data is available
Edit report at http://bugs.php.net/bug.php?id=51056&edit=1
ID: 51056
Updated by: magical...@php.net
Reported by: magical...@php.net
Summary: fread() on blocking stream will block even if data is
available
Status: Open
Type: Bug
Package: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
Hi,
I know about fread() returning less data than asked for, however I could
not
modify this behaviour without passing some kind of value to lower-level
read
operation, which will call poll() if socket is blocking.
When data is already available in buffer, an information should be
passed to the
lower-level read() to let it know it should not block.
The only non-intrusive solution to fix this would be to temporarly pass
socket
in non-blocking mode if data was found in PHP buffer.
Considering any application handling data from network should handle
cases when
received data is not complete, I believe it was best to return
immediatly if
data is found and let the application call fread() again rather than
trying to
workaround this problem with a dirty solution like passing temporarly in
non-
blocking mode.
Another solution would be to add an argument to the internal read call
("do not
block") however it would change the API for the internal stream api, and
would
require the argument to be handled into each stream wrapper.
Previous Comments:
[2010-03-11 02:05:59] lbarn...@php.net
Hi,
I made a test case for this ( 51056.phpt.txt )
fread() in C has exactly the same behavior, it will block if you try to
read more bytes than available.
Your patch correctly avoids this, however it introduces an other issue:
fread() will return less data than asked for, even if enough data is
available ( 51056-2.phpt.txt ).
[2010-02-17 16:00:07] j...@php.net
btw. If you really want someone to do something about this, post the
patch to intern...@lists.php.net as well. :)
[2010-02-17 05:39:56] magical...@php.net
While for file sockets it makes sense when reading data to make sure a
buffer gets completly filled until EOF is reached, this is not true
for sockets.
There is already a condition for "greedy read", but it does not apply
when we first restore data from the read buffer.
Here is a diff (PHP_5_3) that solves the issue:
Index: main/streams/streams.c
===
--- main/streams/streams.c (révision 295152)
+++ main/streams/streams.c (copie de travail)
@@ -592,6 +592,10 @@
size -= toread;
buf += toread;
didread += toread;
+
+ /* avoid trying to read if we already have
data to pass */
+ if (stream->wrapper !=
&php_plain_files_wrapper)
+ break;
}
/* ignore eof here; the underlying state might have
changed */
Test script output:
Testing PHP version: 5.3.3-dev
fread took 0.07ms to read 8 bytes
fread took 5.07ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.11ms to read 8 bytes
fread took 5.02ms to read 256 bytes
fread took 0.00ms to read 45 bytes
fread took 1000.13ms to read 8 bytes
fread took 5.04ms to read 256 bytes
[2010-02-16 13:06:45] magical...@php.net
I tried to switch to non-blocking mode. This solves this issue with
most sockets, except for SSL sockets when transmitting a lot of data.
This bug is blocking in my case (socket communication transmitting a
lot of data).
[2010-02-16 12:19:38] fel...@php.net
Testing PHP version: 5.2.13RC3-dev
fread took 0.04ms to read 8 bytes
fread took 4.88ms to read 256 bytes
fread took 1000.04ms to read 53 bytes
fread took 4.96ms to read 256 bytes
fread took 1000.06ms to read 53 bytes
fread took 4.97ms to read 256 bytes
fread took 1000.06ms to read 53 bytes
(etc)
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=51056
--
Edit this bug report at http://bugs.php.net/bug.php?id=51056&edit=1
Bug #51056 [Fbk]: fread() on blocking stream will block even if data is available
Edit report at http://bugs.php.net/bug.php?id=51056&edit=1
ID: 51056
Updated by: magical...@php.net
Reported by: magical...@php.net
Summary: fread() on blocking stream will block even if data is
available
Status: Feedback
Type: Bug
Package: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
> This will block anyway when the buffer is empty and you won't be able
to known
when it is empty, so you can't rely on this (sometimes it will block,
sometimes
not).
PHP always calls poll() before read, so it knows if there is nothing to
read.
stream_select() will return the socket as "ready" if there is data
pending in
php buffer (even if there's no data on the socket), just so we can read
it.
> Also, some applications may rely on the blocking and will break if it
is
changed. This behavior exists since at least PHP 5.1.
fread() manual explicitly warns about this:
When reading from anything that is not a regular local file, such as
streams
returned when reading remote files or from popen() and fsockopen(),
reading will
stop after a packet is available. This means that you should collect the
data
together in chunks as shown in the examples below.
On the contrary, using blocking streams together with stream_select()
may lead
to async program blocking because stream_select() saw there was pending
data,
but a new packet will not arrive anytime soon.
> As this is not the normal case I would suggest to introduce some
timeout
handling (this is what applications like e.g. Apache does, I guess), or
fixing
what prevents you from using non blocking i/o with SSL streams instead.
It is the normal case to receive less than expected data as documented
on the
php manual.
Apache (or any correctly coded networking app) does not uses timeouts
(except to
detect dead clients), instead it uses read() which is reliable (ie. not
hang
when there is data that can be returned).
By the way I have looked at what causes the problem I have with SSL
streams, and
it could be worked around by switching the streamd between blocking mode
and
non-blocking mode depending on the situation, however I would prefer to
avoid
that (and it doesn't change the fact that fread() does not comply with
what is
expected from it, both from read() syscall behaviour and php's manual)
Previous Comments:
[2010-03-11 16:51:20] lbarn...@php.net
> When data is already available in buffer, an information should be
passed to the lower-level read() to let it know it should not block.
This will block anyway when the buffer is empty and you won't be able to
known when it is empty, so you can't rely on this (sometimes it will
block, sometimes not).
Also, some applications may rely on the blocking and will break if it is
changed. This behavior exists since at least PHP 5.1.
> Considering any application handling data from network should handle
cases when received data is not complete
As this is not the normal case I would suggest to introduce some timeout
handling (this is what applications like e.g. Apache does, I guess), or
fixing what prevents you from using non blocking i/o with SSL streams
instead.
[2010-03-11 02:21:59] magical...@php.net
Hi,
I know about fread() returning less data than asked for, however I could
not
modify this behaviour without passing some kind of value to lower-level
read
operation, which will call poll() if socket is blocking.
When data is already available in buffer, an information should be
passed to the
lower-level read() to let it know it should not block.
The only non-intrusive solution to fix this would be to temporarly pass
socket
in non-blocking mode if data was found in PHP buffer.
Considering any application handling data from network should handle
cases when
received data is not complete, I believe it was best to return
immediatly if
data is found and let the application call fread() again rather than
trying to
workaround this problem with a dirty solution like passing temporarly in
non-
blocking mode.
Another solution would be to add an argument to the internal read call
("do not
block") however it would change the API for the internal stream api, and
would
require the argument to be handled into each stream wrapper.
[2010-03-11 02:05:59] lbarn...@php.net
Hi,
I made a test case for this ( 51056.phpt.txt )
fread() in C has exactly the same behavior, it will block if you try to
read more bytes than available.
Your patch correctly avoids this, however it introduces an other issue:
fread() will return less data than asked for, even if enough data is
available ( 51056-2.phpt.txt ).
Bug #51056 [Fbk]: fread() on blocking stream will block even if data is available
Edit report at http://bugs.php.net/bug.php?id=51056&edit=1
ID: 51056
Updated by: magical...@php.net
Reported by: magical...@php.net
Summary: fread() on blocking stream will block even if data is
available
Status: Feedback
Type: Bug
Package: Streams related
Operating System: Linux Gentoo 2.6.32
PHP Version: 5.3.1
New Comment:
I still believe fread() should not hang when it has data it can return.
The C
counterpart doesn't, and the manual says it doesn't.
Regarding test 51056-2.phpt.txt the manual explicitly says that this
*can
happen* on anything else than files (read warning in example #3 on
http://php.net/fread )
While I understand your concern for people who might be relying on
current bogus
behaviour I find this very unlikely considering network streams are
subject to
lags and different kinds of behaviour due to the large amount of tcp
implementations on internet.
In the worst case, the manual explicitly warns against relying on
fread()
returning as many bytes as requested, and says buffering must be used.
Previous Comments:
[2010-03-11 21:23:43] lbarn...@php.net
> Apache [...] uses timeouts [...] to detect dead clients
This is what I was meaning :) (and I though you was meaning this too :
"application handling data from network should handle cases when
received data is not complete")
Dead clients, or situations like this are not the "normal case", and
sometimes this can be handled with timeouts.
If you are in situations where this is the normal case, one solution is
to use non blocking streams.
The following code does exactly what you are asking for (if there is
something to read, return it; else, block) :
stream_set_blocking(..., 0);
while (stream_select(...)) {
$data = fread(...);
}
If it does not works with SSL streams, then SSL stuff should be fixed
instead.
[2010-03-11 20:26:59] magical...@php.net
> This will block anyway when the buffer is empty and you won't be able
to known
when it is empty, so you can't rely on this (sometimes it will block,
sometimes
not).
PHP always calls poll() before read, so it knows if there is nothing to
read.
stream_select() will return the socket as "ready" if there is data
pending in
php buffer (even if there's no data on the socket), just so we can read
it.
> Also, some applications may rely on the blocking and will break if it
is
changed. This behavior exists since at least PHP 5.1.
fread() manual explicitly warns about this:
When reading from anything that is not a regular local file, such as
streams
returned when reading remote files or from popen() and fsockopen(),
reading will
stop after a packet is available. This means that you should collect the
data
together in chunks as shown in the examples below.
On the contrary, using blocking streams together with stream_select()
may lead
to async program blocking because stream_select() saw there was pending
data,
but a new packet will not arrive anytime soon.
> As this is not the normal case I would suggest to introduce some
timeout
handling (this is what applications like e.g. Apache does, I guess), or
fixing
what prevents you from using non blocking i/o with SSL streams instead.
It is the normal case to receive less than expected data as documented
on the
php manual.
Apache (or any correctly coded networking app) does not uses timeouts
(except to
detect dead clients), instead it uses read() which is reliable (ie. not
hang
when there is data that can be returned).
By the way I have looked at what causes the problem I have with SSL
streams, and
it could be worked around by switching the streamd between blocking mode
and
non-blocking mode depending on the situation, however I would prefer to
avoid
that (and it doesn't change the fact that fread() does not comply with
what is
expected from it, both from read() syscall behaviour and php's manual)
[2010-03-11 16:51:20] lbarn...@php.net
> When data is already available in buffer, an information should be
passed to the lower-level read() to let it know it should not block.
This will block anyway when the buffer is empty and you won't be able to
known when it is empty, so you can't rely on this (sometimes it will
block, sometimes not).
Also, some applications may rely on the blocking and will break if it is
changed. This behavior exists since at least PHP 5.1.
> Considering any application handling data from network should handle
cases when received data is not complete
As this is not the normal case I would suggest to introduce some timeout
handling (this is what applications like e.g. Apache does, I guess), or
fixing what prevents
Doc #51056 [Fbk]: fread() on blocking stream will block even if data is available
Edit report at http://bugs.php.net/bug.php?id=51056&edit=1 ID: 51056 Updated by: magical...@php.net Reported by: magical...@php.net Summary: fread() on blocking stream will block even if data is available Status: Feedback Type: Documentation Problem Package: Streams related Operating System: Linux Gentoo 2.6.32 PHP Version: 5.3.1 New Comment: So, it is normal for php's fread() to return immediatly when less data than asked is available, unless this data arrived while a previous call of fread() was done and there was too much data ? Let me just state that this doesn't makes sense. I tested stdc's fread() and could confirm that its behaviour is consistent: it will only return when it has collected the data it needed, when EOF is reached or when an error occurs. It seems that PHP's php_stream_read() is closer to read() syscall than to stdc's fread(), except for this one specific behaviour. > It follows fread() behavior since years and I believe it should not change. I believe the problem comes from the new streams api which is an attempt to make the socket api obsolete. In fact stream functions (including fread()) behave the same way the old socket counterpart did when passed a socket. The correct behaviour (as defined by common sense, and confirmed by PHP 4.4.9) : Testing PHP version: 4.4.9 socket_read took 0.06ms to read 8 bytes socket_read took 5.08ms to read 256 bytes socket_read took 0.01ms to read 45 bytes socket_read took 0.08ms to read 8 bytes socket_read took 5.06ms to read 256 bytes socket_read took 0.01ms to read 45 bytes socket_read took 0.07ms to read 8 bytes socket_read took 5.05ms to read 256 bytes socket_read took 0.01ms to read 45 bytes socket_read took 0.08ms to read 8 bytes Testing with PHP 5.1.0 (first version containing stream_socket_pair()) exhibits a change of behaviour due to the new stream api. Both tests 51056.phpt and 51056-2.phpt pass on PHP 4.4.9. By the way using nonblocking mode makes no sense with provided example. It would just make the program use 100% cpu. For example a PHP program reading an email from a POP3 server might lockdown because of this bug in blocking mode. If end of email is reached while a read is in progress and a new read is called, it will block until the server closes connections (expected behaviour = return remaining data). As a PHP sockets programmer (I believe my experience when it comes to php and sockets is not negligeable) I say once more that *this* fread()'s behaviour is not consistent. fread() in blocking mode should block until it has enough bytes or return as soon as some bytes are avaialble. Blocking should not depend on when data has arrived. Previous Comments: [2010-03-11 22:03:51] lbarn...@php.net > I still believe fread() should not hang when it has data it can return. It follows fread() behavior since years and I believe it should not change. > The C counterpart doesn't C's fread() does :) > and the manual says it doesn't. The manual looks wrong on this point, "reading will stop after a packet is available" is never true, whatever packet means. fread() (both PHP's and C's) returns less data than asked only on EOF or errors. The only reliable way of doing non-blocking i/o is still to use non-blocking streams ;-) [2010-03-11 21:39:48] magical...@php.net I still believe fread() should not hang when it has data it can return. The C counterpart doesn't, and the manual says it doesn't. Regarding test 51056-2.phpt.txt the manual explicitly says that this *can happen* on anything else than files (read warning in example #3 on http://php.net/fread ) While I understand your concern for people who might be relying on current bogus behaviour I find this very unlikely considering network streams are subject to lags and different kinds of behaviour due to the large amount of tcp implementations on internet. In the worst case, the manual explicitly warns against relying on fread() returning as many bytes as requested, and says buffering must be used. [2010-03-11 21:23:43] lbarn...@php.net > Apache [...] uses timeouts [...] to detect dead clients This is what I was meaning :) (and I though you was meaning this too : "application handling data from network should handle cases when received data is not complete") Dead clients, or situations like this are not the "normal case", and sometimes this can be handled with timeouts. If you are in situations where this is the normal case, one solution is to use non blocking streams. The following code does exactly what you are asking for (if there is something to read, return it; else,
Req #49203 [Fbk]: call_user_func_array when calling a parent constructor not from a user class
Edit report at http://bugs.php.net/bug.php?id=49203&edit=1
ID: 49203
Updated by: magical...@php.net
Reported by:magical...@php.net
Summary:call_user_func_array when calling a parent
constructor not from a user class
Status: Feedback
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Linux x86_64
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
Rather simple: if a given class's constructor is named with the class
name (and
not "__construct"), and is extended, then from the extending class:
- calling parent::__construct() will work
- calling call_user_func_array(array('parent', '__construct'), array())
won't
The behaviour would usually be assumed to be the same, but it is not.
Previous Comments:
[2011-01-01 22:47:06] j...@php.net
What is the FR here? Re-type if this is actually a bug. And rewrite the
summary, it isn't very informative. And update PHP version if this is
still an issue.
[2009-08-10 08:29:09] magical...@php.net
Ok, mysqli's contructor is not named "__construct"
Method [ public method mysqli ] {
}
Still, one would expect that calling
call_user_func_array(array('parent', '__construct'), ...) acts the same
as parent::__construct(...) (which works). I guess somewhere the call to
__construct must be redirected to the ctor...
[2009-08-10 07:48:18] col...@php.net
The problem is not about internal classes, but classes not defining a
__construct:
class A {
}
class B extends A {
public function __construct() {
echo "here\n";
call_user_func(array('parent', '__construct'));
}
}
$x = new B;
seems like is_callable() returns true on array('parent', '__construct')
and shouldn't.
[2009-08-10 03:57:09] magical...@php.net
Description:
When using:
call_user_func_array(array('parent', '__construct'), $var);
This works if the parent is a user-defined class, but not if it's an
extension-provided class (the extended constructor gets called twice).
This is not easy to explain, see attached reproduce code for more
details.
My initial code was (in a class extending mysqli):
private function __construct($params) {
call_user_func_array(array('parent', '__construct'),
$params);
$this->set_charset('utf8');
}
Using this instead awfully fixes the problem:
parent::__construct($params[0], $params[1], $params[2], $params[3]);
Note that this wasn't possible in PHP 5.2.x
Warning: call_user_func_array(): First argument is expected to be a
valid callback, 'parent::__construct' was given in foo.php on line 5
Reproduce code:
---
http://bugs.php.net/bug.php?id=49203&edit=1
#38739 [NEW]: stream_socket_server should not require a port
From: magicaltux at ookoo dot org Operating system: * PHP version: 5.1.6 PHP Bug Type: Feature/Change Request Bug description: stream_socket_server should not require a port Description: When trying, for example, to do : We get the following output : Warning: stream_socket_server(): unable to connect to tcp://0.0.0.0 (Failed to parse address "0.0.0.0") in /home/magicaltux/- on line 2 string(33) "Failed to parse address "0.0.0.0"" Expected result would be to have no port passed to bind, and thru having a random port allocated by the operating system (that we would later retrieve with stream_socket_get_name). In socket_bind, the port is also optionnal. It's still possible to get a random port by using ":0" but the no-port behaviour would be great too (and probably not too hard to implement). Reproduce code: --- Expected result: string(0) "" Actual result: -- Warning: stream_socket_server(): unable to connect to tcp://0.0.0.0 (Failed to parse address "0.0.0.0") in /home/magicaltux/- on line 2 string(33) "Failed to parse address "0.0.0.0"" -- Edit bug report at http://bugs.php.net/?id=38739&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38739&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38739&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38739&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38739&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38739&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38739&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38739&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38739&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38739&r=support Expected behavior:http://bugs.php.net/fix.php?id=38739&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38739&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38739&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38739&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38739&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38739&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38739&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38739&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38739&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38739&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38739&r=mysqlcfg
#36445 [Com]: Cannot enable encryption for stream server
ID: 36445 Comment by: magicaltux at gmail dot com Reported By: Jacek at veo dot pl Status: Assigned Bug Type: Sockets related Operating System: SuSE Linux 9.1 PHP Version: 5.1.4 Assigned To: wez New Comment: I'm working on a PHP-based SMTP server, and I also have problems with STARTTLS. The full sourcecode can be fetched from: http://ookoo.org/svn/pinetd/ The STARTTLS function does *not* work. Warning: stream_socket_enable_crypto(): SSL operation failed with code 111. OpenSSL Error messages: error::lib(0):func(0):reason(0) in /usr/local/pinetd/daemon/25.php on line 373 Previous Comments: [2006-07-24 18:58:32] gladyston at eacnet dot com dot br --> Apache 2.2 --> PHP Version 5.1.4 --> Linux 2.6.8-2-386 Aug 16 12:46:35 UTC 2005 i686 GNU/Linux https://shopline.itau.com.br/shopline/consulta.asp?DC=N183Z175F213E11E234B109E158C173O228K60Y165W217L103M205X7D136G92Q103R208F14E7W147L40Q103G244F243W216Z177K39S36F154S121D205D155A136V";; $handle = fopen($url, "r"); ?> Warning: fopen() [function.fopen]: SSL operation failed with code 114. OpenSSL Error messages: error::lib(0):func(0):reason(0) in /home/gladyston/webservice/t2.php on line 3 Warning: fopen() [function.fopen]: Failed to enable crypto in /home/gladyston/webservice/t2.php on line 3 Warning: fopen(https://shopline.itau.com.br/shopline/consulta.asp?DC=N183Z175F213E11E234B109E158C173O228K60Y165W217L103M205X7D136G92Q103R208F14E7W147L40Q103G244F243W216Z177K39S36F154S121D205D155A136V) [function.fopen]: failed to open stream: Bad file descriptor in /home/gladyston/webservice/t2.php on line 3 Ass, Gladyston Batista Belo Horizonte - Brazil [2006-06-01 07:35:01] Jacek at veo dot pl PHP 5.1.4 + OpenSSL 0.9.8b: SERVER serwer:/tls # php tls-server.php 1: STARTTLS Warning: stream_socket_enable_crypto(): Unable to set private key file `./server.pem' in /tls/tls-server.php on line 30 Warning: stream_socket_enable_crypto(): failed to create an SSL handle in /tls/tls-server.php on line 30 Error (if any): 2: [EMAIL PROTECTED]�F�~F1�V�hxK.985/32~}|yxwtsr Warning: stream_socket_accept(): accept failed: Connection timed out in /tls/tls-server.php on line 2 CLIENT serwer:/tls # php tls-client.php 1: 220 ESMTP 2: 250 STARTTLS Warning: stream_socket_enable_crypto(): SSL operation failed with code 114. OpenSSL Error messages: error::lib(0):func(0):reason(0) in /tls/tls-client.php on line 10 bool(false) [2006-05-31 21:03:47] e at osterman dot com And just to make sure we're using the same tools to test, this is the certificate that I used to make the test above work. The pass phrase is "comet". -BEGIN CERTIFICATE- MIIDgTCCAuqgAwIBAgIJAMgtIWVzb1oIMA0GCSqGSIb3DQEBBQUAMIGIMQswCQYD VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2Vs ZXMxFDASBgNVBAoTC091ciBDb21wYW55MQ0wCwYDVQQLEwRUZXN0MQwwCgYDVQQD EwNEZXYxGzAZBgkqhkiG9w0BCQEWDGFzZEBob3N0LmNvbTAeFw0wNjA1MjYwMTM4 NTRaFw0wNzA1MjYwMTM4NTRaMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2Fs aWZvcm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxFDASBgNVBAoTC091ciBDb21w YW55MQ0wCwYDVQQLEwRUZXN0MQwwCgYDVQQDEwNEZXYxGzAZBgkqhkiG9w0BCQEW DGFzZEBob3N0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3mStTm74 kOQCelquoGI/WyUIOvngDdNcJGmi2xnzDpRjKfQTH/3VVDQJUwvjKcLxnBQHFg7M nvEZrfC3LEmFajAzRKjXK5gUCQEQKqhbVsfZO+7ANq4axNldd4UgMhPeZIKr8DDt P3pjFqFSYh/dtOq2pfDXSbstmCZ1Q3GAYDcCAwEAAaOB8DCB7TAdBgNVHQ4EFgQU WQSzc00pkM9aCzsxKJpTYm3kwEUwgb0GA1UdIwSBtTCBsoAUWQSzc00pkM9aCzsx KJpTYm3kwEWhgY6kgYswgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9y bmlhMRQwEgYDVQQHEwtMb3MgQW5nZWxlczEUMBIGA1UEChMLT3VyIENvbXBhbnkx DTALBgNVBAsTBFRlc3QxDDAKBgNVBAMTA0RldjEbMBkGCSqGSIb3DQEJARYMYXNk QGhvc3QuY29tggkAyC0hZXNvWggwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUF AAOBgQA7G/XKQ9kLTZOcVAG/IOxdn9tW38sEwHifNQ7zMSS5di1MmnD5JJWdK/s4 dzN06T1Ey5FCu2kafFzk48khZpoPsXMRF8DNBXLVSCGj4maPtEviJVjwtj3XwZjA 82a8A/Yil0+fo25zPX4I4oBcbl3bPqzVPXxsQ7myp9f7MDZcbQ== -END CERTIFICATE- -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,E4476A175B6608B6 r0sox8H5ijuOanXwYFtIDgPti3AAuIUdy5EJG9GZbrtQHEW6HL+YxdI58Ng70t4w EfBvcuLb7XAGsJwF65yad0vSXsYv6F+0brEefEvZX3ljxUZ3yGfHVJyEdBWJty7X A8QpqOVVQseAST1IKeWOIT16/a9ZOgwnIhQe36y43pxBwL5tumXTM+AuWPOBW8c0 s49I8GyptttGJpcFohLsmP9Jza/fMIzYFNeuOBQ93fieCcVXBd2fWNyZVEsOU5Mi kt5FQ9Lc9F8Wc+Mh0xiodDz6H+2yNIMC2SNu/mDSAGwDCctBZ34enFDad/eBiYW+ iTjMaqWGFs+cantSgVQ6pdZWYQd5Rsb3/Qbcfia/C1vtzWipBG7wlQCsNWwceXx/ f8hqWl5kyCxvBdH9eyRNMVJkCbFABl9tnaMGRi/UnVL68wgUvosAsdCjUrdL3x7O i6yMBrxYjACbYslPFaG5OtgXcbacBKjsVMkcRYRyGqClgVZHICYZXhZoZTjOsgT4 L9WivT1RnozmFUMPaXbnxX4h/B3v6aSYAc4mPM6oMFTiXGJ7cLoafNw7Fxug7oeF 0+04DykzFCsL
