Bug #60879 [Asn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879&edit=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=60879&edit=1
Bug #60879 [Asn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879&edit=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=60879&edit=1
Bug #60879 [Csd->Asn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879&edit=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=60879&edit=1
Bug #60879 [Fbk->Opn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879&edit=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=60879&edit=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=60879&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60879&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60879&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60879&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60879&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60879&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60879&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60879&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60879&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60879&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60879&r=support Expected behavior: https://bugs.php.net/fix.php?id=60879&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60879&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60879&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60879&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60879&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60879&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60879&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60879&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60879&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60879&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60879&r=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=53619&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53619&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53619&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53619&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53619&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53619&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53619&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53619&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53619&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53619&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53619&r=support Expected behavior: http://bugs.php.net/fix.php?id=53619&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53619&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53619&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53619&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53619&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53619&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53619&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53619&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53619&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53619&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53619&r=mysqlcfg
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079&edit=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 myslq&IPv6 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=51079&edit=1
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079&edit=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=51079&edit=1
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079&edit=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=51079&edit=1