Bug #60473 [Com]: Built-in server randomly closes connections
Edit report at https://bugs.php.net/bug.php?id=60473&edit=1 ID: 60473 Comment by: lolautruche at gmail dot com Reported by:lolautruche at gmail dot com Summary:Built-in server randomly closes connections Status: Feedback Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Hi No, I mean that there is no response at all. The browser opens the connection and the built-in server closes it "unexpectedly" Previous Comments: [2011-12-09 05:45:56] larue...@php.net Hi, what do you mean by "connection closed"? 500 error? [2011-12-08 16:22:22] lolautruche at gmail dot com Description: When using built-in server with a regular PHP application (eZ Publish in my case), and with many design ressources going through the server, it regularly fails to serve some ressources to the browser (randomly). I'm using a router with rewrite rules emulations (with regexp), so it might come from here, but there is no error logged anywhere :-( Please note that this has been tested with only one user. Test script: --- php -S localhost:8000 router.php My router script : https://gist.github.com/1447481 Expected result: All requested ressources should be served, or at least there should be an error message explaining why connection has been closed -- Edit this bug report at https://bugs.php.net/bug.php?id=60473&edit=1
[PHP-BUG] Req #60478 [NEW]: New unit tests
From: Operating system: PHP version: 5.4.0RC3 Package: Testing related Bug Type: Feature/Change Request Bug description:New unit tests Description: Here are some unit tests written during an event at my company. -- Edit bug report at https://bugs.php.net/bug.php?id=60478&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60478&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60478&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60478&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60478&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60478&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60478&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60478&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60478&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60478&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60478&r=support Expected behavior: https://bugs.php.net/fix.php?id=60478&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60478&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60478&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60478&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60478&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60478&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60478&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60478&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60478&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60478&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60478&r=mysqlcfg
Bug #60472 [Com]: PHP_SELF/SCRIPT_NAME wrongly defined in $_SERVER
Edit report at https://bugs.php.net/bug.php?id=60472&edit=1 ID: 60472 Comment by: lolautruche at gmail dot com Reported by:lolautruche at gmail dot com Summary:PHP_SELF/SCRIPT_NAME wrongly defined in $_SERVER Status: Feedback Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Block user comment: N Private report: N New Comment: Hi Indeed, it's a virtual folder. I was comparing built-in server behaviour with Apache HTTPD's. So I guess you'd suggest to alter those server variables in the router script ? Thanks Previous Comments: [2011-12-09 02:43:50] larue...@php.net is the hello/world is actually a existing folder under you doc root? I think it's no. so actullay the built-in server will find the index.php under the doc_root, this is a feature(for path_info), not a bug. [2011-12-08 16:11:51] lolautruche at gmail dot com Description: By design, if no PHP script is present in the REQUEST_URI, built-in server considers using a directory index (index.php or index.html). However, PHP_SELF and SCRIPT_NAME server variables are not correctly filled. For instance, if I test http://localhost:8000/hello/world, SCRIPT_NAME will be "/index.php" and PHP_SELF will be "/index.php/hello/world", while on Apache httpd, SCRIPT_NAME and PHP_SELF will be "/hello/world/index.php". Test script: --- php -S localhost:8000 router.php router.php script : Expected result: Directory index should be AFTER the dir path : "/hello/world/index.php" Actual result: -- Directory index is before the dir path : "/index.php/hello/world" -- Edit this bug report at https://bugs.php.net/bug.php?id=60472&edit=1
Req #60478 [Asn->Csd]: New unit tests
Edit report at https://bugs.php.net/bug.php?id=60478&edit=1 ID: 60478 Updated by: patrickalla...@php.net Reported by:jm at jmfontaine dot net Summary:New unit tests -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Testing related PHP Version:5.4.0RC3 Assigned To:patrickallaert Block user comment: N Private report: N New Comment: Thanks Jean-Marc for this contribution. This has been committed in SVN (trunk, PHP_5_4 and PHP_5_3): r320774, r320772 and r320771 Previous Comments: [2011-12-09 09:48:06] jm at jmfontaine dot net Description: Here are some unit tests written during an event at my company. -- Edit this bug report at https://bugs.php.net/bug.php?id=60478&edit=1
Bug #60472 [Fbk->Bgs]: PHP_SELF/SCRIPT_NAME wrongly defined in $_SERVER
Edit report at https://bugs.php.net/bug.php?id=60472&edit=1 ID: 60472 Updated by: larue...@php.net Reported by:lolautruche at gmail dot com Summary:PHP_SELF/SCRIPT_NAME wrongly defined in $_SERVER -Status: Feedback +Status: Bogus Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 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 this is not a bug, but a feature. thanks Previous Comments: [2011-12-09 10:26:36] lolautruche at gmail dot com Hi Indeed, it's a virtual folder. I was comparing built-in server behaviour with Apache HTTPD's. So I guess you'd suggest to alter those server variables in the router script ? Thanks [2011-12-09 02:43:50] larue...@php.net is the hello/world is actually a existing folder under you doc root? I think it's no. so actullay the built-in server will find the index.php under the doc_root, this is a feature(for path_info), not a bug. [2011-12-08 16:11:51] lolautruche at gmail dot com Description: By design, if no PHP script is present in the REQUEST_URI, built-in server considers using a directory index (index.php or index.html). However, PHP_SELF and SCRIPT_NAME server variables are not correctly filled. For instance, if I test http://localhost:8000/hello/world, SCRIPT_NAME will be "/index.php" and PHP_SELF will be "/index.php/hello/world", while on Apache httpd, SCRIPT_NAME and PHP_SELF will be "/hello/world/index.php". Test script: --- php -S localhost:8000 router.php router.php script : Expected result: Directory index should be AFTER the dir path : "/hello/world/index.php" Actual result: -- Directory index is before the dir path : "/index.php/hello/world" -- Edit this bug report at https://bugs.php.net/bug.php?id=60472&edit=1
Bug #60473 [Fbk]: Built-in server randomly closes connections
Edit report at https://bugs.php.net/bug.php?id=60473&edit=1 ID: 60473 Updated by: larue...@php.net Reported by:lolautruche at gmail dot com Summary:Built-in server randomly closes connections Status: Feedback Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Hi, if there is no any error message in log, then it must because you return false at your route script if the script_name is not valid. you can try print something just above the last "return false" statement. thanks Previous Comments: [2011-12-09 09:09:44] lolautruche at gmail dot com Hi No, I mean that there is no response at all. The browser opens the connection and the built-in server closes it "unexpectedly" [2011-12-09 05:45:56] larue...@php.net Hi, what do you mean by "connection closed"? 500 error? [2011-12-08 16:22:22] lolautruche at gmail dot com Description: When using built-in server with a regular PHP application (eZ Publish in my case), and with many design ressources going through the server, it regularly fails to serve some ressources to the browser (randomly). I'm using a router with rewrite rules emulations (with regexp), so it might come from here, but there is no error logged anywhere :-( Please note that this has been tested with only one user. Test script: --- php -S localhost:8000 router.php My router script : https://gist.github.com/1447481 Expected result: All requested ressources should be served, or at least there should be an error message explaining why connection has been closed -- Edit this bug report at https://bugs.php.net/bug.php?id=60473&edit=1
Bug #60473 [Fbk->Asn]: Built-in server randomly closes connections
Edit report at https://bugs.php.net/bug.php?id=60473&edit=1 ID: 60473 User updated by:lolautruche at gmail dot com Reported by:lolautruche at gmail dot com Summary:Built-in server randomly closes connections -Status: Feedback +Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Hi Unfortunately, trying to print something doesn't help since PHP webserver doesn't serve the ressource. Trying to call error_log() before returning false doesn't seem to help either. How can SCRIPT_NAME be invalid ? Thanks Previous Comments: [2011-12-09 13:11:39] larue...@php.net Hi, if there is no any error message in log, then it must because you return false at your route script if the script_name is not valid. you can try print something just above the last "return false" statement. thanks [2011-12-09 09:09:44] lolautruche at gmail dot com Hi No, I mean that there is no response at all. The browser opens the connection and the built-in server closes it "unexpectedly" [2011-12-09 05:45:56] larue...@php.net Hi, what do you mean by "connection closed"? 500 error? [2011-12-08 16:22:22] lolautruche at gmail dot com Description: When using built-in server with a regular PHP application (eZ Publish in my case), and with many design ressources going through the server, it regularly fails to serve some ressources to the browser (randomly). I'm using a router with rewrite rules emulations (with regexp), so it might come from here, but there is no error logged anywhere :-( Please note that this has been tested with only one user. Test script: --- php -S localhost:8000 router.php My router script : https://gist.github.com/1447481 Expected result: All requested ressources should be served, or at least there should be an error message explaining why connection has been closed -- Edit this bug report at https://bugs.php.net/bug.php?id=60473&edit=1
[PHP-BUG] Bug #60480 [NEW]: SERVER_ADDR should be present in server variables
From: Operating system: PHP version: 5.4.0RC3 Package: Built-in web server Bug Type: Bug Bug description:SERVER_ADDR should be present in server variables Description: Hi Currently, SERVER_ADDR is absent from server variables, so that it needs to be defined in a router script. IMHO this variable should be available out-of-the- box. Thanks ! -- Edit bug report at https://bugs.php.net/bug.php?id=60480&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60480&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60480&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60480&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60480&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60480&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60480&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60480&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60480&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60480&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60480&r=support Expected behavior: https://bugs.php.net/fix.php?id=60480&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60480&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60480&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60480&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60480&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60480&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60480&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60480&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60480&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60480&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60480&r=mysqlcfg
Bug #60471 [Com]: Random "Invalid request (unexpected EOF)" using a router script
Edit report at https://bugs.php.net/bug.php?id=60471&edit=1 ID: 60471 Comment by: patrickalla...@php.net Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: @laruence: Gentoo Linux Most of the time, several of those messages appears in one block like in: [Thu Dec 8 13:39:29 2011] 127.0.0.1:50358 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50359 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50360 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50361 Invalid request (Unexpected EOF) [Thu Dec 8 13:39:29 2011] 127.0.0.1:50362 Invalid request (Unexpected EOF) I expect it comes from the fact that the page generated by the built-in server contains references to pictures, js and css files that has been downloaded by chrome through the built-in server. Does chrome do some special treatment? Can't reproduce with a dummy page with just an Hello World. Previous Comments: [2011-12-09 05:44:26] larue...@php.net I can't reproduce this on Linux. @patrickallaert, what is your OS? [2011-12-08 16:24:27] patrickalla...@php.net I can confirm those messages. It looks like it happens only with Chrome/Chromium. Debugging at the TCP level shows that it comes from empty messages: TCP messages corresponding to port 41767 that generated the error message: [Thu Dec 8 16:48:33 2011] 127.0.0.1:41767 Invalid request (Unexpected EOF) appears below, as captured by Wireshark. No. TimeSourceDestination Protocol Length Info 1214 196.678104 127.0.0.1 127.0.0.1 TCP 74 41767 > http-alt [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=209439162 TSecr=0 WS=128 Frame 1214: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Arrival Time: Dec 8, 2011 16:48:22.673873000 CET Epoch Time: 1323359302.673873000 seconds [Time delta from previous captured frame: 9.255505000 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 196.678104000 seconds] Frame Number: 1214 Frame Length: 74 bytes (592 bits) Capture Length: 74 bytes (592 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:tcp] [Coloring Rule Name: TCP SYN/FIN] [Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 00.. = Differentiated Services Codepoint: Default (0x00) ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 60 Identification: 0x6b16 (27414) Flags: 0x02 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0xd1a3 [correct] [Good: True] [Bad: False] Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) Transmission Control Protocol, Src Port: 41767 (41767), Dst Port: http-alt (8080), Seq: 0, Len: 0 Source port: 41767 (41767) Destination port: http-alt (8080) [Stream index: 78] Sequence number: 0(relative sequence number) Header length: 40 bytes Flags: 0x02 (SYN) 000. = Reserved: Not set ...0 = Nonce: Not set 0... = Congestion Window Reduced (CWR): Not set .0.. = ECN-Echo: Not set ..0. = Urgent: Not set ...0
Bug #60473 [Asn]: Built-in server randomly closes connections
Edit report at https://bugs.php.net/bug.php?id=60473&edit=1 ID: 60473 Updated by: larue...@php.net Reported by:lolautruche at gmail dot com Summary:Built-in server randomly closes connections Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: sorry, I mis-understand your router, but I can't reproduce this with the router you gived... can you make a deep search, to find a 100% reproduce-able way? Previous Comments: [2011-12-09 13:35:24] lolautruche at gmail dot com Hi Unfortunately, trying to print something doesn't help since PHP webserver doesn't serve the ressource. Trying to call error_log() before returning false doesn't seem to help either. How can SCRIPT_NAME be invalid ? Thanks [2011-12-09 13:11:39] larue...@php.net Hi, if there is no any error message in log, then it must because you return false at your route script if the script_name is not valid. you can try print something just above the last "return false" statement. thanks [2011-12-09 09:09:44] lolautruche at gmail dot com Hi No, I mean that there is no response at all. The browser opens the connection and the built-in server closes it "unexpectedly" [2011-12-09 05:45:56] larue...@php.net Hi, what do you mean by "connection closed"? 500 error? [2011-12-08 16:22:22] lolautruche at gmail dot com Description: When using built-in server with a regular PHP application (eZ Publish in my case), and with many design ressources going through the server, it regularly fails to serve some ressources to the browser (randomly). I'm using a router with rewrite rules emulations (with regexp), so it might come from here, but there is no error logged anywhere :-( Please note that this has been tested with only one user. Test script: --- php -S localhost:8000 router.php My router script : https://gist.github.com/1447481 Expected result: All requested ressources should be served, or at least there should be an error message explaining why connection has been closed -- Edit this bug report at https://bugs.php.net/bug.php?id=60473&edit=1
Bug #60467 [Opn]: About 107 auto test [phpt script] failed .
Edit report at https://bugs.php.net/bug.php?id=60467&edit=1 ID: 60467 Updated by: dani...@php.net Reported by:Jtang at suse dot com Summary:About 107 auto test [phpt script] failed . Status: Open Type: Bug Package:Testing related Operating System: SLES 11 SP2 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I'll deal with the ext/date/tests portions in the near future. Previous Comments: [2011-12-08 03:34:59] Jtang at suse dot com Description: I use the phpt file from php 5.3 tarball package for automation test. 11338 test file , 107 failed , in 107 failed : # 33 test are expect as described in output # 9 test have bug NO. # 66 test is failed 66 test cases are: ./ext/calendar/tests/easter_date.phpt ./ext/calendar/tests/unixtojd.phpt ./ext/date/tests/DateTime_days-spring-type2-type2.phpt ./ext/date/tests/DateTime_days-spring-type2-type3.phpt ./ext/date/tests/DateTime_days-spring-type3-type2.phpt ./ext/date/tests/DateTime_days-spring-type3-type3.phpt ./ext/date/tests/DateTime_sub-dates.phpt ./ext/date/tests/DateTime_sub-february.phpt ./ext/date/tests/timezone_location_get.phpt ./ext/dom/tests/DOMDocument_relaxNGValidate_error2.phpt ./ext/dom/tests/DOMDocument_validate_on_parse_variation.phpt ./ext/gmp/tests/gmp_nextprime.phpt ./ext/intl/tests/resourcebundle_arrayaccess.phpt ./ext/intl/tests/resourcebundle_individual.phpt ./ext/intl/tests/resourcebundle_iterator.phpt ./ext/mysql/tests/001.phpt ./ext/mysql/tests/mysql_connect.phpt ./ext/mysql/tests/mysql_max_links.phpt ./ext/mysql/tests/mysql_sql_safe_mode.phpt ./ext/mysqli/tests/mysqli_connect.phpt ./ext/mysqli/tests/mysqli_connect_oo.phpt ./ext/mysqli/tests/mysqli_connect_oo_defaults.phpt ./ext/pcre/tests/006.phpt ./ext/pdo_mysql/tests/pdo_mysql___construct_options.phpt ./ext/pdo_mysql/tests/pdo_mysql_interface.phpt ./ext/posix/tests/posix_ttyname_error.phpt ./ext/posix/tests/posix_ttyname_variation1.phpt ./ext/posix/tests/posix_ttyname_variation2.phpt ./ext/posix/tests/posix_ttyname_variation3.phpt ./ext/posix/tests/posix_ttyname_variation4.phpt ./ext/posix/tests/posix_ttyname_variation5.phpt ./ext/posix/tests/posix_ttyname_variation6.phpt ./ext/posix/tests/posix_ttyname_variation7.phpt ./ext/session/tests/014.phpt ./ext/session/tests/015.phpt ./ext/session/tests/018.phpt ./ext/session/tests/020.phpt ./ext/session/tests/021.phpt ./ext/session/tests/session_id_variation2.phpt ./ext/sockets/tests/socket_strerror.phpt ./ext/spl/examples/tests/dualiterator_001.phpt ./ext/sqlite/tests/sqlite_session_001.phpt ./ext/sqlite/tests/sqlite_session_002.phpt ./ext/sqlite3/tests/sqlite3_prepare_001.phpt ./ext/standard/tests/class_object/is_a_error_001.phpt ./ext/standard/tests/class_object/is_subclass_of_error_001.phpt ./ext/standard/tests/general_functions/getservbyname_variation10.phpt ./ext/standard/tests/general_functions/getservbyname_variation9.phpt ./ext/standard/tests/general_functions/getservbyport_variation1.phpt ./ext/standard/tests/general_functions/phpinfo.phpt ./ext/standard/tests/general_functions/proc_nice_variation5.phpt ./ext/standard/tests/misc/time_sleep_until_basic.phpt ./ext/standard/tests/php_ini_loaded_file.phpt ./ext/standard/tests/strings/htmlentities02.phpt ./ext/standard/tests/strings/htmlentities04.phpt ./ext/standard/tests/strings/htmlentities10.phpt ./ext/standard/tests/strings/htmlentities11.phpt ./ext/standard/tests/strings/htmlentities13.phpt ./ext/standard/tests/strings/htmlentities15.phpt ./ext/standard/tests/strings/setlocale_variation2.phpt ./ext/xsl/tests/xslt010.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcnostring.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcundef.phpt ./sapi/cli/tests/001.phpt ./sapi/cli/tests/015.phpt Test script: --- only one line script env TEST_PHP_EXECUTABLE=/usr/bin/php REPORT_EXIT_STATUS=1 TEST_PHP_SRCDIR=/usr/share/qa/qa_test_php53 TEST_PHP_DETAILED=1 NO_INTERACTION=1 /usr/bin/php -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/share/qa/qa_test_php53/run-tests.php [phpt.file] Expected result: 65 test cases should pass? Actual result: -- 65 test cases failed -- Edit this bug report at https://bugs.php.net/bug.php?id=60467&edit=1
Bug #60473 [Asn]: Built-in server randomly closes connections
Edit report at https://bugs.php.net/bug.php?id=60473&edit=1 ID: 60473 User updated by:lolautruche at gmail dot com Reported by:lolautruche at gmail dot com Summary:Built-in server randomly closes connections Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: OK, I'll dig. But another info: this happens regardless there is a router script or not. An HTTP trace example : Method: GET Protocol-Version: HTTP/1.1 Protocol: http Host: ezpublish.dev Port: 8000 File: /design/admin2/stylesheets/theme/modalwindow.css Remote-Address: 127.0.0.1 Client-Address: 127.0.0.1 Start-Time: 2011-12-09T15:10:43.625+01:00 Request-Time: 2011-12-09T15:10:43.629+01:00 Response-Time: 2011-12-09T15:10:43.707+01:00 End-Time: 2011-12-09T15:10:43.710+01:00 Request-Header-Size: 643 Response-Header-Size: 126 Request-Body-Size: 0 Response-Body-Size: 2137 Request-Body-Decoded: false Response-Body-Decoded: false Request-Header:<<--EOF-1323439906166- GET /design/admin2/stylesheets/theme/modalwindow.css HTTP/1.1 Host: ezpublish.dev:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 Accept: text/css,*/*;q=0.1 Referer: http://ezpublish.dev:8000/plain_site_admin/content/view/full/2 Accept-Encoding: gzip,deflate,sdch Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: adminNavigationTab=view; contentStructureMenu=5/2/43; eZSESSIDa8f71cffda7ca9763445db0b3afb4957=93vhe4inndpt5ghahfjcuofpc6; is_logged_in=true; XDEBUG_SESSION=netbeans-xdebug --EOF-1323439906166- Response-Header:<<--EOF-1323439906166- HTTP/1.1 200 OK Host: ezpublish.dev:8000 Connection: closed Content-Type: text/css; charset=UTF-8 Content-Length: 2137 --EOF-1323439906166- Previous Comments: [2011-12-09 13:59:51] larue...@php.net sorry, I mis-understand your router, but I can't reproduce this with the router you gived... can you make a deep search, to find a 100% reproduce-able way? [2011-12-09 13:35:24] lolautruche at gmail dot com Hi Unfortunately, trying to print something doesn't help since PHP webserver doesn't serve the ressource. Trying to call error_log() before returning false doesn't seem to help either. How can SCRIPT_NAME be invalid ? Thanks [2011-12-09 13:11:39] larue...@php.net Hi, if there is no any error message in log, then it must because you return false at your route script if the script_name is not valid. you can try print something just above the last "return false" statement. thanks [2011-12-09 09:09:44] lolautruche at gmail dot com Hi No, I mean that there is no response at all. The browser opens the connection and the built-in server closes it "unexpectedly" [2011-12-09 05:45:56] larue...@php.net Hi, what do you mean by "connection closed"? 500 error? 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=60473 -- Edit this bug report at https://bugs.php.net/bug.php?id=60473&edit=1
[PHP-BUG] Bug #60481 [NEW]: Can't send cookies when retrieving WSDL with SoapClient
From:
Operating system: n/a
PHP version: 5.3.8
Package: SOAP related
Bug Type: Bug
Bug description:Can't send cookies when retrieving WSDL with SoapClient
Description:
When you construct a SoapClient it immediatly fetches the WSDL, before you
have the chance to set cookies. Our setup requires some cookie to be sent
when fetching the WSDL which is currently impossible.
It should be possible to give cookies to the SoapClient constructor which
should be sent along with the request for the WSDL.
Test script:
---
$soap = new SoapClient('http://webservice/wsdl', array('username' => 'x',
'password' => 'y'));
$soap->__setCookie('extra_thing', 'z');
--
Edit bug report at https://bugs.php.net/bug.php?id=60481&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60481&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60481&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60481&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60481&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60481&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60481&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60481&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60481&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60481&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60481&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60481&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60481&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60481&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60481&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60481&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60481&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60481&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60481&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60481&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60481&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60481&r=mysqlcfg
Bug #60473 [Asn]: Built-in server randomly closes connections
Edit report at https://bugs.php.net/bug.php?id=60473&edit=1 ID: 60473 User updated by:lolautruche at gmail dot com Reported by:lolautruche at gmail dot com Summary:Built-in server randomly closes connections Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Dear Laruence Please note that I'm using the webserver from a browser (tested with Firefox & Chrome), with ~60 ressources loaded from the main generated HTML code (images, css, js...) Previous Comments: [2011-12-09 14:14:53] lolautruche at gmail dot com OK, I'll dig. But another info: this happens regardless there is a router script or not. An HTTP trace example : Method: GET Protocol-Version: HTTP/1.1 Protocol: http Host: ezpublish.dev Port: 8000 File: /design/admin2/stylesheets/theme/modalwindow.css Remote-Address: 127.0.0.1 Client-Address: 127.0.0.1 Start-Time: 2011-12-09T15:10:43.625+01:00 Request-Time: 2011-12-09T15:10:43.629+01:00 Response-Time: 2011-12-09T15:10:43.707+01:00 End-Time: 2011-12-09T15:10:43.710+01:00 Request-Header-Size: 643 Response-Header-Size: 126 Request-Body-Size: 0 Response-Body-Size: 2137 Request-Body-Decoded: false Response-Body-Decoded: false Request-Header:<<--EOF-1323439906166- GET /design/admin2/stylesheets/theme/modalwindow.css HTTP/1.1 Host: ezpublish.dev:8000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 Accept: text/css,*/*;q=0.1 Referer: http://ezpublish.dev:8000/plain_site_admin/content/view/full/2 Accept-Encoding: gzip,deflate,sdch Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: adminNavigationTab=view; contentStructureMenu=5/2/43; eZSESSIDa8f71cffda7ca9763445db0b3afb4957=93vhe4inndpt5ghahfjcuofpc6; is_logged_in=true; XDEBUG_SESSION=netbeans-xdebug --EOF-1323439906166- Response-Header:<<--EOF-1323439906166- HTTP/1.1 200 OK Host: ezpublish.dev:8000 Connection: closed Content-Type: text/css; charset=UTF-8 Content-Length: 2137 --EOF-1323439906166- [2011-12-09 13:59:51] larue...@php.net sorry, I mis-understand your router, but I can't reproduce this with the router you gived... can you make a deep search, to find a 100% reproduce-able way? [2011-12-09 13:35:24] lolautruche at gmail dot com Hi Unfortunately, trying to print something doesn't help since PHP webserver doesn't serve the ressource. Trying to call error_log() before returning false doesn't seem to help either. How can SCRIPT_NAME be invalid ? Thanks [2011-12-09 13:11:39] larue...@php.net Hi, if there is no any error message in log, then it must because you return false at your route script if the script_name is not valid. you can try print something just above the last "return false" statement. thanks [2011-12-09 09:09:44] lolautruche at gmail dot com Hi No, I mean that there is no response at all. The browser opens the connection and the built-in server closes it "unexpectedly" 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=60473 -- Edit this bug report at https://bugs.php.net/bug.php?id=60473&edit=1
[PHP-BUG] Req #60482 [NEW]: Add cookies to stream_context
From: Operating system: n/a PHP version: Irrelevant Package: Streams related Bug Type: Feature/Change Request Bug description:Add cookies to stream_context Description: I think cookies would be a usable addition to the possibilities of stream-context's. -- Edit bug report at https://bugs.php.net/bug.php?id=60482&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60482&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60482&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60482&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60482&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60482&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60482&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60482&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60482&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60482&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60482&r=support Expected behavior: https://bugs.php.net/fix.php?id=60482&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60482&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60482&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60482&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60482&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60482&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60482&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60482&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60482&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60482&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60482&r=mysqlcfg
Bug #60481 [Com]: Can't send cookies when retrieving WSDL with SoapClient
Edit report at https://bugs.php.net/bug.php?id=60481&edit=1
ID: 60481
Comment by: jille at hexon dot cx
Reported by:jille at hexon dot cx
Summary:Can't send cookies when retrieving WSDL with
SoapClient
Status: Open
Type: Bug
Package:SOAP related
Operating System: n/a
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
We could also add cookies to stream-contexts (proposed it in
https://bugs.php.net/bug.php?id=60482)
Previous Comments:
[2011-12-09 14:38:30] jille at hexon dot cx
Description:
When you construct a SoapClient it immediatly fetches the WSDL, before you have
the chance to set cookies. Our setup requires some cookie to be sent when
fetching the WSDL which is currently impossible.
It should be possible to give cookies to the SoapClient constructor which
should be sent along with the request for the WSDL.
Test script:
---
$soap = new SoapClient('http://webservice/wsdl', array('username' => 'x',
'password' => 'y'));
$soap->__setCookie('extra_thing', 'z');
--
Edit this bug report at https://bugs.php.net/bug.php?id=60481&edit=1
[PHP-BUG] Bug #60483 [NEW]: stream_select only selects STDIN if present in read array
From: Operating system: Linux/Debian x64 PHP version: 5.3.8 Package: Streams related Bug Type: Bug Bug description:stream_select only selects STDIN if present in read array Description: I'm writing a data multiplexer PHP CLI script that takes data from STDIN and dispatchs those data on programs opened with proc_open(). I'm using stream_select() to see which descriptor has data. The read array I'm using contains STDIN and the output streams from programs opened with proc_open() (the classic $pipes[1] from proc_open() descriptorspec). Those programs write on their stdout as soon as there is data on their stdin (actually those programs are PHP scripts echoing input). If STDIN remains in the read set, stream_select returns only STDIN as readable and never returns any of the programs output streams. As soon as STDIN is removed from the read set, stream_select behave normaly and selects the output streams that are ready. Expected result: I'm expecting all my ready streams to be returned, even if STDIN is present in the set. -- Edit bug report at https://bugs.php.net/bug.php?id=60483&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60483&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60483&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60483&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60483&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60483&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60483&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60483&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60483&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60483&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60483&r=support Expected behavior: https://bugs.php.net/fix.php?id=60483&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60483&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60483&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60483&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60483&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60483&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60483&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60483&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60483&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60483&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60483&r=mysqlcfg
[PHP-BUG] Req #60485 [NEW]: in_array insensitive string comparison
From:
Operating system: linux
PHP version: Irrelevant
Package: Arrays related
Bug Type: Feature/Change Request
Bug description:in_array insensitive string comparison
Description:
Can you please add parameter for in_array that let this function to compare
strings insensitive?
Test script:
---
// something like
in_array('a', Array('a', 'A'), true, true);
// 4th bool param says should the function compare string in a
case-sensitive manner or not
--
Edit bug report at https://bugs.php.net/bug.php?id=60485&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60485&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60485&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60485&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60485&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60485&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60485&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60485&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60485&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60485&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60485&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60485&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60485&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60485&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60485&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60485&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60485&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60485&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60485&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60485&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60485&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60485&r=mysqlcfg
[PHP-BUG] Req #60486 [NEW]: Add parameter to token_get_all for normalized output
From: nikic Operating system: PHP version: 5.4.0RC3 Package: *General Issues Bug Type: Feature/Change Request Bug description:Add parameter to token_get_all for normalized output Description: A all_tokens_as_arrays parameter should be added to token_get_all which would result in it returning a normalized output, i.e. return arrays for all tokens, including single char tokens. -- Edit bug report at https://bugs.php.net/bug.php?id=60486&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60486&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60486&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60486&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60486&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60486&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60486&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60486&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60486&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60486&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60486&r=support Expected behavior: https://bugs.php.net/fix.php?id=60486&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60486&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60486&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60486&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60486&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60486&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60486&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60486&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60486&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60486&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60486&r=mysqlcfg
Req #60486 [PATCH]: Add parameter to token_get_all for normalized output
Edit report at https://bugs.php.net/bug.php?id=60486&edit=1 ID: 60486 Patch added by: ni...@php.net Reported by:ni...@php.net Summary:Add parameter to token_get_all for normalized output Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.4.0RC3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: token_get_all.patch Revision: 1323450945 URL: https://bugs.php.net/patch-display.php?bug=60486&patch=token_get_all.patch&revision=1323450945 Previous Comments: [2011-12-09 17:13:10] ni...@php.net Description: A all_tokens_as_arrays parameter should be added to token_get_all which would result in it returning a normalized output, i.e. return arrays for all tokens, including single char tokens. -- Edit this bug report at https://bugs.php.net/bug.php?id=60486&edit=1
Bug #54708 [Com]: Fatal error by defined class with inheritance and wrong order and including
Edit report at https://bugs.php.net/bug.php?id=54708&edit=1 ID: 54708 Comment by: pov at fingerprint dot fr Reported by:interrobang at noicq dot org Summary:Fatal error by defined class with inheritance and wrong order and including Status: Open Type: Bug Package:Class/Object related Operating System: Debian Squeeze PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Other weird comportment with probably the same origin : Expected result : no error Actual result : "Cannot redeclare class SimpleFoo" Previous Comments: [2011-05-11 12:30:27] interrobang at noicq dot org Description: Script "test.php" produces Fatal error in relation of writing order of classes. If that missing class defined in same file, at the same place like require_once() (by replacing), no error will appear :O Test script: --- class file: test.class.php main file: test.php Expected result: nothing, blank screen. No "Fatal error" should be displayed. Actual result: -- Fatal error: Class 'formularAlpha' not found in test.php -- Edit this bug report at https://bugs.php.net/bug.php?id=54708&edit=1
Bug #45942 [Com]: D_FILE_OFFSET_BITS=64 causes PHP to run at half speed
Edit report at https://bugs.php.net/bug.php?id=45942&edit=1 ID: 45942 Comment by: jhuckaby at gmail dot com Reported by:jhuckaby at gmail dot com Summary:D_FILE_OFFSET_BITS=64 causes PHP to run at half speed Status: Closed Type: Bug Package:Performance problem Operating System: Fedora Core 6 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Just a follow-up note. I was wrong about closing the bug. This is still an open issue. When using AC_SYS_LARGEFILE, PHP still fails to write more than 2 GB to a file -- it just doesn't throw any kind of error. To this day, even with PHP 5.3.6, the only way to get true large file support seems to be adding the -D_FILE_OFFSET_BITS=64 compile flag, which still causes a 50% runtime performance penalty. Previous Comments: [2008-09-03 21:05:03] jhuckaby at gmail dot com This can be solved by using AC_SYS_LARGEFILE and a more modern operating system (tested with Mac OS X 10.5 and Fedora 9). Apparently Fedora Core 6 is too old to support the flag. I am closing this bug. [2008-08-29 21:30:35] jhuckaby at gmail dot com I should have also noted, this same error happens with 5.2.4 stable, 5.2.6 stable, and the CVS daily snapshot build for Aug 29, 2008. [2008-08-29 21:27:01] jhuckaby at gmail dot com Wait, I spoke too soon! Please don't close the bug yet. As soon as I removed the "--disable-all --disable-cgi" ./configure command-line options, I got this build error from the "make" step: /home/jhuckaby/dev/3rdparty/source/apache-1.3/php- 5.2.7/ext/posix/posix.c: In function 'zif_posix_uname': /home/jhuckaby/dev/3rdparty/source/apache-1.3/php- 5.2.7/ext/posix/posix.c:471: error: 'struct utsname' has no member named 'domainname' make: *** [ext/posix/posix.lo] Error 1 I didn't add any new command-line options, I simply removed the "-- disable-all --disable-cgi". ./configure --with-apache=../apache_1.3.39 --prefix=/ipix/php --with- config-file-path=/ipix/php/lib --disable-all --disable-cgi Any ideas? Should I file this under a separate bug? [2008-08-29 20:28:04] jhuckaby at gmail dot com Okay, I followed your instructions. I added AC_SYS_LARGEFILE to configure.in, then ran ./buildconf --force. Then I followed with ./configure..., make, and make install. I found the following output from ./configure of interest: checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... unknown checking for _LARGE_FILES value needed for large files... unknown Anyway, it compiled clean and installed. And it seems to work correctly, writing >2GB large files without error AND the interpreter speed is fast! Thanks! [root@dev-ops php-5.2.6]# /ipix/php/bin/php ~/benchmark.php CPU Benchmark: 310 [root@dev-ops php-5.2.6]# /ipix/php/bin/php ~/benchmark.php CPU Benchmark: 311 [root@dev-ops php-5.2.6]# /ipix/php/bin/php ~/benchmark.php CPU Benchmark: 312 [root@dev-ops php-5.2.6]# /ipix/php/bin/php ~/benchmark.php CPU Benchmark: 306 [root@dev-ops php-5.2.6]# /ipix/php/bin/php ~/benchmark.php CPU Benchmark: 311 I guess we can close this bug! [2008-08-29 19:03:20] crrodriguez at suse dot de You dont pass D_FILE_OFFSET_BITS=64 directly, but add AC_SYS_LARGEFILE to configure.in then run ./buildconf --force and rebuild PHP. BTW.. it is known that large file support may not work currenlty with PHP. 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=45942 -- Edit this bug report at https://bugs.php.net/bug.php?id=45942&edit=1
[PHP-BUG] Bug #60488 [NEW]: Simple Typo In php.ini Files
From: Operating system: N/A PHP version: 5.4SVN-2011-12-09 (SVN) Package: *Configuration Issues Bug Type: Bug Bug description:Simple Typo In php.ini Files Description: Noticed this while setting up a new box for a client this afternoon. Where it refers to freetds.comf, it should instead be freetds.conf. An interesting side- effect of this is seeing how many folks on the web have exposed php.ini files, purposely or otherwise. Diff attached. -- Edit bug report at https://bugs.php.net/bug.php?id=60488&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60488&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60488&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60488&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60488&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60488&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60488&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60488&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60488&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60488&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60488&r=support Expected behavior: https://bugs.php.net/fix.php?id=60488&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60488&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60488&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60488&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60488&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60488&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60488&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60488&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60488&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60488&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60488&r=mysqlcfg
[PHP-BUG] Bug #60489 [NEW]: Simple Typo In php.ini Files
From: danbrown Operating system: N/A PHP version: 5.4SVN-2011-12-09 (SVN) Package: *Configuration Issues Bug Type: Bug Bug description:Simple Typo In php.ini Files Description: Noticed this while setting up a new box for a client this afternoon. Where it refers to freetds.comf, it should instead be freetds.conf. An interesting side- effect of this is seeing how many folks on the web have exposed php.ini files, purposely or otherwise. -- Edit bug report at https://bugs.php.net/bug.php?id=60489&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60489&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60489&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60489&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60489&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60489&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60489&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60489&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60489&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60489&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60489&r=support Expected behavior: https://bugs.php.net/fix.php?id=60489&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60489&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60489&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60489&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60489&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60489&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60489&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60489&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60489&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60489&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60489&r=mysqlcfg
Bug #60488 [Opn->Dup]: Simple Typo In php.ini Files
Edit report at https://bugs.php.net/bug.php?id=60488&edit=1 ID: 60488 Updated by: danbr...@php.net Reported by:danbr...@php.net Summary:Simple Typo In php.ini Files -Status: Open +Status: Duplicate Type: Bug Package:*Configuration Issues Operating System: N/A PHP Version:5.4SVN-2011-12-09 (SVN) Block user comment: N Private report: N New Comment: Must've been a browser issue on my end. Duped as #60489, but this one doesn't contain the patch. Previous Comments: [2011-12-09 22:10:20] danbr...@php.net Description: Noticed this while setting up a new box for a client this afternoon. Where it refers to freetds.comf, it should instead be freetds.conf. An interesting side- effect of this is seeing how many folks on the web have exposed php.ini files, purposely or otherwise. Diff attached. -- Edit this bug report at https://bugs.php.net/bug.php?id=60488&edit=1
Bug #60489 [Opn->Csd]: Simple Typo In php.ini Files
Edit report at https://bugs.php.net/bug.php?id=60489&edit=1 ID: 60489 Updated by: fel...@php.net Reported by:danbr...@php.net Summary:Simple Typo In php.ini Files -Status: Open +Status: Closed Type: Bug Package:*Configuration Issues Operating System: N/A PHP Version:5.4SVN-2011-12-09 (SVN) -Assigned To: +Assigned To:felipe 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-12-09 22:13:05] danbr...@php.net Description: Noticed this while setting up a new box for a client this afternoon. Where it refers to freetds.comf, it should instead be freetds.conf. An interesting side- effect of this is seeing how many folks on the web have exposed php.ini files, purposely or otherwise. -- Edit this bug report at https://bugs.php.net/bug.php?id=60489&edit=1
Bug #50757 [Com]: PDO MYSQL issue with BIT data type not setting correct value
Edit report at https://bugs.php.net/bug.php?id=50757&edit=1
ID: 50757
Comment by: dipan9876 at hotmail dot com
Reported by:christian at activemediaworks dot com
Summary:PDO MYSQL issue with BIT data type not setting
correct value
Status: Bogus
Type: Bug
Package:PDO related
Operating System: MAC OSX 10.5.8
PHP Version:5.2.12
Block user comment: N
Private report: N
New Comment:
PDO is seriously crap. Having used .NET's beautiful ADO.Net, PDO almost feels
like
something thrown together by a college student. It's no wonder the community is
dropping PHP like a brick if this is the sort of developments being made these
days.
Previous Comments:
[2010-03-24 12:55:33] u...@php.net
No bug here. This is how crappy PDO works ever since. If you don't specify a
bind type, binding will use strings. Your code:
$stmt = $db->prepare("INSERT INTO mytable (mybit) VALUES (?)");
$stmt->execute(array(0));
... is equivalent to:
$stmt = $db->prepare("INSERT INTO mytable (mybit) VALUES ('0')");
$stmt->execute(array(0));
Which in turn inserts 1 into the BIT column.
[2010-01-14 20:22:48] christian at activemediaworks dot com
Description:
When trying to insert a row with a 0-value into a column of type BIT(1), if the
value for the column is not hard-coded into SQL statement, it causes the value
to be inserted to become 1. If it is hardcoded, it is okay.
Reproduce code:
---
/* This results in the value of the column being set to 1 (incorrect) */
$db = new PDO ( "mysql:dbname=db1234;host=localhost", "user1234", "pass1234" );
$stmt = $db->prepare("INSERT INTO mytable (mybit) VALUES (?)");
$stmt->execute(array(0));
db_disconnect($db);
/* This results in the value of the column being set to 0 (correct) */
$db = new PDO ( "mysql:dbname=db1234;host=localhost", "user1234", "pass1234" );
$stmt = $db->prepare("INSERT INTO mytable (mybit) VALUES (0)");
$stmt->execute();
db_disconnect($db);
Actual result:
--
The first example inserts a row with the column value set to 1 (wrong)
The second example inserts a row with the column value set to 0 (right)
--
Edit this bug report at https://bugs.php.net/bug.php?id=50757&edit=1
[PHP-BUG] Bug #60490 [NEW]: PHP 5.3.x will not compile gcc3.3.4
From: Operating system: Linux (Slackware 10) PHP version: 5.3.8 Package: *Compile Issues Bug Type: Bug Bug description:PHP 5.3.x will not compile gcc3.3.4 Description: Tried a few versions in the 5.3.x range but all fail on: dns.c resides in /php-5.3.8/ext/standard/ dns.c: In function `php_parserr': dns.c:453: error: case label does not reduce to an integer constant dns.c:459: error: case label does not reduce to an integer constant dns.c:464: error: case label does not reduce to an integer constant dns.c:465: warning: comparison between pointer and integer dns.c:469: error: case label does not reduce to an integer constant dns.c:470: warning: comparison between pointer and integer dns.c:474: error: case label does not reduce to an integer constant dns.c:475: warning: comparison between pointer and integer dns.c:485: error: case label does not reduce to an integer constant dns.c:497: error: case label does not reduce to an integer constant dns.c:521: error: case label does not reduce to an integer constant dns.c:546: error: case label does not reduce to an integer constant Also tried the 5.3.9rc All 5.2.x versions compiled fine On slackware 13.xx compilation goes fine. Issue appears by simply running ./configure and make (no extra options provided) -- Edit bug report at https://bugs.php.net/bug.php?id=60490&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60490&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60490&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60490&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60490&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60490&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60490&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60490&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60490&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60490&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60490&r=support Expected behavior: https://bugs.php.net/fix.php?id=60490&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60490&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60490&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60490&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60490&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60490&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60490&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60490&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60490&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60490&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60490&r=mysqlcfg
Bug #60480 [Opn->Fbk]: SERVER_ADDR should be present in server variables
Edit report at https://bugs.php.net/bug.php?id=60480&edit=1 ID: 60480 Updated by: larue...@php.net Reported by:lolautruche at gmail dot com Summary:SERVER_ADDR should be present in server variables -Status: Open +Status: Feedback Type: Bug Package:Built-in web server PHP Version:5.4.0RC3 -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I added SERVER_NAME yesterday, since it is handy. you can use that instead :) Previous Comments: [2011-12-09 13:46:19] lolautruche at gmail dot com Description: Hi Currently, SERVER_ADDR is absent from server variables, so that it needs to be defined in a router script. IMHO this variable should be available out-of-the- box. Thanks ! -- Edit this bug report at https://bugs.php.net/bug.php?id=60480&edit=1
Bug #53791 [Com]: NumberFormat::parse fail with French thousands separator
Edit report at https://bugs.php.net/bug.php?id=53791&edit=1 ID: 53791 Comment by: playa71 at gmail dot com Reported by:jinmoku at hotmail dot com Summary:NumberFormat::parse fail with French thousands separator Status: Feedback Type: Bug Package:I18N and L10N related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Running PHP 5.3.8 on Win7 - this problem still happens. Amazing in 2011 a programming language exists that doesn't support entire countries! sigh. Previous Comments: [2011-09-05 17:03:26] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ or 5.3.8 [2011-09-05 16:56:50] jinmoku at hotmail dot com in fact the french group sep is not a "space" but a "no-breaking space" [2011-07-13 08:38:46] jinmoku at hotmail dot com Feedback sent [2011-01-21 17:08:20] jinmoku at hotmail dot com On VC9 : string(6) "1 234" float(1) float(1234.56) [2011-01-19 19:50:39] jinmoku at hotmail dot com I can't try now, but I tested on my OSX with php 5.3.5 and ICU 4.6, and I have : string(6) "1 234" float(1) float(1234.56) 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=53791 -- Edit this bug report at https://bugs.php.net/bug.php?id=53791&edit=1
