[PHP-BUG] Bug #52167 [NEW]: gmp_pow does not accept gmp values
From: Operating system: Linux PHP version: 5.3.2 Package: GNU MP related Bug Type: Bug Bug description:gmp_pow does not accept gmp values Description: gmp_pow throws a "expects parameter 2 to be long" error when passed a gmp value. Works nicely with PHP 5.2.x but not with PHP 5.3. I am doing some maths for encryption with php which use large integers and I have to compute pow(a,b) with both values being large integers (~512 bits). I'm opening this bug so we can investigate why gmp_pow() has been modified to only accept integers as second argument, and if there is no good reason make it accept gmp values again. My guess is this change was done on the PHP_5_2 branch but not ported to PHP_5_3. Unfortunately svn blame couldn't fetch anything interesting to know why this became like this. Test script: --- $a=gmp_init(48974); $b=gmp_init(55); $c=gmp_pow($a,$b); var_dump(gmp_intval($c)); Expected result: int(7944261659914959072) Actual result: -- Warning: gmp_pow() expects parameter 2 to be long, resource given in Command line code on line 1 int(0) -- Edit bug report at http://bugs.php.net/bug.php?id=52167&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52167&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52167&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52167&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52167&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52167&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52167&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52167&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52167&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52167&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52167&r=support Expected behavior: http://bugs.php.net/fix.php?id=52167&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52167&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52167&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52167&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52167&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52167&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52167&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52167&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52167&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52167&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52167&r=mysqlcfg
#46128 [Com]: Magic function __cast($to)
ID: 46128
Comment by: mark at hell dot ne dot jp
Reported By: 131 dot php at cloudyks dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.6
New Comment:
Please test the following extension :
http://ookoo.org/svn/snip/phpcastable/
This extension adds a "Castable" interface. Any class implementing this
interface have to implement a __cast() function. This function will be
called when the object needs to be casted to a type.
This extension is EXPERIMENTAL and needs more testing/review before
being used in any production system.
Previous Comments:
[2008-10-27 17:08:24] info at netmosfera dot it
AWESOME!
php developers, please, we need it!!
http://bugs.php.net/bug.php?id=46404
[2008-10-06 04:15:03] mark at hell dot ne dot jp
Backported to PHP 5.2.6 :
http://ookoo.org/svn/snip/php-5.2.6_class_cast_func.patch
[2008-10-05 16:33:07] 131 dot php at cloudyks dot org
This is awesome
[2008-10-05 08:49:55] mark at hell dot ne dot jp
Did a test implementation only supporting a few types (int, float,
bool, string).
This works as expected.
Test code:
--
class test {
public function __cast($type) {
switch($type) {
case 'string': return 'a string';
case 'bool': return true;
case 'float': return 123.456;
case 'int': return 978;
default:
var_dump($type);
return null;
}
}
}
$t = new test();
var_dump((string)$t);
var_dump((int)$t);
var_dump((float)$t);
var_dump((bool)$t);
Result:
string(8) "a string"
int(978)
float(123.456)
bool(true)
Here's the patch file for this simple implementation against PHP
5.3.0alpha2.
http://ookoo.org/svn/snip/php-5.3.0alpha2_class_cast_func.patch
[2008-09-19 15:52:29] 131 dot php at cloudyks dot org
Description:
The same way __toString is implemented, i suggest new magics functions
__toBool, __toInt, __toArray, or maybe, as suggested on php.general, a
generic magic function __cast($type){}
An example of implementation could be
class error extends exeption {
__toBool(){return false; }
}
Reproduce code:
---
http://bugs.php.net/?id=46128&edit=1
#45314 [Com]: wddx_serialize_value() does not handle unicode properly
ID: 45314 Comment by: mark at hell dot ne dot jp Reported By: mikx at mikx dot de Status: Open Bug Type: WDDX related Operating System: * PHP Version: 5.2.6 New Comment: This bug is related to bug #46496. Bug #37571 indeed seems to be at the origin of the problem. Previous Comments: [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
#45037 [Com]: wddx_add_vars() does not convert variable names to UTF8
ID: 45037
Comment by: mark at hell dot ne dot jp
Reported By: JeanLuc dot TRIPLET at yahoo dot fr
Status: Open
Bug Type: WDDX related
Operating System: Windows
PHP Version: 5.2.6
New Comment:
This report is bogus, as WDDX is not supposed to convert content to
UTF-8 either.
Please see bug #46496 for more infos.
Previous Comments:
[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
#46496 [Bgs]: [PATCH] wddx_serialize_value() treats input as ISO-8859-1
ID: 46496 User updated by: mark at hell dot ne dot jp Reported By: mark at hell dot ne dot jp Status: Bogus Bug Type: WDDX related Operating System: Linux PHP Version: 5.2.6 New Comment: Updated version of the patch, with a test fixed (test for bug #37569 depended on wddx_* functions accepting ISO-8859-1). http://ookoo.org/svn/snip/php-5.2.7rc3_wddx_utf8_resolved.patch compile runs nicely, make test does not report anything wrong, and the test for bug #37569 now also checks for this bug (ie. it checks that wddx_* functions indeed handle utf-8 as expected). Previous Comments: [2008-11-06 05:00:49] mark at hell dot ne dot jp Here's a patch against PHP 5.2.7rc2 to fix this issue. The real problem is about WDDX always considering input is ISO-8859-1. This is not consistent with PHP <5.2.5, not consistent with the XML api, and not consistent with the documentation. http://ookoo.org/svn/snip/php-5.2.7rc2_wddx_utf8_resolved.patch [2008-11-06 04:54:54] mark at hell dot ne dot jp Tested and reproduced with PHP 5.2.7rc2 [2008-11-06 04:36:12] mark at hell dot ne dot jp Hello, I'd like this bug to be reopened. The &#xxx; are due to the PHP's bugtracker unability to display unicode characters. My report was initially written with korean string. Here's a screenshot of an UTF-8 terminal with the same test: http://beta.magicaltux.net/php5_bug_utf8_terminal.png [2008-11-06 01:14:25] [EMAIL PROTECTED] http://fi.php.net/manual/en/wddx.examples.php "Note: If you want to serialize non-ASCII characters you have to convert your data to UTF-8 first" -------- [2008-11-05 17:30:47] mark at hell dot ne dot jp Description: As written on the page on : http://fr.php.net/manual/en/ref.wddx.php wddx_serialize_value() always treats input as ISO-8859-1. This behaviour has changed in PHP 5.2.5, and has caused a few bugs on our side (and it seems we are not the only ones). For now the workaround is to use utf8_decode() on the resulting XML string. Reproduce code: --- Expected result: 안녕 하세요 Actual result: -- 안녕 하세요 -- Edit this bug report at http://bugs.php.net/?id=46496&edit=1
#46496 [Bgs]: [PATCH] wddx_serialize_value() treats input as ISO-8859-1
ID: 46496 User updated by: mark at hell dot ne dot jp -Summary: wddx_serialize_value() treats input as ISO-8859-1 Reported By: mark at hell dot ne dot jp Status: Bogus Bug Type: WDDX related Operating System: Linux PHP Version: 5.2.6 New Comment: Here's a patch against PHP 5.2.7rc2 to fix this issue. The real problem is about WDDX always considering input is ISO-8859-1. This is not consistent with PHP <5.2.5, not consistent with the XML api, and not consistent with the documentation. http://ookoo.org/svn/snip/php-5.2.7rc2_wddx_utf8_resolved.patch Previous Comments: [2008-11-06 04:54:54] mark at hell dot ne dot jp Tested and reproduced with PHP 5.2.7rc2 [2008-11-06 04:36:12] mark at hell dot ne dot jp Hello, I'd like this bug to be reopened. The &#xxx; are due to the PHP's bugtracker unability to display unicode characters. My report was initially written with korean string. Here's a screenshot of an UTF-8 terminal with the same test: http://beta.magicaltux.net/php5_bug_utf8_terminal.png [2008-11-06 01:14:25] [EMAIL PROTECTED] http://fi.php.net/manual/en/wddx.examples.php "Note: If you want to serialize non-ASCII characters you have to convert your data to UTF-8 first" -------- [2008-11-05 17:30:47] mark at hell dot ne dot jp Description: As written on the page on : http://fr.php.net/manual/en/ref.wddx.php wddx_serialize_value() always treats input as ISO-8859-1. This behaviour has changed in PHP 5.2.5, and has caused a few bugs on our side (and it seems we are not the only ones). For now the workaround is to use utf8_decode() on the resulting XML string. Reproduce code: --- Expected result: 안녕 하세요 Actual result: -- 안녕 하세요 -- Edit this bug report at http://bugs.php.net/?id=46496&edit=1
#46496 [Bgs]: wddx_serialize_value() treats input as ISO-8859-1
ID: 46496 User updated by: mark at hell dot ne dot jp Reported By: mark at hell dot ne dot jp Status: Bogus Bug Type: WDDX related Operating System: Linux PHP Version: 5.2.6 New Comment: Tested and reproduced with PHP 5.2.7rc2 Previous Comments: [2008-11-06 04:36:12] mark at hell dot ne dot jp Hello, I'd like this bug to be reopened. The &#xxx; are due to the PHP's bugtracker unability to display unicode characters. My report was initially written with korean string. Here's a screenshot of an UTF-8 terminal with the same test: http://beta.magicaltux.net/php5_bug_utf8_terminal.png [2008-11-06 01:14:25] [EMAIL PROTECTED] http://fi.php.net/manual/en/wddx.examples.php "Note: If you want to serialize non-ASCII characters you have to convert your data to UTF-8 first" ---- [2008-11-05 17:30:47] mark at hell dot ne dot jp Description: As written on the page on : http://fr.php.net/manual/en/ref.wddx.php wddx_serialize_value() always treats input as ISO-8859-1. This behaviour has changed in PHP 5.2.5, and has caused a few bugs on our side (and it seems we are not the only ones). For now the workaround is to use utf8_decode() on the resulting XML string. Reproduce code: --- Expected result: 안녕 하세요 Actual result: -- 안녕 하세요 -- Edit this bug report at http://bugs.php.net/?id=46496&edit=1
#46496 [Bgs]: wddx_serialize_value() treats input as ISO-8859-1
ID: 46496 User updated by: mark at hell dot ne dot jp Reported By: mark at hell dot ne dot jp Status: Bogus Bug Type: WDDX related Operating System: Linux PHP Version: 5.2.6 New Comment: Hello, I'd like this bug to be reopened. The &#xxx; are due to the PHP's bugtracker unability to display unicode characters. My report was initially written with korean string. Here's a screenshot of an UTF-8 terminal with the same test: http://beta.magicaltux.net/php5_bug_utf8_terminal.png Previous Comments: [2008-11-06 01:14:25] [EMAIL PROTECTED] http://fi.php.net/manual/en/wddx.examples.php "Note: If you want to serialize non-ASCII characters you have to convert your data to UTF-8 first" ---- [2008-11-05 17:30:47] mark at hell dot ne dot jp Description: As written on the page on : http://fr.php.net/manual/en/ref.wddx.php wddx_serialize_value() always treats input as ISO-8859-1. This behaviour has changed in PHP 5.2.5, and has caused a few bugs on our side (and it seems we are not the only ones). For now the workaround is to use utf8_decode() on the resulting XML string. Reproduce code: --- Expected result: 안녕 하세요 Actual result: -- 안녕 하세요 -- Edit this bug report at http://bugs.php.net/?id=46496&edit=1
#46496 [NEW]: wddx_serialize_value does not respects the documentation
From: mark at hell dot ne dot jp Operating system: Linux PHP version: 5.2.6 PHP Bug Type: XML related Bug description: wddx_serialize_value does not respects the documentation Description: As written on the page on : http://fr.php.net/manual/en/ref.wddx.php wddx_serialize_value() always treats input as ISO-8859-1. This behaviour has changed in PHP 5.2.5, and has caused a few bugs on our side (and it seems we are not the only ones). For now the workaround is to use utf8_decode() on the resulting XML string. Reproduce code: --- Expected result: 안녕 하세요 Actual result: -- 안녕 하세요 -- Edit bug report at http://bugs.php.net/?id=46496&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46496&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46496&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46496&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46496&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46496&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46496&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46496&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46496&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46496&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46496&r=support Expected behavior: http://bugs.php.net/fix.php?id=46496&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46496&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46496&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46496&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46496&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46496&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46496&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46496&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46496&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46496&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46496&r=mysqlcfg
#5007 [Com]: enable no-resolve mode for here docs
ID: 5007 Comment by: mark at hell dot ne dot jp Reported By: waldschrott at kiffen dot de Status: Analyzed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.0 Latest CVS (13/06/2000) New Comment: I believe this feature request can now be closed (with PHP 5.3.0). http://fr.php.net/language.types.string#language.types.string.syntax.nowdoc Previous Comments: [2000-08-28 01:49:53] [EMAIL PROTECTED] in addition we could make here-docs structured code friendly by adding sth. like a parameter (don´t know where,maybe <<<3"MARK") indicationg how many tabs are prepended, thus the above would render echo <<<3"MARK" \t\t\tHello \t\t\tMr. Foobar \t\t\t\tTest MARK; as Hello Mr. Foobar \tTest and not with these redundant 3*\t´s in front of every line then users can user here-docs in classes and functions *without* crippling their code to ugliness [2000-07-08 10:49:48] waldschrott at kiffen dot de The format of here-documents is as follows: <<[-]word here-document delimiter No parameter expansion, command substitution, arithmetic expansion, or pathname expansion is performed on word. If any characters in word are quoted, the delimiter is the result of quote removal on word, and the lines in the here-document are not expanded. If word is unquoted, all lines of the here-document are subjected to parameter expansion, command substitution, and arithmetic expansion. In the latter case, the character sequence \ is ignored, and \ must be used to quote the characters \, $, and `. If the redirection operator is <<-, then all leading tab characters are stripped from input lines and the line containing delimiter. This allows here-documents within shell scripts to be indented in a natural fashion. [2000-06-13 19:22:54] waldschrott at kiffen dot de Perl has <<"MARK" and <<'MARK' (as Stas told me), it would be handy for PHP too... I think sample code isn´t need, because it´s an existing feature in Perl core devolpers know of. -- Edit this bug report at http://bugs.php.net/?id=5007&edit=1
#46128 [Com]: Magic function __cast($to)
ID: 46128
Comment by: mark at hell dot ne dot jp
Reported By: 131 dot php at cloudyks dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.6
New Comment:
Backported to PHP 5.2.6 :
http://ookoo.org/svn/snip/php-5.2.6_class_cast_func.patch
Previous Comments:
[2008-10-05 16:33:07] 131 dot php at cloudyks dot org
This is awesome
[2008-10-05 08:49:55] mark at hell dot ne dot jp
Did a test implementation only supporting a few types (int, float,
bool, string).
This works as expected.
Test code:
--
class test {
public function __cast($type) {
switch($type) {
case 'string': return 'a string';
case 'bool': return true;
case 'float': return 123.456;
case 'int': return 978;
default:
var_dump($type);
return null;
}
}
}
$t = new test();
var_dump((string)$t);
var_dump((int)$t);
var_dump((float)$t);
var_dump((bool)$t);
Result:
string(8) "a string"
int(978)
float(123.456)
bool(true)
Here's the patch file for this simple implementation against PHP
5.3.0alpha2.
http://ookoo.org/svn/snip/php-5.3.0alpha2_class_cast_func.patch
[2008-09-19 15:52:29] 131 dot php at cloudyks dot org
Description:
The same way __toString is implemented, i suggest new magics functions
__toBool, __toInt, __toArray, or maybe, as suggested on php.general, a
generic magic function __cast($type){}
An example of implementation could be
class error extends exeption {
__toBool(){return false; }
}
Reproduce code:
---
http://bugs.php.net/?id=46128&edit=1
#46128 [Com]: Magic function __cast($to)
ID: 46128
Comment by: mark at hell dot ne dot jp
Reported By: 131 dot php at cloudyks dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.6
New Comment:
Did a test implementation only supporting a few types (int, float,
bool, string).
This works as expected.
Test code:
--
class test {
public function __cast($type) {
switch($type) {
case 'string': return 'a string';
case 'bool': return true;
case 'float': return 123.456;
case 'int': return 978;
default:
var_dump($type);
return null;
}
}
}
$t = new test();
var_dump((string)$t);
var_dump((int)$t);
var_dump((float)$t);
var_dump((bool)$t);
Result:
string(8) "a string"
int(978)
float(123.456)
bool(true)
Here's the patch file for this simple implementation against PHP
5.3.0alpha2.
http://ookoo.org/svn/snip/php-5.3.0alpha2_class_cast_func.patch
Previous Comments:
[2008-09-19 15:52:29] 131 dot php at cloudyks dot org
Description:
The same way __toString is implemented, i suggest new magics functions
__toBool, __toInt, __toArray, or maybe, as suggested on php.general, a
generic magic function __cast($type){}
An example of implementation could be
class error extends exeption {
__toBool(){return false; }
}
Reproduce code:
---
http://bugs.php.net/?id=46128&edit=1
#46222 [Com]: Memory issues in ArrayObject
ID: 46222
Comment by: mark at hell dot ne dot jp
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.6
Assigned To: colder
New Comment:
The patch by crrodriguez doesn't fix the main problem: If you print_r
(or var_dump in my case) $test, it's empty.
This fixes the overwritting of EG(uninitialized_zval_ptr), but not the
behaviour problem.
I suggest updating the reproduce code as following:
Reproduce code:
---
$test = new ArrayObject();
$test['d1']['d2'] = 'hello';
var_dump($test, $test3['m']);
Expected result (php5.3):
-
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["d1"]=>
array(1) {
["d2"]=>
string(5) "hello"
}
}
}
NULL
Actual result (php5.3):
---
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
array(1) {
["d2"]=>
string(5) "hello"
}
Actual result with crrodriguez's patch:
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
NULL
Previous Comments:
[2008-10-05 03:46:30] crrodriguez at opensuse dot org
Not sure, but this patch works for me
Index: ext/spl/spl_array.c
===
RCS file: /repository/php-src/ext/spl/spl_array.c,v
retrieving revision 1.71.2.17.2.13.2.26
diff -u -p -r1.71.2.17.2.13.2.26 spl_array.c
--- ext/spl/spl_array.c 29 Sep 2008 22:45:27 -
1.71.2.17.2.13.2.26
+++ ext/spl/spl_array.c 5 Oct 2008 03:44:42 -
@@ -346,7 +346,7 @@ static zval *spl_array_read_dimension_ex
/* When in a write context,
* ZE has to be fooled into thinking this is in a reference
set
* by separating (if necessary) and returning as an is_ref=1
zval (even if refcount == 1) */
- if ((type == BP_VAR_W || type == BP_VAR_RW) &&
!Z_ISREF_PP(ret)) {
+ if (ret != &EG(uninitialized_zval_ptr) && (type == BP_VAR_W ||
type == BP_VAR_RW) && !Z_ISREF_PP(ret)) {
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
[2008-10-04 20:57:34] mark at hell dot ne dot jp
Changing the previously mentionned code to add one line :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/* Separate */
MAKE_STD_ZVAL(newval);
*newval = **ret;
zval_copy_ctor(newval);
Z_SET_REFCOUNT_P(newval, 1);
/* Replace */
Z_DELREF_PP(ret);
ret = emalloc(sizeof(void*)); // Avoid overwritting stuff??
*ret = newval;
}
Seems to fix the initial problem (dumping anything else no longer
breaks stuff; I didn't care about memleaks in this "fix", it's just to
demonstrate that this part of code has problems), however I see
something else coming: dumping $test in initial code shows that it stays
empty even after assigning $test['d1']['d2'].
I guess the real problem is probably something like the fact
$test['d1'] didn't get created, so d2 gets lost in "outer space".
[2008-10-04 20:29:34] mark at hell dot ne dot jp
I searched a bit too and found that we overwrite the memory space for:
EG(uninitialized_zval_ptr)
In spl/spl_array.c near line 375 (probably wrong as I added lots of
debug to find out where this came from).
Basically this code :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/* Separate */
MAKE_STD_ZVAL(newval);
*newval = **ret;
zval_copy_ctor(newval);
Z_SET_REFCOUNT_P(newval, 1);
/* Replace */
Z_DELREF_PP(ret);
*ret = newval;
}
Will be run in some cases with ret == &EG(uninitialized_zval_ptr),
which means writing to *ret is the same as writing to
EG(uninitialized_zval_ptr).
I checked how new (unexisting) array entries are managed in Zend and
will try to replace some code here to see if it helps.
[2008-10-03 13:13:12] karsten at typo3 dot org
Ran it under:
PHP 5.3.0alpha1 (cli) (built: Sep 8 2008 13:16:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
(installed via MacPorts on 10.5.5)
Got:
Array
(
[d2] => hello
)
[2008-10-03 04:47:28] [EMAIL PROTECTED]
Ran it under:
PHP 5.3.
#46222 [Com]: Memory issues in ArrayObject
ID: 46222
Comment by: mark at hell dot ne dot jp
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.6
Assigned To: colder
New Comment:
Adding the following code in spl_array.c near line 350 seems to fix the
problem (however it's a bit dirty, I think).
After line :
ret = spl_array_get_dimension_ptr_ptr(check_inherited, object,
offset, type TSRMLS_CC);
Add :
// Dirty test patch
if ((type == BP_VAR_W || type == BP_VAR_RW) && (ret ==
&EG(uninitialized_zval_ptr))) {
// write a NULL value in the missing part of the array
spl_array_write_dimension_ex(check_inherited, object, offset,
EG(uninitialized_zval_ptr) TSRMLS_CC);
// And reload it
ret = spl_array_get_dimension_ptr_ptr(check_inherited, object,
offset, type TSRMLS_CC);
}
This fixes this bug, but I don't think this is the best way to fix it.
I just make things how they should be at a later point in code, I don't
know the Zend engine internals enough (and the documentation's empty
skeleton isn't helping much) to make a better fix than that.
Previous Comments:
--------
[2008-10-05 05:38:58] mark at hell dot ne dot jp
The patch by crrodriguez doesn't fix the main problem: If you print_r
(or var_dump in my case) $test, it's empty.
This fixes the overwritting of EG(uninitialized_zval_ptr), but not the
behaviour problem.
I suggest updating the reproduce code as following:
Reproduce code:
---
$test = new ArrayObject();
$test['d1']['d2'] = 'hello';
var_dump($test, $test3['m']);
Expected result (php5.3):
-
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(1) {
["d1"]=>
array(1) {
["d2"]=>
string(5) "hello"
}
}
}
NULL
Actual result (php5.3):
---
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
array(1) {
["d2"]=>
string(5) "hello"
}
Actual result with crrodriguez's patch:
object(ArrayObject)#1 (1) {
["storage":"ArrayObject":private]=>
array(0) {
}
}
NULL
[2008-10-05 03:46:30] crrodriguez at opensuse dot org
Not sure, but this patch works for me
Index: ext/spl/spl_array.c
===
RCS file: /repository/php-src/ext/spl/spl_array.c,v
retrieving revision 1.71.2.17.2.13.2.26
diff -u -p -r1.71.2.17.2.13.2.26 spl_array.c
--- ext/spl/spl_array.c 29 Sep 2008 22:45:27 -
1.71.2.17.2.13.2.26
+++ ext/spl/spl_array.c 5 Oct 2008 03:44:42 -
@@ -346,7 +346,7 @@ static zval *spl_array_read_dimension_ex
/* When in a write context,
* ZE has to be fooled into thinking this is in a reference
set
* by separating (if necessary) and returning as an is_ref=1
zval (even if refcount == 1) */
- if ((type == BP_VAR_W || type == BP_VAR_RW) &&
!Z_ISREF_PP(ret)) {
+ if (ret != &EG(uninitialized_zval_ptr) && (type == BP_VAR_W ||
type == BP_VAR_RW) && !Z_ISREF_PP(ret)) {
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
[2008-10-04 20:57:34] mark at hell dot ne dot jp
Changing the previously mentionned code to add one line :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/* Separate */
MAKE_STD_ZVAL(newval);
*newval = **ret;
zval_copy_ctor(newval);
Z_SET_REFCOUNT_P(newval, 1);
/* Replace */
Z_DELREF_PP(ret);
ret = emalloc(sizeof(void*)); // Avoid overwritting stuff??
*ret = newval;
}
Seems to fix the initial problem (dumping anything else no longer
breaks stuff; I didn't care about memleaks in this "fix", it's just to
demonstrate that this part of code has problems), however I see
something else coming: dumping $test in initial code shows that it stays
empty even after assigning $test['d1']['d2'].
I guess the real problem is probably something like the fact
$test['d1'] didn't get created, so d2 gets lost in "outer space".
[2008-10-04 20:29:34] mark at hell dot ne dot jp
I searched a bit too and found that we overwrite the memory space for:
EG(uninitialized_zval_ptr)
In spl/spl_array.c near line 375 (probably wrong as I added lots of
debug to find out where this came from).
Basically this code :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/*
#46222 [Com]: Memory issues in ArrayObject
ID: 46222
Comment by: mark at hell dot ne dot jp
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.6
Assigned To: colder
New Comment:
Changing the previously mentionned code to add one line :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/* Separate */
MAKE_STD_ZVAL(newval);
*newval = **ret;
zval_copy_ctor(newval);
Z_SET_REFCOUNT_P(newval, 1);
/* Replace */
Z_DELREF_PP(ret);
ret = emalloc(sizeof(void*)); // Avoid overwritting stuff??
*ret = newval;
}
Seems to fix the initial problem (dumping anything else no longer
breaks stuff; I didn't care about memleaks in this "fix", it's just to
demonstrate that this part of code has problems), however I see
something else coming: dumping $test in initial code shows that it stays
empty even after assigning $test['d1']['d2'].
I guess the real problem is probably something like the fact
$test['d1'] didn't get created, so d2 gets lost in "outer space".
Previous Comments:
--------------------
[2008-10-04 20:29:34] mark at hell dot ne dot jp
I searched a bit too and found that we overwrite the memory space for:
EG(uninitialized_zval_ptr)
In spl/spl_array.c near line 375 (probably wrong as I added lots of
debug to find out where this came from).
Basically this code :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/* Separate */
MAKE_STD_ZVAL(newval);
*newval = **ret;
zval_copy_ctor(newval);
Z_SET_REFCOUNT_P(newval, 1);
/* Replace */
Z_DELREF_PP(ret);
*ret = newval;
}
Will be run in some cases with ret == &EG(uninitialized_zval_ptr),
which means writing to *ret is the same as writing to
EG(uninitialized_zval_ptr).
I checked how new (unexisting) array entries are managed in Zend and
will try to replace some code here to see if it helps.
[2008-10-03 13:13:12] karsten at typo3 dot org
Ran it under:
PHP 5.3.0alpha1 (cli) (built: Sep 8 2008 13:16:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
(installed via MacPorts on 10.5.5)
Got:
Array
(
[d2] => hello
)
[2008-10-03 04:47:28] [EMAIL PROTECTED]
Ran it under:
PHP 5.3.0alpha3-dev (cli) (built: Oct 3 2008 00:09:28) (DEBUG)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
Got:
Array
(
[d2] => hello
)
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/ext/spl/spl_array.c(354) :
Freeing 0x00C1419C (20 bytes), script=-
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_execute.c(932) :
Freeing 0x00C142B8 (44 bytes), script=-
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_API.c(930) : Actual
location (location was relayed)
Last leak repeated 1 time
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_hash.c(247) : Freeing
0x00C14364 (38 bytes), script=-
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_execute.c(727) :
Freeing 0x00C143BC (20 bytes), script=-
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_variables.h(45) :
Freeing 0x00C14400 (6 bytes), script=-
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_variables.c(120) :
Actual location (location was relayed)
=== Total 6 memory leaks detected ===
[2008-10-03 03:57:49] [EMAIL PROTECTED]
Description:
ArrayObject appears to corrupt the symbol table
Checked it with Valgrind and didn't see anything, but haven't checked
the code yet. Appears to be a problem in both 5.2 and 5.3.
Reproduce code:
---
$test = new ArrayObject();
$test['d1']['d2'] = 'hello';
print_r($test3['m']);
Expected result:
nothing
Actual result:
--
Array
(
[d2] => hello
)
--
Edit this bug report at http://bugs.php.net/?id=46222&edit=1
#46222 [Com]: Memory issues in ArrayObject
ID: 46222
Comment by: mark at hell dot ne dot jp
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.6
Assigned To: colder
New Comment:
I searched a bit too and found that we overwrite the memory space for:
EG(uninitialized_zval_ptr)
In spl/spl_array.c near line 375 (probably wrong as I added lots of
debug to find out where this came from).
Basically this code :
if (Z_REFCOUNT_PP(ret) > 1) {
zval *newval;
/* Separate */
MAKE_STD_ZVAL(newval);
*newval = **ret;
zval_copy_ctor(newval);
Z_SET_REFCOUNT_P(newval, 1);
/* Replace */
Z_DELREF_PP(ret);
*ret = newval;
}
Will be run in some cases with ret == &EG(uninitialized_zval_ptr),
which means writing to *ret is the same as writing to
EG(uninitialized_zval_ptr).
I checked how new (unexisting) array entries are managed in Zend and
will try to replace some code here to see if it helps.
Previous Comments:
[2008-10-03 13:13:12] karsten at typo3 dot org
Ran it under:
PHP 5.3.0alpha1 (cli) (built: Sep 8 2008 13:16:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
(installed via MacPorts on 10.5.5)
Got:
Array
(
[d2] => hello
)
[2008-10-03 04:47:28] [EMAIL PROTECTED]
Ran it under:
PHP 5.3.0alpha3-dev (cli) (built: Oct 3 2008 00:09:28) (DEBUG)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
Got:
Array
(
[d2] => hello
)
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/ext/spl/spl_array.c(354) :
Freeing 0x00C1419C (20 bytes), script=-
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_execute.c(932) :
Freeing 0x00C142B8 (44 bytes), script=-
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_API.c(930) : Actual
location (location was relayed)
Last leak repeated 1 time
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_hash.c(247) : Freeing
0x00C14364 (38 bytes), script=-
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_execute.c(727) :
Freeing 0x00C143BC (20 bytes), script=-
[Fri Oct 3 00:19:06 2008] Script: '-'
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_variables.h(45) :
Freeing 0x00C14400 (6 bytes), script=-
/Users/gwynne/src/php-src/cvs/php-5.3/Zend/zend_variables.c(120) :
Actual location (location was relayed)
=== Total 6 memory leaks detected ===
[2008-10-03 03:57:49] [EMAIL PROTECTED]
Description:
ArrayObject appears to corrupt the symbol table
Checked it with Valgrind and didn't see anything, but haven't checked
the code yet. Appears to be a problem in both 5.2 and 5.3.
Reproduce code:
---
$test = new ArrayObject();
$test['d1']['d2'] = 'hello';
print_r($test3['m']);
Expected result:
nothing
Actual result:
--
Array
(
[d2] => hello
)
--
Edit this bug report at http://bugs.php.net/?id=46222&edit=1
#46127 [Opn]: [PATCH] php_openssl_tcp_sockop_accept forgets to set context on accepted stream
ID: 46127 User updated by: mark at hell dot ne dot jp -Summary: OpenSSL php_openssl_tcp_sockop_accept forgets to set context on accepted stream Reported By: mark at hell dot ne dot jp Status: Open Bug Type: OpenSSL related Operating System: Gentoo Linux PHP Version: 5.3.0alpha2 Assigned To: pajoye New Comment: (Adding [PATCH] tag to bug summary) Previous Comments: [2008-09-21 09:05:42] mark at hell dot ne dot jp This bug is fixed by the following patch. I found this out while reading the code and comparing the OpenSSL and non-OpenSSL versions of the connection accept process. This one-line-patch shouldn't require that much testing, and fixes this problem. NB: Even if the reference to the context wasn't done, the context's refcount was increased, causing a minor memoryleak if on a ssl server stream, at least one connection was attempted (and failed). Fix: http://ookoo.org/svn/snip/ssl_test/ssl_fix_5.3.0alpha2.diff [2008-09-19 15:50:36] mark at hell dot ne dot jp Description: A SSL socket created with stream_socket_server() isn't able to accept any connection. It returns an SSL_R_NO_SHARED_CIPHER error, as if the context wasn't passed from the listener socket to the created socket in stream_socket_accept() This is causing me some problems as I'm writing an application which needs SSL sockets. Reproduce code: --- http://ookoo.org/svn/snip/ssl_test/ssl_test.php Expected result: Running on 5.2.6-pl6-gentoo Linux Memol.ooKoo.org 2.6.25-gentoo-r1-tux #1 SMP Sat Apr 19 21:17:22 CEST 2008 x86_64 Actual result: -- Running on 5.3.0alpha2 Warning: stream_socket_accept(): SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used. This could be because the server is missing an SSL certificate (local_cert context option) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): accept failed: Success in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14077410:SSL routines:func(119):reason(1040) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): unable to connect to ssl://127.0.0.1:21673 (Unknown error) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 -- Edit this bug report at http://bugs.php.net/?id=46127&edit=1
#46127 [Opn]: OpenSSL php_openssl_tcp_sockop_accept forgets to set context on accepted stream
ID: 46127 User updated by: mark at hell dot ne dot jp -Summary: Unable to create a SSL server using stream_socket_server Reported By: mark at hell dot ne dot jp Status: Open Bug Type: OpenSSL related Operating System: Gentoo Linux PHP Version: 5.3.0alpha2 New Comment: This bug is fixed by the following patch. I found this out while reading the code and comparing the OpenSSL and non-OpenSSL versions of the connection accept process. This one-line-patch shouldn't require that much testing, and fixes this problem. NB: Even if the reference to the context wasn't done, the context's refcount was increased, causing a minor memoryleak if on a ssl server stream, at least one connection was attempted (and failed). Fix: http://ookoo.org/svn/snip/ssl_test/ssl_fix_5.3.0alpha2.diff Previous Comments: [2008-09-19 15:50:36] mark at hell dot ne dot jp Description: A SSL socket created with stream_socket_server() isn't able to accept any connection. It returns an SSL_R_NO_SHARED_CIPHER error, as if the context wasn't passed from the listener socket to the created socket in stream_socket_accept() This is causing me some problems as I'm writing an application which needs SSL sockets. Reproduce code: --- http://ookoo.org/svn/snip/ssl_test/ssl_test.php Expected result: Running on 5.2.6-pl6-gentoo Linux Memol.ooKoo.org 2.6.25-gentoo-r1-tux #1 SMP Sat Apr 19 21:17:22 CEST 2008 x86_64 Actual result: -- Running on 5.3.0alpha2 Warning: stream_socket_accept(): SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used. This could be because the server is missing an SSL certificate (local_cert context option) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): accept failed: Success in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14077410:SSL routines:func(119):reason(1040) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): unable to connect to ssl://127.0.0.1:21673 (Unknown error) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 -- Edit this bug report at http://bugs.php.net/?id=46127&edit=1
#46127 [NEW]: Unable to create a SSL server using stream_socket_server
From: mark at hell dot ne dot jp Operating system: Gentoo Linux PHP version: 5.3.0alpha2 PHP Bug Type: OpenSSL related Bug description: Unable to create a SSL server using stream_socket_server Description: A SSL socket created with stream_socket_server() isn't able to accept any connection. It returns an SSL_R_NO_SHARED_CIPHER error, as if the context wasn't passed from the listener socket to the created socket in stream_socket_accept() This is causing me some problems as I'm writing an application which needs SSL sockets. Reproduce code: --- http://ookoo.org/svn/snip/ssl_test/ssl_test.php Expected result: Running on 5.2.6-pl6-gentoo Linux Memol.ooKoo.org 2.6.25-gentoo-r1-tux #1 SMP Sat Apr 19 21:17:22 CEST 2008 x86_64 Actual result: -- Running on 5.3.0alpha2 Warning: stream_socket_accept(): SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used. This could be because the server is missing an SSL certificate (local_cert context option) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): accept failed: Success in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14077410:SSL routines:func(119):reason(1040) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): unable to connect to ssl://127.0.0.1:21673 (Unknown error) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 -- Edit bug report at http://bugs.php.net/?id=46127&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46127&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46127&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46127&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46127&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46127&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46127&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46127&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46127&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46127&r=support Expected behavior:http://bugs.php.net/fix.php?id=46127&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46127&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46127&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46127&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46127&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46127&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46127&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46127&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46127&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46127&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46127&r=mysqlcfg
