Bug #54959 [Opn->Bgs]: Report One Bug For 08 And 09 Numbers In functions
Edit report at http://bugs.php.net/bug.php?id=54959&edit=1 ID: 54959 Updated by: scott...@php.net Reported by:farszabanan at yahoo dot com Summary:Report One Bug For 08 And 09 Numbers In functions -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: All PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Numbers beginning with a 0 are octal numbers. Previous Comments: [2011-05-31 07:32:52] farszabanan at yahoo dot com Description: Test script: --- Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/bug.php?id=54959&edit=1
[PHP-BUG] Bug #54959 [NEW]: Report One Bug For 08 And 09 Numbers In functions
From: Operating system: All PHP version: 5.3.6 Package: *General Issues Bug Type: Bug Bug description:Report One Bug For 08 And 09 Numbers In functions Description: Test script: --- Expected result: Actual result: -- -- Edit bug report at http://bugs.php.net/bug.php?id=54959&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54959&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54959&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54959&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54959&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54959&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54959&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54959&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54959&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54959&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54959&r=support Expected behavior: http://bugs.php.net/fix.php?id=54959&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54959&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54959&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54959&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54959&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54959&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54959&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54959&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54959&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54959&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54959&r=mysqlcfg
Bug #54832 [Opn->Ctl]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832&edit=1 ID: 54832 Updated by: paj...@php.net Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql -Status: Open +Status: Critical Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N New Comment: Pls check this one as well, regression introduced by the browswer fix (wondering what can cause that in mysql/socket code.) Previous Comments: [2011-05-31 02:21:07] neweracracker at gmail dot com Yes. I can reproduce the problem. I am sure devs will fix then when they have time available. [2011-05-30 21:28:38] giorgio dot liscio at email dot it can you reproduce the problem? [2011-05-30 17:19:09] neweracracker at gmail dot com Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revision&revision=310691 Thank you. [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) 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=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832&edit=1
Bug #54896 [Opn->Ctl]: Connection to localhost doesn't work in Apache SAPI but works in CLI and CGI
Edit report at http://bugs.php.net/bug.php?id=54896&edit=1 ID: 54896 Updated by: paj...@php.net Reported by:neweracracker at gmail dot com Summary:Connection to localhost doesn't work in Apache SAPI but works in CLI and CGI -Status: Open +Status: Critical Type: Bug Package:Streams related Operating System: Windows 7 PHP Version:5.3SVN-2011-05-20 (snap) -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N New Comment: Gustavo, pls check this out as well. Previous Comments: [2011-05-24 18:31:40] neweracracker at gmail dot com This bug seems to be a consequence of bug #54918 It works flawless prior to this commit svn.php.net/viewvc?view=revision&revision=310691 [2011-05-21 00:55:40] neweracracker at gmail dot com Description: I have downloaded a snapshot of php 5.3.7 (Revision: 311276) from windows.php.net/snapshots/ and I am using php.ini-production as my php.ini file IPv6 is enabled in my machine. Using Apache and running the test script I got "bool(false)" Using nginx (with php fastcgi) and running the test script I got "resource(1) of type (stream)" Running php from the cmd line and running the test script I got "resource(4) of type (stream)" I think it is supposed to work with all situations. Please attempt to reproduce and fix this bug. Thank you. Test script: --- -- Edit this bug report at http://bugs.php.net/bug.php?id=54896&edit=1
Bug #54832 [Com]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832&edit=1 ID: 54832 Comment by: neweracracker at gmail dot com Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: Yes. I can reproduce the problem. I am sure devs will fix then when they have time available. Previous Comments: [2011-05-30 21:28:38] giorgio dot liscio at email dot it can you reproduce the problem? [2011-05-30 17:19:09] neweracracker at gmail dot com Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revision&revision=310691 Thank you. [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) [2011-05-26 14:57:27] giorgio dot liscio at email dot it hi johannes, i tested with every combination, including firewall issues but updating php latest revisions i noticed that not always driver throws that error sometimes on a just ran server (or thread?) some queries work, and sometimes when i F5 my browser the same queries continue to work, but if i hold down f5 for a lot of continuous reloads the error HY000/2002 is thrown hope this helps to fix the bug 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=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832&edit=1
Bug #51176 [Com]: Static calling in non-static method behaves like $this->
Edit report at http://bugs.php.net/bug.php?id=51176&edit=1 ID: 51176 Comment by: david71rj at gmail dot com Reported by:majkl578 at gmail dot com Summary:Static calling in non-static method behaves like $this-> Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:5.3.2RC3 Assigned To:felipe Block user comment: N Private report: N New Comment: Sorry by realive this topic, but I really think that it is a bug. If I want call "bar" with context, the correct mean is $this->bar(). Else, the "static" sounds for me like "call without context". I'm wrong? Please, read this topic to understand what I'm saying: http://stackoverflow.com/questions/6181603/php-is-handling-incorrectly-my-static- call Previous Comments: [2010-11-03 12:03:17] majkl578 at gmail dot com You cannot call foo::start(), because the method is non-static and therefore it does not make sense. Also, self, static and class name are used to call methods statically, not in a object context. For calling method bar in object context, I think '$this->' should be used instead. Obviously parent should not behave this way and respect context, but I think it should be the only exception (as shown in #52713). [2010-11-03 02:45:23] fel...@php.net Hello, I've reverted the wrong changes introduced by trying to fix the issue reported, but actually there is no bug at all. self::bar(), static::bar() and foo::bar() are being called in an object context, hence the __call() is called. I.e. $foo->start(); // invoke the __call method foo::start(); // invoke the __callStatic method Thanks. [2010-11-03 02:35:28] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=305043 Log: - Reverted fix for bug #51176 [2010-03-04 14:27:55] fel...@php.net Hello! This isn't my decision, but the release manager. Thanks. [2010-03-04 12:33:59] majkl578 at gmail dot com Can you explain me, please, why this is not fixed in 5.3.2 stable? "Thank you for the report, and for helping us make PHP better." You are intentionally making PHP worse! 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=51176 -- Edit this bug report at http://bugs.php.net/bug.php?id=51176&edit=1
Bug #54957 [Opn->Asn]: Memleak in alloc_globals_ctor
Edit report at http://bugs.php.net/bug.php?id=54957&edit=1 ID: 54957 Updated by: fel...@php.net Reported by:fel...@php.net Summary:Memleak in alloc_globals_ctor -Status: Open +Status: Assigned Type: Bug Package:Scripting Engine problem -PHP Version:trunk-SVN-2011-05-30 (SVN) +PHP Version:5.4, trunk -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2011-05-31 01:56:03] fel...@php.net Description: A memory leak happens when using ZTS+USE_ZEND_ALLOC=0 Test script: --- $ USE_ZEND_ALLOC=0 valgrind --tool=memcheck --leak-check=yes sapi/cli/php -v ==17712== Memcheck, a memory error detector ==17712== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17712== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==17712== Command: sapi/cli/php -v ==17712== PHP 5.5.0-dev (cli) (built: May 30 2011 18:37:59) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies ==17712== ==17712== HEAP SUMMARY: ==17712== in use at exit: 604 bytes in 1 blocks ==17712== total heap usage: 19,354 allocs, 19,353 frees, 1,466,000 bytes allocated ==17712== ==17712== 604 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==17712==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==17712==by 0x8429867: alloc_globals_ctor (zend_alloc.c:2633) ==17712==by 0x83C103F: ts_allocate_id (TSRM.c:255) ==17712==by 0x8429917: start_memory_manager (zend_alloc.c:2654) ==17712==by 0x845D1A4: zend_startup (zend.c:642) ==17712==by 0x83C893A: php_module_startup (main.c:1901) ==17712==by 0x85A479B: php_cli_startup (php_cli.c:414) ==17712==by 0x85A567B: main (php_cli.c:790) ==17712== ==17712== LEAK SUMMARY: ==17712==definitely lost: 604 bytes in 1 blocks ==17712==indirectly lost: 0 bytes in 0 blocks ==17712== possibly lost: 0 bytes in 0 blocks ==17712==still reachable: 0 bytes in 0 blocks ==17712== suppressed: 0 bytes in 0 blocks ==17712== ==17712== For counts of detected and suppressed errors, rerun with: -v ==17712== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 9) -- Edit this bug report at http://bugs.php.net/bug.php?id=54957&edit=1
[PHP-BUG] Bug #54957 [NEW]: Memleak in alloc_globals_ctor
From: felipe Operating system: PHP version: trunk-SVN-2011-05-30 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Memleak in alloc_globals_ctor Description: A memory leak happens when using ZTS+USE_ZEND_ALLOC=0 Test script: --- $ USE_ZEND_ALLOC=0 valgrind --tool=memcheck --leak-check=yes sapi/cli/php -v ==17712== Memcheck, a memory error detector ==17712== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17712== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==17712== Command: sapi/cli/php -v ==17712== PHP 5.5.0-dev (cli) (built: May 30 2011 18:37:59) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies ==17712== ==17712== HEAP SUMMARY: ==17712== in use at exit: 604 bytes in 1 blocks ==17712== total heap usage: 19,354 allocs, 19,353 frees, 1,466,000 bytes allocated ==17712== ==17712== 604 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==17712==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==17712==by 0x8429867: alloc_globals_ctor (zend_alloc.c:2633) ==17712==by 0x83C103F: ts_allocate_id (TSRM.c:255) ==17712==by 0x8429917: start_memory_manager (zend_alloc.c:2654) ==17712==by 0x845D1A4: zend_startup (zend.c:642) ==17712==by 0x83C893A: php_module_startup (main.c:1901) ==17712==by 0x85A479B: php_cli_startup (php_cli.c:414) ==17712==by 0x85A567B: main (php_cli.c:790) ==17712== ==17712== LEAK SUMMARY: ==17712==definitely lost: 604 bytes in 1 blocks ==17712==indirectly lost: 0 bytes in 0 blocks ==17712== possibly lost: 0 bytes in 0 blocks ==17712==still reachable: 0 bytes in 0 blocks ==17712== suppressed: 0 bytes in 0 blocks ==17712== ==17712== For counts of detected and suppressed errors, rerun with: -v ==17712== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 9) -- Edit bug report at http://bugs.php.net/bug.php?id=54957&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54957&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54957&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54957&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54957&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54957&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54957&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54957&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54957&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54957&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54957&r=support Expected behavior: http://bugs.php.net/fix.php?id=54957&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54957&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54957&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54957&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54957&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54957&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54957&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54957&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54957&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54957&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54957&r=mysqlcfg
Bug #44780 [Com]: some time zone offsets not recognized by timezone_name_from_abbr
Edit report at http://bugs.php.net/bug.php?id=44780&edit=1 ID: 44780 Comment by: theogaden at gmail dot com Reported by:shawn dot parker at alttech dot com Summary:some time zone offsets not recognized by timezone_name_from_abbr Status: Assigned Type: Bug Package:Date/time related Operating System: * PHP Version:5CVS-2008-08-14 Assigned To:derick Block user comment: N Private report: N New Comment: I have the exact same problem and I found this bug entry thanks to someone at stackoverflow. Here was my original question: http://stackoverflow.com/questions/6180892/why-does-timezone-name-from-abbr- return-an-empty-string Test Code -- $offset = -10; //UM10 echo timezone_name_from_abbr('', $offset * 3600, true); //empty string Expected Result -- Pacific/Honolulu Actual result: -- false I am using PHP 5.3.0. Previous Comments: [2009-05-08 18:23:40] mfburdett at gmail dot com I was able to resolve this by changing the fallbackmap from hours to minutes (the bug is apparently due to some issue with float vs. integer). Also, this patch adds Caracas and Shanghai time (there are likely other missing time zones, however) and uses the new spelling for Calcutta (Kolkata). Index: ext/date/lib/fallbackmap.h === RCS file: /repository/php-src/ext/date/lib/fallbackmap.h,v retrieving revision 1.3 diff -u -p -r1.3 fallbackmap.h --- ext/date/lib/fallbackmap.h 15 Oct 2005 18:14:40 - 1.3 +++ ext/date/lib/fallbackmap.h 8 May 2009 18:18:32 - @@ -1,40 +1,42 @@ - { "sst", 0, -11, "Pacific/Apia" }, - { "hst", 0, -10, "Pacific/Honolulu" }, - { "akst", 0, -9, "America/Anchorage" }, - { "akdt", 1, -8, "America/Anchorage" }, - { "pst", 0, -8, "America/Los_Angeles" }, - { "pdt", 1, -7, "America/Los_Angeles" }, - { "mst", 0, -7, "America/Denver" }, - { "mdt", 1, -6, "America/Denver" }, - { "cst", 0, -6, "America/Chicago" }, - { "cdt", 1, -5, "America/Chicago" }, - { "est", 0, -5, "America/New_York" }, - { "edt", 1, -4, "America/New_York" }, - { "ast", 0, -4, "America/Halifax" }, - { "adt", 1, -3, "America/Halifax" }, - { "brt", 0, -3, "America/Sao_Paulo" }, - { "brst", 1, -2, "America/Sao_Paulo" }, - { "azost", 0, -1, "Atlantic/Azores" }, - { "azodt", 1,0, "Atlantic/Azores" }, - { "gmt", 0,0, "Europe/London" }, - { "bst", 1,1, "Europe/London" }, - { "cet", 0,1, "Europe/Paris" }, - { "cest", 1,2, "Europe/Paris" }, - { "eet", 0,2, "Europe/Helsinki" }, - { "eest", 1,3, "Europe/Helsinki" }, - { "msk", 0,3, "Europe/Moscow" }, - { "msd", 1,4, "Europe/Moscow" }, - { "gst", 0,4, "Asia/Dubai" }, - { "pkt", 0,5, "Asia/Karachi" }, - { "ist", 0, 5.5, "Asia/Calcutta" }, - { "npt", 0, 5.75, "Asia/Katmandu" }, - { "yekt", 1,6, "Asia/Yekaterinburg" }, - { "novst", 1,7, "Asia/Novosibirsk" }, - { "krat", 0,7, "Asia/Krasnoyarsk" }, - { "krast", 1,8, "Asia/Krasnoyarsk" }, - { "jst", 0,9, "Asia/Tokyo" }, - { "est", 0, 10, "Australia/Melbourne" }, - { "cst", 1, 10.5, "Australia/Adelaide" }, - { "est", 1, 11, "Australia/Melbourne" }, - { "nzst", 0, 12, "Pacific/Auckland" }, - { "nzdt", 1, 13, "Pacific/Auckland" }, + { "sst", 0, -660, "Pacific/Apia" }, + { "hst", 0, -600, "Pacific/Honolulu" }, + { "akst", 0, -540, "America/Anchorage" }, + { "akdt", 1, -480, "America/Anchorage" }, + { "pst", 0, -480, "America/Los_Angeles" }, + { "pdt", 1, -420, "America/Los_Angeles" }, + { "mst", 0, -420, "America/Denver" }, + { "mdt", 1, -360, "America/Denver" }, + { "cst", 0, -360, "America/Chicago" }, + { "cdt", 1, -300, "America/Chicago" }, + { "est", 0, -300, "America/New_York" }, + { "vet", 0, -270, "America/Caracas" }, + { "edt", 1, -240, "America/New_York" }, + { "ast", 0, -240, "America/Halifax" }, + { "adt", 1, -180, "America/Halifax" }, + { "brt", 0, -180, "America/Sao_Paulo" }, + { "brst", 1, -120, "America/Sao_Paulo" }, + { "azost", 0, -60, "Atlantic/Azores" }, + { "azodt", 1,0, "Atlantic/Azores" }, + { "gmt", 0,0, "Europe/London" }, + { "bst", 1, 60, "Europe/London" }, + { "cet", 0,
[PHP-BUG] Bug #54955 [NEW]: FastCGI doesn't recognize Windows relative paths
From: Operating system: Windows 7 64bits SP1 PHP version: 5.3.6 Package: CGI related Bug Type: Bug Bug description:FastCGI doesn't recognize Windows relative paths Description: I have configured my webserver (nginx) to have its document root out of its working path in "..\files" (please, note the two dots). When I request static files, it serves them without any problem. Anyway If I request a PHP file, the request it's not served because php-cgi.exe running as the fastCGI server al 127.0.0.1:9000 returns an error 400 code. If I user absolute paths it works. Also, if I move the "..\files" folder to "./files" (please, note the only one dot) and I change the document root to reflect that new relative path. So It looks that relative paths with two dots are not getting resolved by php- cgi.exe as fastCGI server. -- Edit bug report at http://bugs.php.net/bug.php?id=54955&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54955&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54955&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54955&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54955&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54955&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54955&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54955&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54955&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54955&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54955&r=support Expected behavior: http://bugs.php.net/fix.php?id=54955&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54955&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54955&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54955&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54955&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54955&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54955&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54955&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54955&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54955&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54955&r=mysqlcfg
Bug #54832 [Com]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832&edit=1 ID: 54832 Comment by: giorgio dot liscio at email dot it Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: can you reproduce the problem? Previous Comments: [2011-05-30 17:19:09] neweracracker at gmail dot com Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revision&revision=310691 Thank you. [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) [2011-05-26 14:57:27] giorgio dot liscio at email dot it hi johannes, i tested with every combination, including firewall issues but updating php latest revisions i noticed that not always driver throws that error sometimes on a just ran server (or thread?) some queries work, and sometimes when i F5 my browser the same queries continue to work, but if i hold down f5 for a lot of continuous reloads the error HY000/2002 is thrown hope this helps to fix the bug [2011-05-26 14:50:06] johan...@php.net This works on other systems quite well. Are you sure you have no firewall or such? Pleas etry using 127.0.0.1 instead of localhost (there had been issues due to Ipv6 vs. IPv4 in the past) 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=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832&edit=1
Bug #54710 [Opn->Bgs]: sys_get_temp_dir() does not respect upload_tmp_dir
Edit report at http://bugs.php.net/bug.php?id=54710&edit=1 ID: 54710 Updated by: il...@php.net Reported by:royanee at yahoo dot com Summary:sys_get_temp_dir() does not respect upload_tmp_dir -Status: Open +Status: Bogus Type: Bug Package:PHP options/info functions PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The function is designed to return the location of the temporary directory, not the file upload directory. Previous Comments: [2011-05-11 15:47:13] royanee at yahoo dot com Additionally, enabling open_basedir results in FALSE and triggers the following warning: PHP Warning: tempnam(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/www/myvhost/) [2011-05-11 15:45:07] royanee at yahoo dot com Description: The only configuration option for setting the temporary directory for normal operations is the upload_tmp_dir option. As such, functions that rely on the temporary directory should respect the upload_tmp_dir option to ensure that true separation of concerns between virtual hosts can be achieved. This is particularly important when also using open_basedir. Note that the following line is correctly located in the vhost config: php_admin_value upload_tmp_dir "/www/myvhost/tmp" Test script: --- Expected result: /www/myvhost/tmp/TuxDRhRIg Actual result: -- /tmp/TuxDRhRIg -- Edit this bug report at http://bugs.php.net/bug.php?id=54710&edit=1
Bug #52496 [Opn->Csd]: Zero exit code on option parsing failure
Edit report at http://bugs.php.net/bug.php?id=52496&edit=1 ID: 52496 Updated by: il...@php.net Reported by:php-bugs at thequod dot de Summary:Zero exit code on option parsing failure -Status: Open +Status: Closed Type: Bug Package:CGI related Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-05-30 17:57:53] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=311600 Log: Fixed bug #52496 (Zero exit code on option parsing failure). [2010-07-30 08:36:00] php-bugs at thequod dot de Description: When PHP's option parsing fails, PHP outputs the "Usage" info, but exits with exit code 0, which means "success". So, given any PHP script where the options in the shebang line are wrong, or only considered wrong (like with bug 52495), will never execute, but always report success! Please fix this, so that option parsing will return a non-exit error code. Test script: --- # php --wrong-option ; echo $? Expected result: # php --wrong-option ; echo $? Usage: php [options] [-f] [--] [args...] [...] 1 Actual result: -- # php --wrong-option ; echo $? Usage: php [options] [-f] [--] [args...] [...] 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=52496&edit=1
Bug #54832 [Com]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832&edit=1 ID: 54832 Comment by: neweracracker at gmail dot com Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revision&revision=310691 Thank you. Previous Comments: [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) [2011-05-26 14:57:27] giorgio dot liscio at email dot it hi johannes, i tested with every combination, including firewall issues but updating php latest revisions i noticed that not always driver throws that error sometimes on a just ran server (or thread?) some queries work, and sometimes when i F5 my browser the same queries continue to work, but if i hold down f5 for a lot of continuous reloads the error HY000/2002 is thrown hope this helps to fix the bug [2011-05-26 14:50:06] johan...@php.net This works on other systems quite well. Are you sure you have no firewall or such? Pleas etry using 127.0.0.1 instead of localhost (there had been issues due to Ipv6 vs. IPv4 in the past) [2011-05-21 21:33:41] giorgio dot liscio at email dot it same error on latest 5.4 revision too May 21 2011 20:50:15 i'm using the binaries of windows.php.net http://windows.php.net/downloads/snaps/php-5.4/r311300/ 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=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832&edit=1
Bug #40048 [Com]: SQL IN (...) and = ANY (...) not supported by PDO
Edit report at http://bugs.php.net/bug.php?id=40048&edit=1 ID: 40048 Comment by: ggrraay at gmail dot com Reported by:bugs dot php dot net at andrewprendergast dot com Summary:SQL IN (...) and = ANY (...) not supported by PDO Status: Bogus Type: Bug Package:PDO related Operating System: Linux Red Hat EL PHP Version:5.2.1RC2 Block user comment: N Private report: N New Comment: >PDO does not implement query parsing it is entirely up to the database. Query parsing not needed, it can be done this way $stmt = $dbh->prepare("SELECT * FROM table WHERE id IN(:ids)"); $sth->bindValue(':ids', array(1,2,3), PDO::PARAM_ARRAY); If specified PDO::PARAM_ARRAY in bindValue method query can be parsed as this SELECT * FROM table WHERE id IN(1,2,3) not as SELECT * FROM table WHERE id IN('1,2,3') >The solution is to re-write queries to use IN (?, ?, �) It will not work if parameters array has variable length Previous Comments: [2007-01-08 00:23:49] bugs dot php dot net at andrewprendergast dot com Just to re-iterate some comments made about this on IRC: again PDO is not design to "modify" or extend SQL query language about definition, PDO is "only" a wrapper not an abstraction layer, it does not abstract anything (besides Specifically PDO does not do any parsing of SQL queries, it just passes them directly to the database engine in question so PDO is unable to re-write the SQL to support this feature. The solution is to re-write queries to use IN (?, ?, ) [2007-01-07 23:46:51] nlop...@php.net I also came across this problem last week: it would be could if we could bind an array to IN(). Probably it would be too dificult, but we could support this syntax in our sql re2c lexer.. [2007-01-07 17:44:11] il...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. PDO does not implement query parsing it is entirely up to the database. So the features you are talking about would only work if supported by the underlying database. [2007-01-07 13:35:55] bugs dot php dot net at andrewprendergast dot com Description: PDO doesn't allow one to SELECT or DELETE groups of records based on their primary key. Specifically, the SQL clauses WHERE ... IN (...) and WHERE ... = ANY (...) does not work for more than one record. As a workaround I can construct an SQL query and execute it myself but that defeats the niceness of PDO. Reproduce code: --- the following should return the records with ID 1 & 2: $dbh = new PDO('mysql:host=localhost;dbname=mobop', "root", ""); $stmt = $dbh->prepare("SELECT * FROM news_item WHERE news_item_id IN(?)"); if ( $stmt->execute(array("1, 2")) ) while ( ($row = $stmt->fetch()) ) print_r($row); But it doesn't. The following execute statement fails as well: $stmt->execute(array(array(2,1))) NB: The intention of the 2nd example is that when binding an array, it seems natural that PDO would assume its part of an IN or =ANY clause and convert it into a bunch of comma separated keys automagically. Some of the higher level PDO based O/R abstractions currently bouncing around like Doctrine would then be able to support (without any modificaiton) queries that affect multiple records. Expected result: Two records should be loaded. Actual result: -- One record is loaded. -- Edit this bug report at http://bugs.php.net/bug.php?id=40048&edit=1
Bug #54953 [Opn]: Implemented SPL Interfaces wont work on mapped classes
Edit report at http://bugs.php.net/bug.php?id=54953&edit=1 ID: 54953 User updated by:willem dot stuursma at hyves dot nl Reported by:willem dot stuursma at hyves dot nl -Summary:Implements SPL Interfaces wont work on mapped classes +Summary:Implemented SPL Interfaces wont work on mapped classes Status: Open Type: Bug Package:SOAP related Operating System: n/a PHP Version:5.3.6 Block user comment: N Private report: N New Comment: (corrected typo in bug title) Previous Comments: [2011-05-30 14:44:28] willem dot stuursma at hyves dot nl Description: If you implement the Iterator interface on one of the classes that you use in the classmap that you pass to SoapClient::SoapClient(), it does not work. If you use foreach() on the object that implements the interface it just iterates of the properties of the object instead of using the custom iterator you implemented. Test script: --- Not a full working code since this requires a SOAP service, but this gives you the gist: class Bar implements Iterator { /*...*/ } $bar = $soapClient->someFunc() // say this is an object returned by a SOAP client call and was mapped to class Bar foreach ($bar as $key => $value) { // Just iterates over each property } $baz = new Bar(); foreach ($baz as $key => $value) { // Works as expected } Expected result: I expect the custom iterator to be used when I iterator over an object returned by the SOAPClient. Actual result: -- Custom iterator is ignored, I get just regular iteration over all properties of the class Bar. -- Edit this bug report at http://bugs.php.net/bug.php?id=54953&edit=1
[PHP-BUG] Bug #54953 [NEW]: Implements SPL Interfaces wont work on mapped classes
From: Operating system: n/a PHP version: 5.3.6 Package: SOAP related Bug Type: Bug Bug description:Implements SPL Interfaces wont work on mapped classes Description: If you implement the Iterator interface on one of the classes that you use in the classmap that you pass to SoapClient::SoapClient(), it does not work. If you use foreach() on the object that implements the interface it just iterates of the properties of the object instead of using the custom iterator you implemented. Test script: --- Not a full working code since this requires a SOAP service, but this gives you the gist: class Bar implements Iterator { /*...*/ } $bar = $soapClient->someFunc() // say this is an object returned by a SOAP client call and was mapped to class Bar foreach ($bar as $key => $value) { // Just iterates over each property } $baz = new Bar(); foreach ($baz as $key => $value) { // Works as expected } Expected result: I expect the custom iterator to be used when I iterator over an object returned by the SOAPClient. Actual result: -- Custom iterator is ignored, I get just regular iteration over all properties of the class Bar. -- Edit bug report at http://bugs.php.net/bug.php?id=54953&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54953&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54953&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54953&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54953&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54953&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54953&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54953&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54953&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54953&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54953&r=support Expected behavior: http://bugs.php.net/fix.php?id=54953&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54953&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54953&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54953&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54953&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54953&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54953&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54953&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54953&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54953&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54953&r=mysqlcfg
Bug #54952 [Opn->Bgs]: Finfo invalid mime type detect for webm format
Edit report at http://bugs.php.net/bug.php?id=54952&edit=1 ID: 54952 Updated by: il...@php.net Reported by:daniel at bojdo dot eu Summary:Finfo invalid mime type detect for webm format -Status: Open +Status: Bogus Type: Bug Package:Filesystem function related Operating System: Debian 6 32bit PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The issue is with the libmagic library which is the one responsible for file type detection. Previous Comments: [2011-05-30 11:05:45] daniel at bojdo dot eu Description: Finfo extention detects invalid mime type for webm video format. "application/octet-stream; charset=binary" instead of "video/webm" Test script: --- file('MyVideo.webm',FILEINFO_MIME); // outputs "application/octet-stream; charset=binary" but should be "video/webm" Expected result: video/webm Actual result: -- application/octet-stream; charset=binary -- Edit this bug report at http://bugs.php.net/bug.php?id=54952&edit=1
[PHP-BUG] Bug #54952 [NEW]: Finfo invalid mime type detect for webm format
From: Operating system: Debian 6 32bit PHP version: 5.3.6 Package: Filesystem function related Bug Type: Bug Bug description:Finfo invalid mime type detect for webm format Description: Finfo extention detects invalid mime type for webm video format. "application/octet-stream; charset=binary" instead of "video/webm" Test script: --- file('MyVideo.webm',FILEINFO_MIME); // outputs "application/octet-stream; charset=binary" but should be "video/webm" Expected result: video/webm Actual result: -- application/octet-stream; charset=binary -- Edit bug report at http://bugs.php.net/bug.php?id=54952&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54952&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54952&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54952&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54952&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54952&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54952&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54952&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54952&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54952&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54952&r=support Expected behavior: http://bugs.php.net/fix.php?id=54952&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54952&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54952&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54952&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54952&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54952&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54952&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54952&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54952&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54952&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54952&r=mysqlcfg
Bug #54947 [Opn->Bgs]: ssh2.sftp protocol wrapper works incorrectly for paths which contain a '#'
Edit report at http://bugs.php.net/bug.php?id=54947&edit=1 ID: 54947 Updated by: paj...@php.net Reported by:josvanbakel at gmail dot com Summary:ssh2.sftp protocol wrapper works incorrectly for paths which contain a '#' -Status: Open +Status: Bogus Type: Bug Package:*Network Functions Operating System: Ubuntu PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Please report ssh2 bugs to pecl.php.net/ssh2. Also it could be a problem in libssh2 itself, I will have to check. Previous Comments: [2011-05-29 19:59:34] josvanbakel at gmail dot com Thanks for the tip. I'll give it a try. [2011-05-29 16:53:37] zelnaga at gmail dot com You'd probably have more success with phpseclib, a pure PHP SFTP implementation: http://phpseclib.sourceforge.net/ Doesn't absolve the maintainer of the php_ssh2.dll from fixing this bug but it's a work around you can none-the-less use until the problem is fixed. [2011-05-28 15:42:31] josvanbakel at gmail dot com Description: When trying to read a file or directory via the ssh2.sftp protocol wrapper which contains a '#' in the path ssh2.sftp will ignore it. It looks like it treats the '#' as a start comment command (e.g. // in PHP) In the test script, i have used the following directory structure: #Test/ a Test#/ b Test/ c Note that creating the directories from the bash shell requires escaping the # with a \, e.g.: mkdir \#Test Test script: --- // $sftp is a ssh2_sftp resource // $dir is the directory containing the test directory structure (see description) $root = "ssh2.sftp://$sftp/$dir";; $a = scandir("$root/#Test"); // $a = array(".", "..", "#Test", "Test#", "Test"); // Note that $a is a dir listing of $root, everything after the # is ignored $b = scandir("$root/Test#"); // $b = array(".", "..", "c"); // Gives a listing of Test not of Test# Expected result: $a = array(".", "..", "a"); $b = array(".", "..", "b"); Actual result: -- $a = array(".", "..", "#Test", "Test#", "Test"); $b = array(".", "..", "c"); -- Edit this bug report at http://bugs.php.net/bug.php?id=54947&edit=1