Bug #60879 [Asn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1 ID: 60879 User updated by:thijsputman at gmail dot com Reported by:thijsputman at gmail dot com Summary:unserialize() Does not invoke __wakeup() on object Status: Assigned Type: Bug Package:Class/Object related Operating System: Windows 7 PHP Version:5.4.0RC6 Assigned To:szarkos Block user comment: N Private report: N New Comment: The RC8 build provided fixes the issue in my environment. Thanks for the quick follow up! Previous Comments: [2012-02-17 18:05:35] szar...@php.net Thank you for reporting this! It appears to be related to the PGO build, however we've been using PGO since RC3, so it looks like this popped up in the RC6+ builds. Can you please test this build of RC8 and let me know if it fixes the issue in your environment: http://windows.php.net/downloads/snaps/ostc/build/php-5.4.0-RC8-1/php-5.4.0RC8-nts-Win32-VC9-x86.zip The configure line was fixed earlier (was also in some 5.3 snaps), good catch. It does not appear to be related to this issue, however. [2012-02-10 22:43:56] johan...@php.net Steve, I can't verify the report on Linux and don't see a related code-change. As I don't have a proper Windows environment at hand: From the report the user gave it seems like the compiler would do some over-optimistic optimization, can you take a look into this? Also please mind the notes on the other small issues in the configure lines. [2012-02-08 14:02:24] thijsputman at gmail dot com The configure commands between RC7-dev (which works properly) and RC7 (which exhibits the problem) seem to differ a bit, could that be the cause? RC7 contains the following elements not contained in RC7-dev: --disable-nsapi --with-enchant=shared --disable-static-analyze --with-pgo RC7-dev contains the following not contained in RC7: --enable-object-out-dir=d:/temp/obj/nts-windows-vc9-x86 Also, there seems to be a small typo in the RC7-dev configure command: --enable-snapshot-build --disable-zts --disable-isapi --enable-debug-pack --disable-isapi ISAPI is disabled twice (I'm guessing the second one should be nsapi?) [2012-02-08 13:46:27] thijsputman at gmail dot com Just tried with RC7 (VC9 x86 Non Thread Safe - 2012-Feb-06 23:40:37) and the problem has reappeared... [2012-02-06 13:44:29] yoozer at gmail dot com I've just tested the official release of RC7; it still exhibits this issue with exactly the same testcase. 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 https://bugs.php.net/bug.php?id=60879 -- Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
Bug #60879 [Csd-Asn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1
ID: 60879
User updated by:thijsputman at gmail dot com
Reported by:thijsputman at gmail dot com
Summary:unserialize() Does not invoke __wakeup() on object
-Status: Closed
+Status: Assigned
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.4.0RC6
Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
Just tried with RC7 (VC9 x86 Non Thread Safe - 2012-Feb-06 23:40:37) and the
problem has reappeared...
Previous Comments:
[2012-02-06 13:44:29] yoozer at gmail dot com
I've just tested the official release of RC7; it still exhibits this issue with
exactly the same testcase.
[2012-01-26 11:33:25] johan...@php.net
So let's assume this was fixed. I can't see a relevant change for this, though.
There will be another RC soon, an you check that, too, to be safe? Thanks :-)
[2012-01-26 10:56:17] thijsputman at gmail dot com
Just tried with revision 322785 and it indeed works as expected.
To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe,
2012-Jan-19 23:40:07) from the QA website and in that release the problem does
exist.
[2012-01-26 10:14:20] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works for me with latest svn. Do you have any special extension loaded or some
special configuration?
[2012-01-25 13:24:57] thijsputman at gmail dot com
Description:
When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but unserialize()
does *not* invoke the __wakeup() method.
Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which did
not exhibit this problem. See the below test script for an example (which works
as expected in RC5, but not in RC6).
Test script:
---
class Woei{
public function __sleep(){
echo 'sleep' . PHP_EOL;
return array();
}
public function __wakeup(){
echo 'wakeup' . PHP_EOL;
}
}
$Woei = new Woei();
$s1 = serialize($Woei);
$Woei2 = unserialize($s1);
$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);
Expected result:
sleep
wakeup
sleep
wakeup
Actual result:
--
sleep
sleep
--
Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
Bug #60879 [Asn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1 ID: 60879 User updated by:thijsputman at gmail dot com Reported by:thijsputman at gmail dot com Summary:unserialize() Does not invoke __wakeup() on object Status: Assigned Type: Bug Package:Class/Object related Operating System: Windows 7 PHP Version:5.4.0RC6 Assigned To:johannes Block user comment: N Private report: N New Comment: The configure commands between RC7-dev (which works properly) and RC7 (which exhibits the problem) seem to differ a bit, could that be the cause? RC7 contains the following elements not contained in RC7-dev: --disable-nsapi --with-enchant=shared --disable-static-analyze --with-pgo RC7-dev contains the following not contained in RC7: --enable-object-out-dir=d:/temp/obj/nts-windows-vc9-x86 Also, there seems to be a small typo in the RC7-dev configure command: --enable-snapshot-build --disable-zts --disable-isapi --enable-debug-pack --disable-isapi ISAPI is disabled twice (I'm guessing the second one should be nsapi?) Previous Comments: [2012-02-08 13:46:27] thijsputman at gmail dot com Just tried with RC7 (VC9 x86 Non Thread Safe - 2012-Feb-06 23:40:37) and the problem has reappeared... [2012-02-06 13:44:29] yoozer at gmail dot com I've just tested the official release of RC7; it still exhibits this issue with exactly the same testcase. [2012-01-26 11:33:25] johan...@php.net So let's assume this was fixed. I can't see a relevant change for this, though. There will be another RC soon, an you check that, too, to be safe? Thanks :-) [2012-01-26 10:56:17] thijsputman at gmail dot com Just tried with revision 322785 and it indeed works as expected. To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe, 2012-Jan-19 23:40:07) from the QA website and in that release the problem does exist. [2012-01-26 10:14:20] johan...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works for me with latest svn. Do you have any special extension loaded or some special configuration? 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 https://bugs.php.net/bug.php?id=60879 -- Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
Bug #60879 [Fbk-Opn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1
ID: 60879
User updated by:thijsputman at gmail dot com
Reported by:thijsputman at gmail dot com
Summary:unserialize() Does not invoke __wakeup() on object
-Status: Feedback
+Status: Open
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
Just tried with revision 322785 and it indeed works as expected.
To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe,
2012-Jan-19 23:40:07) from the QA website and in that release the problem does
exist.
Previous Comments:
[2012-01-26 10:14:20] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works for me with latest svn. Do you have any special extension loaded or some
special configuration?
[2012-01-25 13:24:57] thijsputman at gmail dot com
Description:
When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but unserialize()
does *not* invoke the __wakeup() method.
Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which did
not exhibit this problem. See the below test script for an example (which works
as expected in RC5, but not in RC6).
Test script:
---
class Woei{
public function __sleep(){
echo 'sleep' . PHP_EOL;
return array();
}
public function __wakeup(){
echo 'wakeup' . PHP_EOL;
}
}
$Woei = new Woei();
$s1 = serialize($Woei);
$Woei2 = unserialize($s1);
$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);
Expected result:
sleep
wakeup
sleep
wakeup
Actual result:
--
sleep
sleep
--
Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
[PHP-BUG] Bug #60879 [NEW]: unserialize() Does not invoke __wakeup() on object
From:
Operating system: Windows 7
PHP version: 5.4.0RC6
Package: Class/Object related
Bug Type: Bug
Bug description:unserialize() Does not invoke __wakeup() on object
Description:
When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but
unserialize() does *not* invoke the __wakeup() method.
Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which
did not exhibit this problem. See the below test script for an example
(which works as expected in RC5, but not in RC6).
Test script:
---
class Woei{
public function __sleep(){
echo 'sleep' . PHP_EOL;
return array();
}
public function __wakeup(){
echo 'wakeup' . PHP_EOL;
}
}
$Woei = new Woei();
$s1 = serialize($Woei);
$Woei2 = unserialize($s1);
$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);
Expected result:
sleep
wakeup
sleep
wakeup
Actual result:
--
sleep
sleep
--
Edit bug report at https://bugs.php.net/bug.php?id=60879edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60879r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60879r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60879r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60879r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60879r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60879r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60879r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60879r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60879r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60879r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60879r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60879r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60879r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60879r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60879r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60879r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60879r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60879r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60879r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60879r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60879r=mysqlcfg
[PHP-BUG] Bug #53619 [NEW]: ASSERT_BAIL seems to interfer with custom error-handling
From:
Operating system: Windows 7
PHP version: 5.3.4
Package: Scripting Engine problem
Bug Type: Bug
Bug description:ASSERT_BAIL seems to interfer with custom error-handling
Description:
I seem to have encountered an unexpected interaction between my custom
error-handling setup and enabling the ASSERT_BAIL option.
The (simplified) situation is as follows:
* A custom error_handler() is defined and it converts all non-fatal PHP
errors into ErrorException's.
* A custom assert_handler() is defined to display all failed assertions.
* The script in question has ASSERT_BAIL enabled and error reporting set to
E_ALL.
See the reproduce code for an example.
An assertion containing an E_NOTICE type error is constructed. When
executed under the above conditions, execution halts the moment
error_handler() throws its ErrorException.
When ASSERT_BAIL is disabled, the custom error_handler() throws its
ErrorException which is caught by PHP and results in a fatal error.
I would assume ASSERT_BAIL to only bail if/when the assertion gets the
chance to be handled. When the custom error_handler() is modified to _not_
throw an exception, but only provide some output, execution continues to
assert_handler() after which ASSERT_BAIL is respected.
The above behaviour is somewhat killing in situations where the actual
error_handler() does nothing but throw an exception and expects a further
custom exception-handler to pick up the pieces. The situation as sketched
above then simply generates no output.
Test script:
---
function error_handler($severity, $message, $file, $line){
echo Error: $message . PHP_EOL;
throw new ErrorException($message);
}
function assert_handler($file, $line, $expression){
echo Assertion failed: $expression . PHP_EOL;
}
set_error_handler('error_handler', E_ALL);
assert_options(ASSERT_CALLBACK, 'assert_handler');
assert_options(ASSERT_BAIL, true);
assert('$foo instanceof Bar');
echo '*Not executed*' . PHP_EOL;
Expected result:
Error: Undefined variable: foo
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: foo' in ...
Actual result:
--
Error: Undefined variable: foo
For further reference, here's what happens if error_handler() is modified
to _not_ throw an exception:
ASSERT_BAIL enabled:
Error: Undefined variable: foo (- error_handler())
Assertion failed: $foo instanceof Bar (- assert_handler())
Error: assert(): Assertion $foo instanceof Bar failed (-
ASSERT_WARNING)
ASSERT_BAIL disabled:
Error: Undefined variable: foo (- error_handler())
Assertion failed: $foo instanceof Bar (- assert_handler())
Error: assert(): Assertion $foo instanceof Bar failed (-
ASSERT_WARNING)
*Not executed* (- ASSERT_BAIL)
--
Edit bug report at http://bugs.php.net/bug.php?id=53619edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53619r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53619r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53619r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53619r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53619r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53619r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53619r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53619r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53619r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53619r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53619r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53619r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53619r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53619r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53619r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53619r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53619r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53619r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53619r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53619r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53619r=mysqlcfg
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079edit=1
ID: 51079
Comment by: thijsputman at gmail dot com
Reported by: tony at marston-home dot demon dot co dot uk
Summary: fsockopen will not work on 'localhost'
Status: Open
Type: Bug
Package: Sockets related
Operating System: win32 only - Windows XP
PHP Version: 5.2.12
New Comment:
I can confirm that the problem is not present in PHP 5.3.0, but _is_
present in PHP 5.3.2...
It appears the mysql(i) extension is suffering from the same issue: I
just spend a couple hours going through various versions of phpMyAdmin
(which after upgrading from 5.3.0 simply timed out with a blank page)
until discovering this issue. Changing localhost into 127.0.0.1 did
trick.
Tested using 5.3.2 (VC9 NTS) on Windows Server 2008 (x64). On a side
note, both Firefox and MS telnet don't have any issues connecting to
localhost over IPv4.
Previous Comments:
[2010-02-19 14:42:07] tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
I have tried 5.2.13RC2, but it produces the same error. I have not tried
5.3.2RC2 as I do not have an error with 5.3.0 (which may be because my
copy of 5.3.0 does not have IPv6 support enabled).
[2010-02-19 12:51:20] paj...@php.net
-Status: Bogus
+Status: Feedback
Have you tried with 5.2.13RC2 and 5.3.2RC2?
[2010-02-19 10:58:02] tony at marston-home dot demon dot co dot uk
Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested fix was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.
This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.
None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1
gethostbyname('localhost') returns '127.0.0.1' without any problem.
The CURL extension can send requests to 'localhost' without a problem.
I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.
So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?
Do NOT tell me that this is a Windows XP issue and that I should disable
IPv6 support. IPv4 and IPv6 are designed to run alongside each other and
are NOT mutually exclusive. The only function on my PC that has a
problem with that is fsockopen(), so stop procrastinating and FIX IT!
[2010-02-18 17:44:10] ras...@php.net
You are going to have to debug it yourself. Nobody has been able to
reproduce your problem and you are the only one who has reported it.
We can't fix something we can't see.
[2010-02-18 11:20:44] tony at marston-home dot demon dot co dot uk
The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say disable IPv6 support in your
operating system as the problem CLEARLY lies within the code for
fsockopen.
If IPv6 support is enabled in the operating system it does NOT mean that
only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
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=51079
--
Edit this bug report at http://bugs.php.net/bug.php?id=51079edit=1
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079edit=1
ID: 51079
Comment by: thijsputman at gmail dot com
Reported by: tony at marston-home dot demon dot co dot uk
Summary: fsockopen will not work on 'localhost'
Status: Open
Type: Bug
Package: Sockets related
Operating System: win32 only - Windows XP
PHP Version: 5.2.12
New Comment:
Agreed, but that's not my point:
Just like when using fsockopen() to connect to localhost, I would
expect mysql_connect(localhost) to also attempt to use IPv4,
irrespective of whether localhost resolves to [::1] or 127.0.0.1.
This is the same behaviour exhibited by Firefox on my system and
apparently also the behaviour of several other PHP functions, as made
clear in the initial post of this bug.
Previous Comments:
[2010-03-10 10:53:40] paj...@php.net
Mysql is not related to this problem, IPv6 is not supported and you have
to apply one of the solutions described here or one of the other
numerous reports about mysql and IPv6.
[2010-03-10 09:43:16] thijsputman at gmail dot com
I can confirm that the problem is not present in PHP 5.3.0, but _is_
present in PHP 5.3.2...
It appears the mysql(i) extension is suffering from the same issue: I
just spend a couple hours going through various versions of phpMyAdmin
(which after upgrading from 5.3.0 simply timed out with a blank page)
until discovering this issue. Changing localhost into 127.0.0.1 did
trick.
Tested using 5.3.2 (VC9 NTS) on Windows Server 2008 (x64). On a side
note, both Firefox and MS telnet don't have any issues connecting to
localhost over IPv4.
[2010-02-19 14:42:07] tony at marston-home dot demon dot co dot uk
-Status: Feedback
+Status: Open
I have tried 5.2.13RC2, but it produces the same error. I have not tried
5.3.2RC2 as I do not have an error with 5.3.0 (which may be because my
copy of 5.3.0 does not have IPv6 support enabled).
[2010-02-19 12:51:20] paj...@php.net
-Status: Bogus
+Status: Feedback
Have you tried with 5.2.13RC2 and 5.3.2RC2?
[2010-02-19 10:58:02] tony at marston-home dot demon dot co dot uk
Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested fix was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.
This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.
None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1
gethostbyname('localhost') returns '127.0.0.1' without any problem.
The CURL extension can send requests to 'localhost' without a problem.
I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.
So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?
Do NOT tell me that this is a Windows XP issue and that I should disable
IPv6 support. IPv4 and IPv6 are designed to run alongside each other and
are NOT mutually exclusive. The only function on my PC that has a
problem with that is fsockopen(), so stop procrastinating and FIX IT!
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=51079
--
Edit this bug report at http://bugs.php.net/bug.php?id=51079edit=1
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079edit=1 ID: 51079 Comment by: thijsputman at gmail dot com Reported by: tony at marston-home dot demon dot co dot uk Summary: fsockopen will not work on 'localhost' Status: Assigned Type: Bug Package: Sockets related Operating System: win32 only - Windows XP PHP Version: 5.2.12 Assigned To: pajoye New Comment: Fair enough :) The reproduce code provided fails to connect to localhost with fsockopen() in PHP 5.3.2. When using PHP 5.3.0 fsockopen() connects to localhost without problems. Previous Comments: [2010-03-10 12:03:59] paj...@php.net It does not depend on PHP only but libmysql or mysql server. Please keep posting about the socket issue only here as the myslqIPv6 questions have been covered numerous times in other reports. The one report per issue rule is also a good way to do not get distracted, thanks for your understanding :) [2010-03-10 11:38:07] thijsputman at gmail dot com Agreed, but that's not my point: Just like when using fsockopen() to connect to localhost, I would expect mysql_connect(localhost) to also attempt to use IPv4, irrespective of whether localhost resolves to [::1] or 127.0.0.1. This is the same behaviour exhibited by Firefox on my system and apparently also the behaviour of several other PHP functions, as made clear in the initial post of this bug. [2010-03-10 10:53:40] paj...@php.net Mysql is not related to this problem, IPv6 is not supported and you have to apply one of the solutions described here or one of the other numerous reports about mysql and IPv6. [2010-03-10 09:43:16] thijsputman at gmail dot com I can confirm that the problem is not present in PHP 5.3.0, but _is_ present in PHP 5.3.2... It appears the mysql(i) extension is suffering from the same issue: I just spend a couple hours going through various versions of phpMyAdmin (which after upgrading from 5.3.0 simply timed out with a blank page) until discovering this issue. Changing localhost into 127.0.0.1 did trick. Tested using 5.3.2 (VC9 NTS) on Windows Server 2008 (x64). On a side note, both Firefox and MS telnet don't have any issues connecting to localhost over IPv4. [2010-02-19 14:42:07] tony at marston-home dot demon dot co dot uk -Status: Feedback +Status: Open I have tried 5.2.13RC2, but it produces the same error. I have not tried 5.3.2RC2 as I do not have an error with 5.3.0 (which may be because my copy of 5.3.0 does not have IPv6 support enabled). 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=51079 -- Edit this bug report at http://bugs.php.net/bug.php?id=51079edit=1
