Bug #60477 [Asn->Opn]: Segfault after two multipart/form-data POST requestes
Edit report at https://bugs.php.net/bug.php?id=60477&edit=1 ID: 60477 Updated by: larue...@php.net Reported by:reeze dot xia at gmail dot com -Summary:Segfault after two multipart/form-data POST requestes, one 200 RQ and one 404 +Summary:Segfault after two multipart/form-data POST requestes -Status: Assigned +Status: Open Type: Bug Package:Built-in web server Operating System: Mac OS X 10.6.7 PHP Version:trunk-SVN-2011-12-09 (SVN) Assigned To:laruence 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. I made a different patch, since the main/SAPI.c is used by many other sapis, and this bug should fixed in built-in server. thanks for your work . Previous Comments: [2011-12-09 05:37:23] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=320716 Log: Fixed bug #60477 (Segfault after two multipart/form-data POST requests) [2011-12-09 04:18:57] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL when sapi deactive. when trying to free the SG(rfc1867_uploaded_files), server will core dumped on the next form-data post request. So It's a simple oneline-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. thx. [2011-12-09 04:05:38] reeze dot xia at gmail dot com Description: Post two multipart/form-data to the cli-server, one 200 request and one 404 request will cause the cli-server segfault. if enabled debug, the server exit with a message: "in-consist hashtable". Test script: --- 1.Start the cli-server 2.Touch a simple empty php script 3.Make the requestes $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; Expected result: Server response correctly. one 200 and one 404 reponse. Actual result: -- Correctly response the first request. but segfault after the second 404 request. (gdb) bt #0 0x000100250da5 in _zend_mm_free_int (heap=0x10100, p=0x100670b60) at zend_alloc.c:2097 #1 0x000100224e4f in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x0001002219f2 in sapi_deactivate () at SAPI.c:535 #3 0x000100306b5e in php_cli_server_send_error_page (server=0x7fff5fbfa560, client=0x100b51170, status=404) at php_cli_server.c:1755 #4 0x0001003046ad in php_cli_server_dispatch [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:1851 #5 0x0001003046ad in php_cli_server_recv_event_read_request (server=0x7fff5fbfe790, client=0x100670b60) at php_cli_server.c:2180 #6 0x000100305ef5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2271 #7 php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:767 #8 php_cli_server_poller_iter_on_active [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2302 #9 php_cli_server_do_event_loop [inlined] () at /Volumes/Dev/Opensources/php- src-5.4/sapi/cli/php_cli_server.c:2292 #10 0x000100305ef5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2403 #11 0x0001002ffb94 in main (argc=1606414960, argv=0x7fff5fbff298) at php_cli.c:1359 -- Edit this bug report at https://bugs.php.net/bug.php?id=60477&edit=1
Bug #55121 [ReO->Fbk]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121&edit=1 ID: 55121 Updated by: larue...@php.net Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request -Status: Re-Opened +Status: Feedback Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) 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/ Previous Comments: [2011-12-09 03:50:41] reeze dot xia at gmail dot com haha, got you idea, I will open a new one. This bug's is indeed differ from the one I updated:-) [2011-12-09 03:31:19] larue...@php.net ah, sorry, my mis-take, assumed the wrong one :) [2011-12-09 03:29:47] larue...@php.net Hi, this is a closed bug, and your problem is another issue, could you please open a new bug instead of reopening a closed one? thanks [2011-12-09 03:07:29] reeze dot xia at gmail dot com To make it clear, the way to reproduce the core dump is: $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; if the --enable-debug flag is enabled, cli-server will exit with a message "in consist hashtable", normally it simply core dumped. [2011-12-09 02:50:26] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk still have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL after sapi deactive. when try to free the HashTable php core dumped on the next form-data post request. So It's a one-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. 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=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121&edit=1
Bug #60471 [Opn]: Random "Invalid request (unexpected EOF)" using a router script
Edit report at https://bugs.php.net/bug.php?id=60471&edit=1 ID: 60471 Updated by: larue...@php.net Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Open Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: I can't reproduce this on Linux. @patrickallaert, what is your OS? Previous Comments: [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 = Acknowledgement: Not set 0... = Push: Not set .0.. = Reset: Not set ..1. = Syn: Set [Expert Info (Chat/Sequence): Connection establish request (SYN): server port http-alt] [Message: Connection establish request (SYN): server port http- alt] [Severity level: Chat] [Group: Sequence] ...0 = Fin: Not set Window size value: 32792 [Calculated window size: 32792] Checksum: 0xfe30 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (20 bytes) Maximum segment size: 16396 bytes TCP SACK Permitted Option: True Timestamps: TSval 209439162, TSecr 0 Kind: Timestamp (8) Length: 10 Timestamp value: 209439162 Timestamp echo r
Bug #60473 [Opn->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: Open +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, what do you mean by "connection closed"? 500 error? Previous Comments: [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 #60477 [Asn->Csd]: Segfault after two multipart/form-data POST requestes
Edit report at https://bugs.php.net/bug.php?id=60477&edit=1 ID: 60477 Updated by: larue...@php.net Reported by:reeze dot xia at gmail dot com Summary:Segfault after two multipart/form-data POST requestes -Status: Assigned +Status: Closed Type: Bug Package:Built-in web server Operating System: Mac OS X 10.6.7 PHP Version:trunk-SVN-2011-12-09 (SVN) Assigned To:laruence Block user comment: N Private report: N Previous Comments: [2011-12-09 05:39:21] larue...@php.net 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. I made a different patch, since the main/SAPI.c is used by many other sapis, and this bug should fixed in built-in server. thanks for your work . [2011-12-09 05:37:23] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=320716 Log: Fixed bug #60477 (Segfault after two multipart/form-data POST requests) [2011-12-09 04:18:57] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL when sapi deactive. when trying to free the SG(rfc1867_uploaded_files), server will core dumped on the next form-data post request. So It's a simple oneline-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. thx. [2011-12-09 04:05:38] reeze dot xia at gmail dot com Description: Post two multipart/form-data to the cli-server, one 200 request and one 404 request will cause the cli-server segfault. if enabled debug, the server exit with a message: "in-consist hashtable". Test script: --- 1.Start the cli-server 2.Touch a simple empty php script 3.Make the requestes $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; Expected result: Server response correctly. one 200 and one 404 reponse. Actual result: -- Correctly response the first request. but segfault after the second 404 request. (gdb) bt #0 0x000100250da5 in _zend_mm_free_int (heap=0x10100, p=0x100670b60) at zend_alloc.c:2097 #1 0x000100224e4f in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x0001002219f2 in sapi_deactivate () at SAPI.c:535 #3 0x000100306b5e in php_cli_server_send_error_page (server=0x7fff5fbfa560, client=0x100b51170, status=404) at php_cli_server.c:1755 #4 0x0001003046ad in php_cli_server_dispatch [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:1851 #5 0x0001003046ad in php_cli_server_recv_event_read_request (server=0x7fff5fbfe790, client=0x100670b60) at php_cli_server.c:2180 #6 0x000100305ef5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2271 #7 php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:767 #8 php_cli_server_poller_iter_on_active [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2302 #9 php_cli_server_do_event_loop [inlined] () at /Volumes/Dev/Opensources/php- src-5.4/sapi/cli/php_cli_server.c:2292 #10 0x000100305ef5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2403 #11 0x0001002ffb94 in main (argc=1606414960, argv=0x7fff5fbff298) at php_cli.c:1359 -- Edit this bug report at https://bugs.php.net/bug.php?id=60477&edit=1
Bug #60477 [Opn]: Segfault after two multipart/form-data POST requestes, one 200 RQ and one 404
Edit report at https://bugs.php.net/bug.php?id=60477&edit=1 ID: 60477 User updated by:reeze dot xia at gmail dot com Reported by:reeze dot xia at gmail dot com Summary:Segfault after two multipart/form-data POST requestes, one 200 RQ and one 404 Status: Open Type: Bug Package:Built-in web server Operating System: Mac OS X 10.6.7 PHP Version:trunk-SVN-2011-12-09 (SVN) Block user comment: N Private report: N New Comment: Hi, the 5.4RC3 and the trunk have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL when sapi deactive. when trying to free the SG(rfc1867_uploaded_files), server will core dumped on the next form-data post request. So It's a simple oneline-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. thx. Previous Comments: [2011-12-09 04:05:38] reeze dot xia at gmail dot com Description: Post two multipart/form-data to the cli-server, one 200 request and one 404 request will cause the cli-server segfault. if enabled debug, the server exit with a message: "in-consist hashtable". Test script: --- 1.Start the cli-server 2.Touch a simple empty php script 3.Make the requestes $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; Expected result: Server response correctly. one 200 and one 404 reponse. Actual result: -- Correctly response the first request. but segfault after the second 404 request. (gdb) bt #0 0x000100250da5 in _zend_mm_free_int (heap=0x10100, p=0x100670b60) at zend_alloc.c:2097 #1 0x000100224e4f in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x0001002219f2 in sapi_deactivate () at SAPI.c:535 #3 0x000100306b5e in php_cli_server_send_error_page (server=0x7fff5fbfa560, client=0x100b51170, status=404) at php_cli_server.c:1755 #4 0x0001003046ad in php_cli_server_dispatch [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:1851 #5 0x0001003046ad in php_cli_server_recv_event_read_request (server=0x7fff5fbfe790, client=0x100670b60) at php_cli_server.c:2180 #6 0x000100305ef5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2271 #7 php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:767 #8 php_cli_server_poller_iter_on_active [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2302 #9 php_cli_server_do_event_loop [inlined] () at /Volumes/Dev/Opensources/php- src-5.4/sapi/cli/php_cli_server.c:2292 #10 0x000100305ef5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2403 #11 0x0001002ffb94 in main (argc=1606414960, argv=0x7fff5fbff298) at php_cli.c:1359 -- Edit this bug report at https://bugs.php.net/bug.php?id=60477&edit=1
[PHP-BUG] Bug #60477 [NEW]: Segfault after two multipart/form-data POST requestes, one 200 RQ and one 404
From: Operating system: Mac OS X 10.6.7 PHP version: trunk-SVN-2011-12-09 (SVN) Package: Built-in web server Bug Type: Bug Bug description:Segfault after two multipart/form-data POST requestes, one 200 RQ and one 404 Description: Post two multipart/form-data to the cli-server, one 200 request and one 404 request will cause the cli-server segfault. if enabled debug, the server exit with a message: "in-consist hashtable". Test script: --- 1.Start the cli-server 2.Touch a simple empty php script 3.Make the requestes $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; Expected result: Server response correctly. one 200 and one 404 reponse. Actual result: -- Correctly response the first request. but segfault after the second 404 request. (gdb) bt #0 0x000100250da5 in _zend_mm_free_int (heap=0x10100, p=0x100670b60) at zend_alloc.c:2097 #1 0x000100224e4f in destroy_uploaded_files_hash () at rfc1867.c:199 #2 0x0001002219f2 in sapi_deactivate () at SAPI.c:535 #3 0x000100306b5e in php_cli_server_send_error_page (server=0x7fff5fbfa560, client=0x100b51170, status=404) at php_cli_server.c:1755 #4 0x0001003046ad in php_cli_server_dispatch [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:1851 #5 0x0001003046ad in php_cli_server_recv_event_read_request (server=0x7fff5fbfe790, client=0x100670b60) at php_cli_server.c:2180 #6 0x000100305ef5 in php_cli_server_do_event_for_each_fd_callback [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2271 #7 php_cli_server_do_event_for_each_fd [inlined] () at php_cli_server.c:767 #8 php_cli_server_poller_iter_on_active [inlined] () at /Volumes/Dev/Opensources/php-src-5.4/sapi/cli/php_cli_server.c:2302 #9 php_cli_server_do_event_loop [inlined] () at /Volumes/Dev/Opensources/php- src-5.4/sapi/cli/php_cli_server.c:2292 #10 0x000100305ef5 in do_cli_server (argc=4, argv=0x10) at php_cli_server.c:2403 #11 0x0001002ffb94 in main (argc=1606414960, argv=0x7fff5fbff298) at php_cli.c:1359 -- Edit bug report at https://bugs.php.net/bug.php?id=60477&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60477&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60477&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60477&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60477&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60477&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60477&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60477&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60477&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60477&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60477&r=support Expected behavior: https://bugs.php.net/fix.php?id=60477&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60477&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60477&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60477&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60477&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60477&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60477&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60477&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60477&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60477&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60477&r=mysqlcfg
Bug #55121 [Com]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121&edit=1 ID: 55121 Comment by: reeze dot xia at gmail dot com Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request Status: Re-Opened Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To:fa Block user comment: N Private report: N New Comment: haha, got you idea, I will open a new one. This bug's is indeed differ from the one I updated:-) Previous Comments: [2011-12-09 03:31:19] larue...@php.net ah, sorry, my mis-take, assumed the wrong one :) [2011-12-09 03:29:47] larue...@php.net Hi, this is a closed bug, and your problem is another issue, could you please open a new bug instead of reopening a closed one? thanks [2011-12-09 03:07:29] reeze dot xia at gmail dot com To make it clear, the way to reproduce the core dump is: $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; if the --enable-debug flag is enabled, cli-server will exit with a message "in consist hashtable", normally it simply core dumped. [2011-12-09 02:50:26] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk still have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL after sapi deactive. when try to free the HashTable php core dumped on the next form-data post request. So It's a one-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. [2011-08-19 08:30:20] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=315162 Log: Fixed #55450 (Built in web server not accepting file uploads), which might break #55121 fixing(r313677) Reopened #55121 to let somebody redone the fixing(as I can't reproduce 55121 in redhat 64-bit). 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=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121&edit=1
Bug #55121 [Csd->ReO]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121&edit=1 ID: 55121 Updated by: larue...@php.net Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request -Status: Closed +Status: Re-Opened Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To:fa Block user comment: N Private report: N New Comment: ah, sorry, my mis-take, assumed the wrong one :) Previous Comments: [2011-12-09 03:29:47] larue...@php.net Hi, this is a closed bug, and your problem is another issue, could you please open a new bug instead of reopening a closed one? thanks [2011-12-09 03:07:29] reeze dot xia at gmail dot com To make it clear, the way to reproduce the core dump is: $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; if the --enable-debug flag is enabled, cli-server will exit with a message "in consist hashtable", normally it simply core dumped. [2011-12-09 02:50:26] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk still have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL after sapi deactive. when try to free the HashTable php core dumped on the next form-data post request. So It's a one-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. [2011-08-19 08:30:20] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=315162 Log: Fixed #55450 (Built in web server not accepting file uploads), which might break #55121 fixing(r313677) Reopened #55121 to let somebody redone the fixing(as I can't reproduce 55121 in redhat 64-bit). [2011-08-19 08:29:46] larue...@php.net This cause #55450, need redone. btw: I can't reproduce this in Redhat Linux 64-bit 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=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121&edit=1
Bug #55121 [ReO->Csd]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121&edit=1 ID: 55121 Updated by: larue...@php.net Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request -Status: Re-Opened +Status: Closed Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To:fa Block user comment: N Private report: N New Comment: Hi, this is a closed bug, and your problem is another issue, could you please open a new bug instead of reopening a closed one? thanks Previous Comments: [2011-12-09 03:07:29] reeze dot xia at gmail dot com To make it clear, the way to reproduce the core dump is: $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; if the --enable-debug flag is enabled, cli-server will exit with a message "in consist hashtable", normally it simply core dumped. [2011-12-09 02:50:26] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk still have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL after sapi deactive. when try to free the HashTable php core dumped on the next form-data post request. So It's a one-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. [2011-08-19 08:30:20] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=315162 Log: Fixed #55450 (Built in web server not accepting file uploads), which might break #55121 fixing(r313677) Reopened #55121 to let somebody redone the fixing(as I can't reproduce 55121 in redhat 64-bit). [2011-08-19 08:29:46] larue...@php.net This cause #55450, need redone. btw: I can't reproduce this in Redhat Linux 64-bit [2011-07-26 16:12:44] f...@php.net 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. 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=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121&edit=1
Bug #55121 [Com]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121&edit=1 ID: 55121 Comment by: reeze dot xia at gmail dot com Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request Status: Re-Opened Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To:fa Block user comment: N Private report: N New Comment: To make it clear, the way to reproduce the core dump is: $ curl --form a=b "http://localhost:8000/file.php"; $ curl --form a=b "http://localhost:8000/file-non-exist.php"; if the --enable-debug flag is enabled, cli-server will exit with a message "in consist hashtable", normally it simply core dumped. Previous Comments: [2011-12-09 02:50:26] reeze dot xia at gmail dot com Hi, the 5.4RC3 and the trunk still have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL after sapi deactive. when try to free the HashTable php core dumped on the next form-data post request. So It's a one-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. [2011-08-19 08:30:20] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=315162 Log: Fixed #55450 (Built in web server not accepting file uploads), which might break #55121 fixing(r313677) Reopened #55121 to let somebody redone the fixing(as I can't reproduce 55121 in redhat 64-bit). [2011-08-19 08:29:46] larue...@php.net This cause #55450, need redone. btw: I can't reproduce this in Redhat Linux 64-bit [2011-07-26 16:12:44] f...@php.net 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. [2011-07-25 20:18:37] nbpo...@php.net OK. I retested again just now with the latest snapshot on both OS X and Ubuntu. No segfaults anymore. 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=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121&edit=1
Bug #55121 [Com]: Segfault with multipart/form-data POST / 404 request
Edit report at https://bugs.php.net/bug.php?id=55121&edit=1 ID: 55121 Comment by: reeze dot xia at gmail dot com Reported by:nbpo...@php.net Summary:Segfault with multipart/form-data POST / 404 request Status: Re-Opened Type: Bug Package:Built-in web server Operating System: Ubuntu 10.04.2 LTS (64-bit) PHP Version:5.4SVN-2011-07-03 (snap) Assigned To:fa Block user comment: N Private report: N New Comment: Hi, the 5.4RC3 and the trunk still have this bug. After trace the core. I found the SG(rfc1867_uploaded_files) did't set to NULL after sapi deactive. when try to free the HashTable php core dumped on the next form-data post request. So It's a one-fix. I have attached a patch for this, patch tested on Mac OS X 10.6.7 & Redhat Linux. Previous Comments: [2011-08-19 08:30:20] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=315162 Log: Fixed #55450 (Built in web server not accepting file uploads), which might break #55121 fixing(r313677) Reopened #55121 to let somebody redone the fixing(as I can't reproduce 55121 in redhat 64-bit). [2011-08-19 08:29:46] larue...@php.net This cause #55450, need redone. btw: I can't reproduce this in Redhat Linux 64-bit [2011-07-26 16:12:44] f...@php.net 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. [2011-07-25 20:18:37] nbpo...@php.net OK. I retested again just now with the latest snapshot on both OS X and Ubuntu. No segfaults anymore. [2011-07-25 18:11:10] nbpo...@php.net Tested latest snapshot on OS X. Same backtrace. 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=55121 -- Edit this bug report at https://bugs.php.net/bug.php?id=55121&edit=1
Bug #60472 [Opn->Fbk]: 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: Open +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: 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. Previous Comments: [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 #60452 [Fbk->Opn]: redefine __toString
Edit report at https://bugs.php.net/bug.php?id=60452&edit=1
ID: 60452
User updated by:kashpur dot kostya at gmail dot com
Reported by:kashpur dot kostya at gmail dot com
Summary:redefine __toString
-Status: Feedback
+Status: Open
Type: Bug
Package:*General Issues
Operating System: Windows7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
_file = $file;
}
public function __toString()
{
return $this->getFile() . '-magic';
}
public function getFile()
{
return $this->_file;
}
}
$a = new A(new File('file_name.php'));
print $a;
?>
*
Actual result:
--
file_name.php-magic
Maybe the trick is in this magic '-magic'
Sorry for taftologiya
If I removes '-magic' string PHP would show me "Catchable fatal error: Method
A::__toString() must return a string value in..."
And with magic it would call \SplFileInfo::__toString() not File::__toString()
Expected result:
It`s a file
p.s. hope this code is enoughе to properly diagnose the problem
Previous Comments:
[2011-12-07 02:40:59] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
I can not reproduce what you described with following assuming script:
https://bugs.php.net/bug.php?id=60452&edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: antoninweb at gmail dot com
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
I don't understand how this is not included when PHP supports try...catch. It
just
doesn't makes sense and it's annoying because you have to find ways around it
contantly.
Previous Comments:
[2011-12-06 05:50:29] ben at last dot fm
"finally" would be a majorly beneficial addition to the language. It's
something
we yearn for here at last.fm.
[2011-12-05 17:55:43] php dot net at kenman dot net
+1
>From Zeev, in the 2000 discussion:
> try..finally doesn't make much sense in the context of PHP [...] Nobody has
> ever
asked for this in the past either.
Those days are long past, please take this bug report's comments as a sign that
this *does* now make sense for PHP.
[2011-12-05 15:53:28] topaz dot php dot bugs at lt3 dot us
Ugly workaround hack time!
(This is not a substitute for a real language feature!)
Mix and match with try/catch blocks as necessary.
invoke();
print "Example 1 ended normally.\n";
}
function example2()
{
$finally = new Finally("example_finally");
print "Throwing exception!\n";
throw new Exception("Something exceptional happened!");
$finally->invoke();
print "Example 2 ended normally.\n";
}
// Test harness
print "Example 1...\n";
try
{
example1();
}
catch (Exception $e)
{
print "Example 1 threw an exception!\n";
}
print "\nExample 2...\n";
try
{
example2();
}
catch (Exception $e)
{
print "Example 2 threw an exception!\n";
}
// Implementation of the Finally class
class Finally
{
private $_callback = NULL;
private $_args = array();
function __construct($callback, array $args = array())
{
if (!is_callable($callback))
{
throw new Exception("Callback was not callable!");
}
$this->_callback = $callback;
$this->_args = $args;
}
public function invoke()
{
if ($this->_callback)
{
call_user_func_array($this->_callback, $args);
$this->_callback = NULL;
$this->_args = array();
}
}
function __destruct()
{
$this->invoke();
}
}
[2011-11-18 00:25:23] chiestand at salk dot edu
First, thank you everyone who has contributed to this bug report thread. Your
insights have been incredibly useful.
I too vote for inclusion of "finally" into PHP. In my own particular situation
I was
able to solve my problem using Stroustrup's RAII pattern (thank you btsai). But
I can
imagine that in some cases creating a class for every resource used might be
inconvenient.
I think ceefour really summed it up nicely back in 2005 with even more-ancient
wisdom: "Be conservative with what you emit and be liberal with what you
accept".
Provide the tool, and let the coder decide what pattern to use.
[2011-09-07 14:49:08] viktor at zuiderkwast dot se
The same problem exists in C++, which also lacks the finally clause. The
standard way to solve the resource allocation problem in C++ is instead by
using the RAII design pattern.
As noted in Wikipedia on RAII, "In this language, the only code that can be
guaranteed to be executed after an exception is thrown are the destructors of
objects residing on the stack.". The same is valid for PHP (although the
objects are reference-counted instead of being allocated on the stack). The
destructor is guarranteed to be called as soon as all references to the object
run out of scope, so the RAII is effectively usable in PHP.
So, the code you would put in the finally clause in Java etc has to be put in a
destructor of some object instead. Then, when a return or a or an uncatched
exception occurs inside a try block, and there are no other references to the
object, the destructor will be called at this point to free the resources.
In my optinion, the finally clause is a more elegant solution, although it
might be *too sophisticated* for 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=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
[PHP-BUG] Bug #60475 [NEW]: Assignments of $this in some implicit __toString contexts get broken
From: Operating system: Windows 7, Ubuntu 10 PHP version: 5.3.8 Package: Class/Object related Bug Type: Bug Bug description:Assignments of $this in some implicit __toString contexts get broken Description: Tested with php 5.3.8 on Windows 7, 5.4.0RC2 Win32, and 5.4.0RC2 (cli) on Ubuntu 10.04.3 When an object is implicitly used as a string when passed to some php functions, __toString is called as expected, but any assignments of $this from within __toString are eventually broken and point instead to the string that gets returned. This behavior occurs only in some php functions, and never if you cast as string while passing into the functions. This behavior has been observed when passing objects into at least these php functions: str_replace, preg_replace, preg_match_all, sprintf. There are many php string functions that do not behave this way (they allow __toString-created references to $this persist as references to the object). For extra fun, play around with htmlspecialchars, echo-ing the output... I suspect that's a whole different issue, but related (possible memory leak there). Test script: --- https://bugs.php.net/bug.php?id=60475&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60475&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60475&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60475&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60475&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60475&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60475&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60475&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60475&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60475&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60475&r=support Expected behavior: https://bugs.php.net/fix.php?id=60475&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60475&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60475&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60475&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60475&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60475&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60475&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60475&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60475&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60475&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60475&r=mysqlcfg
Bug #55567 [Com]: SoapFault is missing methods to get the Fault Code
Edit report at https://bugs.php.net/bug.php?id=55567&edit=1 ID: 55567 Comment by: hairmare at purplehaze dot ch Reported by:c...@php.net Summary:SoapFault is missing methods to get the Fault Code Status: Open Type: Bug Package:SOAP related PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: I just ran into this in 5.3.8. Personally i would expect SOAPFault::getCode() to return the fault exactly as it was received from SOAP (ie. as a string). I wrote a phpt case showing what behaviour I would expect. I didn't find a way to add it to this ticket, so here goes: --TEST-- Test for strings in Exception::getCode() --FILE-- getCode()); ?> --EXPECT-- string(6) "Client" Previous Comments: [2011-09-01 17:15:35] c...@php.net Description: The SoapFault object does not have a getFaultCode() method nor does it set the exception code to the received SOAP fault code. The code is available through the undocumented public property "faultcode" though. I would suggest setting the Exception code to the SOAP fault code. Backwards compatibility shouldn't be a big problem because currently, the code can only be 0 as the constructor does not even makes it possible to change it. If you disagree, I'd like to see a getFaultCode() method at least. Having access to the SOAP fault code is essential as SOAP does not transfer the Exception class name and thus there is no other way to cleanly distinguish between different kinds of exceptions. -- Edit this bug report at https://bugs.php.net/bug.php?id=55567&edit=1
Bug #55777 [Com]: Error starting Apache server
Edit report at https://bugs.php.net/bug.php?id=55777&edit=1 ID: 55777 Comment by: justin dot mcdaniel at shipconstructor dot com Reported by:jlmueller at optonline dot net Summary:Error starting Apache server Status: Open Type: Bug Package:Apache2 related Operating System: win xp sp3 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I was able to solve the issue by commenting out the PHP_SQLSRV extension. If you are not hooking up to an MSSQL database, please find the [PHP_SQLSRV] extension line and comment it out: Change: [PHP_SQLSRV] extension=php_sqlsrv.dll To this: ; [PHP_SQLSRV] ; extension=php_sqlsrv.dll If you do need this extension, then you might want to try finding another version of the dll as the one included with PHP 5.3.8 appears to cause errors. Previous Comments: [2011-10-20 01:04:21] jlmueller at optonline dot net I tried going back to PHP 5.2.17 and now things work normally. I guess there is problem with the 5.3.x version form my configuration [2011-10-08 01:20:15] jlmueller at optonline dot net I tried haryo's suggested change of '/' instead of '\'. I still get the same error message as before. [2011-10-07 04:15:39] haryo at ukdw dot ac dot id i've got same error with apache 2.2.21 and php 5.3.8 on windows 2008 server, then i try to change '\' character with '/' and apache run smoothly here's my conf PHPIniDir "C:/PHP/" LoadFile "C:/PHP/php5ts.dll" LoadModule php5_module "C:/PHP/php5apache2_2.dll" php_value extension_dir "C:/PHP/ext/" funny thing is: i have apache 2.2.19 which running okay with '\' char ..sorry for my english, it's not my first language [2011-09-25 01:34:02] jlmueller at optonline dot net Description: Just installed Apache 2.2.21 upgrade and PHP 5.3.8. Had run earlier editions of both without problem. We starting the Apache server it fails with the following error Faulting application httpd.exe, version 2.2.21.0, faulting module php5ts.dll, version 5.3.8.0, fault address 0x000f8a90. It is repeatable. If I comment out the following PHP entries in the Apache hppd.config file entries PHPIniDir "C:\Program Files\PHP\" LoadModule php5_module "C:\Program Files\PHP\php5apache2_2.dll" Apache will start and I can do non-PHP based pages -- Edit this bug report at https://bugs.php.net/bug.php?id=55777&edit=1
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: Open 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: 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 = Acknowledgement: Not set 0... = Push: Not set .0.. = Reset: Not set ..1. = Syn: Set [Expert Info (Chat/Sequence): Connection establish request (SYN): server port http-alt] [Message: Connection establish request (SYN): server port http- alt] [Severity level: Chat] [Group: Sequence] ...0 = Fin: Not set Window size value: 32792 [Calculated window size: 32792] Checksum: 0xfe30 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (20 bytes) Maximum segment size: 16396 bytes TCP SACK Permitted Option: True Timestamps: TSval 209439162, TSecr 0 Kind: Timestamp (8) Length: 10 Timestamp value: 209439162 Timestamp echo reply: 0 No-Operation (NOP) Window scale: 7 (multiply by 128) Kind: Window Scale (3) Length: 3 Shift count: 7 [Multiplier: 128] 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ...
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: lolautruche at gmail dot com Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Open 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: This issue seems to happen only with Google Chrome Previous Comments: [2011-12-08 15:01:09] lolautruche at gmail dot com Description: >From time to time, built-in server with router script logs this kind of stuff : [Thu Dec 8 13:39:29 2011] 127.0.0.1:50358 Invalid request (Unexpected EOF) This happens quite randomly, whatever the script has a close tag or not, whatever it has a blank line after close tag or not. Test script: --- php -S localhost:8000 router.php Actual result: -- [Thu Dec 8 13:39:29 2011] 127.0.0.1:50358 Invalid request (Unexpected EOF) -- Edit this bug report at https://bugs.php.net/bug.php?id=60471&edit=1
[PHP-BUG] Bug #60473 [NEW]: Built-in server randomly closes connections
From: Operating system: Mac OS X 10.7.2 (Lion) PHP version: 5.4.0RC2 Package: Built-in web server Bug Type: Bug Bug description:Built-in server randomly closes connections 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 bug report at https://bugs.php.net/bug.php?id=60473&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60473&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60473&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60473&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60473&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60473&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60473&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60473&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60473&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60473&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60473&r=support Expected behavior: https://bugs.php.net/fix.php?id=60473&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60473&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60473&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60473&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60473&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60473&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60473&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60473&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60473&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60473&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60473&r=mysqlcfg
[PHP-BUG] Bug #60472 [NEW]: PHP_SELF/SCRIPT_NAME wrongly defined in $_SERVER
From: Operating system: Mac OS X 10.7.2 (Lion) PHP version: 5.4.0RC2 Package: Built-in web server Bug Type: Bug Bug description:PHP_SELF/SCRIPT_NAME wrongly defined in $_SERVER 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 bug report at https://bugs.php.net/bug.php?id=60472&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60472&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60472&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60472&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60472&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60472&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60472&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60472&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60472&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60472&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60472&r=support Expected behavior: https://bugs.php.net/fix.php?id=60472&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60472&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60472&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60472&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60472&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60472&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60472&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60472&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60472&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60472&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60472&r=mysqlcfg
[PHP-BUG] Bug #60471 [NEW]: Random "Invalid request (unexpected EOF)" using a router script
From: Operating system: Mac OS X 10.7.2 (Lion) PHP version: 5.4.0RC2 Package: Built-in web server Bug Type: Bug Bug description:Random "Invalid request (unexpected EOF)" using a router script Description: >From time to time, built-in server with router script logs this kind of stuff : [Thu Dec 8 13:39:29 2011] 127.0.0.1:50358 Invalid request (Unexpected EOF) This happens quite randomly, whatever the script has a close tag or not, whatever it has a blank line after close tag or not. Test script: --- php -S localhost:8000 router.php Actual result: -- [Thu Dec 8 13:39:29 2011] 127.0.0.1:50358 Invalid request (Unexpected EOF) -- Edit bug report at https://bugs.php.net/bug.php?id=60471&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60471&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60471&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60471&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60471&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60471&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60471&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60471&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60471&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60471&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60471&r=support Expected behavior: https://bugs.php.net/fix.php?id=60471&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60471&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60471&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60471&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60471&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60471&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60471&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60471&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60471&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60471&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60471&r=mysqlcfg
[PHP-BUG] Req #60470 [NEW]: PEAR Folder not included in PHP 5.3.8 VC9
From: Operating system: Windows PHP version: 5.3.8 Package: Windows Installer Bug Type: Feature/Change Request Bug description:PEAR Folder not included in PHP 5.3.8 VC9 Description: Discussion see http://news.php.net/php.internals.win/838 and http://news.php.net/php.internals.win/840 Test script: --- n/a Expected result: The PEAR Folder should be included into the zip file Actual result: -- PEAR folder isn't in the zip -- Edit bug report at https://bugs.php.net/bug.php?id=60470&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60470&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60470&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60470&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60470&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60470&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60470&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60470&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60470&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60470&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60470&r=support Expected behavior: https://bugs.php.net/fix.php?id=60470&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60470&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60470&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60470&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60470&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60470&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60470&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60470&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60470&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60470&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60470&r=mysqlcfg
Bug #55371 [Com]: get_magic_quotes_gpc() throws deprecation warning
Edit report at https://bugs.php.net/bug.php?id=55371&edit=1
ID: 55371
Comment by: mah11ahm at hotmail dot com
Reported by:thbley at gmail dot com
Summary:get_magic_quotes_gpc() throws deprecation warning
Status: Closed
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Win7 6.1.7600
PHP Version:5.4.0alpha3
Assigned To:dsp
Block user comment: N
Private report: N
New Comment:
My opinion that transcends that disable line 7 as follows, where I have is
version 5.4 (put comment symble) and save then press (live view ) if using
dreamwaver or run it on internet explorer
/* if (PHP_VERSION < 6) {
$theValue = get_magic_quotes_gpc() ? stripslashes($theValue) : $theValue;
}*/
Previous Comments:
[2011-11-22 13:11:07] pierr...@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revision&revision=319679
Log: Those functions are not deprecated (r319249 #55371)
[2011-11-15 13:27:13] d...@php.net
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.
Thanks david, patch applied.
[2011-11-15 13:22:42] d...@php.net
Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=319249
Log: Fixed bug #55371 (get_magic_quotes_gpc() throws deprecation warning.)
Patch by David Zuelke
[2011-11-15 13:09:43] paj...@php.net
Let me clarify this pointer. Getter should not raise any warning. Setters do.
[2011-11-15 13:01:45] david dot zuelke at bitextender dot com
A warning definitely is a bad idea, it makes it impossible to write portable
code
to detect magic quotes without version check stunts. It's fine if the two
functions simply return false forever, there's not even a need to remove them
as
they don't do any harm whatsoever.
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=55371
--
Edit this bug report at https://bugs.php.net/bug.php?id=55371&edit=1
Req #38917 [Com]: OpenSSL: signing function for spkac
Edit report at https://bugs.php.net/bug.php?id=38917&edit=1
ID: 38917
Comment by: jason dot gerfen at gmail dot com
Reported by:zeph at purotesto dot it
Summary:OpenSSL: signing function for spkac
Status: Open
Type: Feature/Change Request
Package:OpenSSL related
Operating System: Irrilevant
PHP Version:4.4.4
Block user comment: N
Private report: N
New Comment:
I modified the test case and fixed a slight memory problem that would
occasionally take place when allocating memory for the openssl_spki_new()
return value.
echo "Generating private key...";
$key = openssl_pkey_new(array('digest_alg' => 'sha1',
'private_key_type' => OPENSSL_KEYTYPE_RSA,
'private_key_bits' => 2048));
echo "done\n";
echo "\n";
echo "Creating SPKAC...\n";
if (function_exists('openssl_spki_new')){
$spki = openssl_spki_new($key, 'wtfd00d');
echo $spki;
}
echo "done\n";
echo "\n";
echo "SPKAC details...\n";
if (function_exists('openssl_spki_details')){
$x = (empty($_POST['spki-key'])) ?
openssl_spki_details(preg_replace('/SPKAC=/', '', $spki)) :
openssl_spki_details($_POST['spki-key']);
var_dump($x);
}
echo "done\n";
echo "\n";
echo "Verifying SPKAC...\n";
if (function_exists('openssl_spki_verify')){
$y = (empty($_POST['spki-key'])) ?
openssl_spki_verify(preg_replace('/SPKAC=/', '', $spki)) :
openssl_spki_verify($_POST['spki-key']);
var_dump($y);
}
echo "\n\n";
echo "Exporting public key from SPKAC...\n";
if (function_exists('openssl_spki_export')){
$z = (empty($_POST['spki-key'])) ?
openssl_spki_export(preg_replace('/SPKAC=/', '', $spki)) :
openssl_spki_export($_POST['spki-key']);
var_dump($z);
}
Previous Comments:
[2011-12-06 11:28:50] jason dot gerfen at gmail dot com
Here is a patch to implement three new functions to help with verification of
the SPKAC HTML keygen element.
To patch:
1. Download PHP-5.3.8
2. Download patch from here (spki.patch)
3. Apply patch
%> patch -p0 < spki.patch
4. Configure and compiled PHP
%> ./configure --with-openssl=/path/to/openssl
%> make && make install
Test script:
$key = openssl_pkey_new(array('digest_alg' => 'sha1',
'private_key_type' => OPENSSL_KEYTYPE_RSA,
'private_key_bits' => 2048));
if (function_exists('openssl_spki_new')){
$spki = openssl_spki_new($key, 'password');
echo $spki.'\n\r';
}
if (function_exists('openssl_spki_verify')){
echo openssl_spki_verify(preg_replace('/SPKAC=/', '', $spki)).'\n\r';
}
if (function_exists('openssl_spki_export')){
echo openssl_spki_export(preg_replace('/SPKAC=/', '', $spki)).'\n\r';
}
[2011-12-03 02:55:06] jason dot gerfen at gmail dot com
Not sure how to go about submitting a patch I am working on to address this.
[2006-09-21 23:45:19] zeph at purotesto dot it
Description:
i need openssl api support for spkac
now there's the possibility to sign a pkcs10 csr (created by explorer) but not
an spkac created by firefox/mozilla/netscape/safary ...
check www.openca.org for more information... i need that api to create
something similar but more usable on the GOsa project http://gosa.gonicus.de
by
Guido Serra
http://dev.purotesto.it/support/gosa
GOsa CA Management plugin
--
Edit this bug report at https://bugs.php.net/bug.php?id=38917&edit=1
Bug #60268 [Com]: Compiling PHP fails
Edit report at https://bugs.php.net/bug.php?id=60268&edit=1 ID: 60268 Comment by: lolautruche at gmail dot com Reported by:rich06 at gmail dot com Summary:Compiling PHP fails Status: Closed Type: Bug Package:Compile Failure Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.3.8 Assigned To:patrickallaert Block user comment: N Private report: N New Comment: I don't agree here, as ./configure --help says: --with-apxs2=FILE Build shared Apache 2.0 Handler module. FILE is the optional pathname to the Apache apxs tool apxs So FILE is optional Previous Comments: [2011-12-08 10:38:54] patrickalla...@php.net Closing. Invalid usage of --with-apxs2 which expects a file argument: --with-apxs2 --with-iconv-dir=/opt/local [2011-12-08 09:59:43] lolautruche at gmail dot com There seems to be linked with --with-apxs2 option. Indeed, I first used --with-apxs2 (without value) and --with-iconv-dir=/opt/local (macports prefix). Here the compiler will take apxs system default (which is /usr/sbin/apxs), and for some reason also makes ignore --with-iconv-dir value. If I use --with-apxs2=/opt/local/apache2/bin/apxs (apache2 macports prefix), then everything will be fine. [2011-12-06 10:02:54] patrickalla...@php.net This issue should be solved, editing manually the Makefile isn't the way to go. [2011-12-06 09:37:01] lolautruche at gmail dot com I confirm the same issue while compiling PHP 5.4RC2. To reproduce it, you'll need to have MacPorts installed with iconv lib installed here. Basically, I already have a 5.3.8 built with MacPorts on my system. Modifying the Makefile as rich06 suggested made it work, but shouldn't this be made by configure script ? I tried with --with-iconv-dir=/opt/local/lib, but it doesn't seem to work here [2011-11-30 20:46:08] rich06 at gmail dot com I finally resolved this by editing the Makefile as follows so that the first -L/usr/lib is changed to -L/opt/local/lib (I am using Macports) MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd -L/opt/local/lib -laprutil-1 -lldap -llber -llber -lexpat -liconv -L/usr/lib -lpq -lsqlite3 -lldap -llber -llber -L/usr/lib -lapr-1 -lpthread Hope this helps someone else. 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=60268 -- Edit this bug report at https://bugs.php.net/bug.php?id=60268&edit=1
Bug #60268 [ReO->Csd]: Compiling PHP fails
Edit report at https://bugs.php.net/bug.php?id=60268&edit=1 ID: 60268 Updated by: patrickalla...@php.net Reported by:rich06 at gmail dot com Summary:Compiling PHP fails -Status: Re-Opened +Status: Closed Type: Bug Package:Compile Failure Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.3.8 -Assigned To: +Assigned To:patrickallaert Block user comment: N Private report: N New Comment: Closing. Invalid usage of --with-apxs2 which expects a file argument: --with-apxs2 --with-iconv-dir=/opt/local Previous Comments: [2011-12-08 09:59:43] lolautruche at gmail dot com There seems to be linked with --with-apxs2 option. Indeed, I first used --with-apxs2 (without value) and --with-iconv-dir=/opt/local (macports prefix). Here the compiler will take apxs system default (which is /usr/sbin/apxs), and for some reason also makes ignore --with-iconv-dir value. If I use --with-apxs2=/opt/local/apache2/bin/apxs (apache2 macports prefix), then everything will be fine. [2011-12-06 10:02:54] patrickalla...@php.net This issue should be solved, editing manually the Makefile isn't the way to go. [2011-12-06 09:37:01] lolautruche at gmail dot com I confirm the same issue while compiling PHP 5.4RC2. To reproduce it, you'll need to have MacPorts installed with iconv lib installed here. Basically, I already have a 5.3.8 built with MacPorts on my system. Modifying the Makefile as rich06 suggested made it work, but shouldn't this be made by configure script ? I tried with --with-iconv-dir=/opt/local/lib, but it doesn't seem to work here [2011-11-30 20:46:08] rich06 at gmail dot com I finally resolved this by editing the Makefile as follows so that the first -L/usr/lib is changed to -L/opt/local/lib (I am using Macports) MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd -L/opt/local/lib -laprutil-1 -lldap -llber -llber -lexpat -liconv -L/usr/lib -lpq -lsqlite3 -lldap -llber -llber -L/usr/lib -lapr-1 -lpthread Hope this helps someone else. [2011-11-30 13:26:11] rich06 at gmail dot com Bump... anyone? This is really screwing me as the version of PHP supplied by Apple won't run background CLI scripts and is missing some extensions I need to have 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=60268 -- Edit this bug report at https://bugs.php.net/bug.php?id=60268&edit=1
Bug #60268 [Com]: Compiling PHP fails
Edit report at https://bugs.php.net/bug.php?id=60268&edit=1 ID: 60268 Comment by: lolautruche at gmail dot com Reported by:rich06 at gmail dot com Summary:Compiling PHP fails Status: Re-Opened Type: Bug Package:Compile Failure Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.3.8 Block user comment: N Private report: N New Comment: There seems to be linked with --with-apxs2 option. Indeed, I first used --with-apxs2 (without value) and --with-iconv-dir=/opt/local (macports prefix). Here the compiler will take apxs system default (which is /usr/sbin/apxs), and for some reason also makes ignore --with-iconv-dir value. If I use --with-apxs2=/opt/local/apache2/bin/apxs (apache2 macports prefix), then everything will be fine. Previous Comments: [2011-12-06 10:02:54] patrickalla...@php.net This issue should be solved, editing manually the Makefile isn't the way to go. [2011-12-06 09:37:01] lolautruche at gmail dot com I confirm the same issue while compiling PHP 5.4RC2. To reproduce it, you'll need to have MacPorts installed with iconv lib installed here. Basically, I already have a 5.3.8 built with MacPorts on my system. Modifying the Makefile as rich06 suggested made it work, but shouldn't this be made by configure script ? I tried with --with-iconv-dir=/opt/local/lib, but it doesn't seem to work here [2011-11-30 20:46:08] rich06 at gmail dot com I finally resolved this by editing the Makefile as follows so that the first -L/usr/lib is changed to -L/opt/local/lib (I am using Macports) MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd -L/opt/local/lib -laprutil-1 -lldap -llber -llber -lexpat -liconv -L/usr/lib -lpq -lsqlite3 -lldap -llber -llber -L/usr/lib -lapr-1 -lpthread Hope this helps someone else. [2011-11-30 13:26:11] rich06 at gmail dot com Bump... anyone? This is really screwing me as the version of PHP supplied by Apple won't run background CLI scripts and is missing some extensions I need to have [2011-11-11 17:08:43] rich06 at gmail dot com Forgot to mention that I did try all the suggestions such as moving MH_BUNDLE_FLAGS in the Makefile and editing iconv.c using different iconv libs (MacPorts) -- nothing worked... 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=60268 -- Edit this bug report at https://bugs.php.net/bug.php?id=60268&edit=1
[PHP-BUG] Bug #60468 [NEW]: Output is not discarded when ob_start() callback returns ""
From: vrana
Operating system: Windows
PHP version: 5.4.0RC2
Package: Output Control
Bug Type: Bug
Bug description:Output is not discarded when ob_start() callback returns ""
Description:
If ob_start() callback returns an empty string then nothing should be
printed. This is the current behavior in PHP 5.3. Behavior in PHP 5.4 is
different - if a callback returns an empty string then the result is same
as if it wouldn't be called at all - next call is prepended by last call
value.
So there is no way for callback how to discard the output.
Test script:
---
ob_start(function ($s) {
fwrite(STDERR, strlen($s) . "\n");
if ($s == "b\n") {
return $s;
}
return "";
}, 2);
echo "a\n";
echo "b\n";
exit;
Expected result:
2
2
b
0
Actual result:
--
2
4
4
--
Edit bug report at https://bugs.php.net/bug.php?id=60468&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60468&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60468&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60468&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60468&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60468&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60468&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60468&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60468&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60468&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60468&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60468&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60468&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60468&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60468&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60468&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60468&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60468&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60468&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60468&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60468&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60468&r=mysqlcfg
