Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Updated by: larue...@php.net Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: I think we can split this into two patch: 1. keep the looks unchanged, and improve the skeleton 2. improve the looks the first one could easy to be accepted. Previous Comments: [2012-10-09 20:28:56] pascal dot chevrel at free dot fr btw, I attached a patch to the bug but in case you prefer a Pull Request on github, just tell me. I don't know what process is preferred today for PHP patches. [2012-10-09 14:50:01] re...@php.net @Pascal, I like the idea to make it more modern, I just think the color you choose it not well consist with PHP's blue color and visual identity. [2012-10-09 12:02:24] pascal dot chevrel at free dot fr I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" 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=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Bug #63249 [Opn->Asn]: built-in webserver does not work with Opera browser
Edit report at https://bugs.php.net/bug.php?id=63249&edit=1 ID: 63249 Updated by: johan...@php.net Reported by:pascal dot chevrel at free dot fr Summary:built-in webserver does not work with Opera browser -Status: Open +Status: Assigned Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.7 -Assigned To: +Assigned To:moriyoshi Block user comment: N Private report: N New Comment: Assigning to author. Previous Comments: [2012-10-09 16:41:46] pascal dot chevrel at free dot fr good guess : http://[::1]:8002/ works my /etc/hosts lists localhost as 127.0.0.1 [2012-10-09 16:38:23] johan...@php.net As a guess: Might this be an IPv6 issue? Can you try loading http://127.0.0.1:8002/ and http://[::1]:8002/ Please also checks whether your /etc/hosts lists "localhost" as ::1 or 127.0.0.1 [2012-10-09 15:25:25] larue...@php.net sounds very weird, maybe you can debug it with tcpdump, to check whether the request really arrived. [2012-10-09 15:10:31] pascal dot chevrel at free dot fr Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit this bug report at https://bugs.php.net/bug.php?id=63249&edit=1
Bug #63240 [Opn]: stream_get_line return contains delimiter string
Edit report at https://bugs.php.net/bug.php?id=63240&edit=1
ID: 63240
Updated by: cataphr...@php.net
Reported by:scope at planetavent dot de
Summary:stream_get_line return contains delimiter string
Status: Open
Type: Bug
Package:Streams related
Operating System: Windows Server 2008 / RHEL 6.2
PHP Version:5.3.17
-Assigned To:
+Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
Thanks, I'll commit this tomorrow.
As to your other comment on the list about the bool(false) return instead of an
empty string for an empty file, that was a bug fix. A return of "" would
indicate an empty line. The result is now corect:
$ php -r '$fd = fopen("php://temp", "r+"); var_dump(stream_get_line($fd, 10,
"MM"));'
bool(false)
$ php -r '$fd = fopen("php://temp", "r+"); fwrite($fd, "MM"); rewind($fd);
var_dump(stream_get_line($fd, 10, "MM"), stream_get_line($fd, 10, "MM"));
string(0) ""
bool(false)
Previous Comments:
[2012-10-09 09:02:54] datib...@php.net
Added a patch that will apply to 5.4.4
[2012-10-09 09:02:18] datib...@php.net
The following patch has been added/updated:
Patch Name: getrecord-delimiter-search-fix
Revision: 1349773338
URL:
https://bugs.php.net/patch-display.php?bug=63240&patch=getrecord-delimiter-search-fix&revision=1349773338
[2012-10-09 03:35:35] datib...@php.net
Reduced test:
$file = __DIR__ . '/input_dummy.txt';
$data = str_repeat( '.', 8189 ) . '';
file_put_contents( $file, $data );
$fh = fopen( $file, "rb" );
$delimiter = "MM";
stream_get_line($fh, 4096, $delimiter);
stream_get_line($fh, 4096, $delimiter);
if ($delimiter === stream_get_line($fh, 4096, $delimiter)) {
echo "BROKEN";
} else {
echo "OK";
}
fclose($fh);
unlink($file);
The amount of dots seems to be related to the used buffer length:
( + 3) % ( x 2) == 0
The length of the delimiter also seems to play a role, but I'm not sure what
that would be.
[2012-10-08 16:03:38] scope at planetavent dot de
Description:
On specific file input stream_get_line returns a "line" that actually contains
the delimiter.
PHP 5.3.10 does not show this problem, PHP versions from 5.3.11 to 5.3.17 do.
PHP 5.4.7 seems to be affected as well.
Bug #44607 seems to be related, but was fixed long time ago.
Test script:
---
https://bugs.php.net/bug.php?id=63240&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: btw, I attached a patch to the bug but in case you prefer a Pull Request on github, just tell me. I don't know what process is preferred today for PHP patches. Previous Comments: [2012-10-09 14:50:01] re...@php.net @Pascal, I like the idea to make it more modern, I just think the color you choose it not well consist with PHP's blue color and visual identity. [2012-10-09 12:02:24] pascal dot chevrel at free dot fr I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" 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=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Bug #62929 [Com]: Segmentation fault on Zend Framework application
Edit report at https://bugs.php.net/bug.php?id=62929&edit=1 ID: 62929 Comment by: ahebert at pubnix dot net Reported by:sergiu dot ionescu at gmail dot com Summary:Segmentation fault on Zend Framework application Status: Open Type: Bug Package:*General Issues Operating System: Ubuntu 10.04.4 LTS PHP Version:PHP 5.3.16 Block user comment: N Private report: N New Comment: I can confirm this issue happening in this situation: . FreeBSD 8.2-p2 amd64 . Compiled ports . PHP 5.4.6 (from ports) . Magento 1.5.1.0 The effect we're noticing is, in the /admin section of Magento, is that while you navigate, it will stop responding: . on the server side nothing is noticeable . after the usual 30s timeout you will get the page back . then you may or may not have a core dump Digging further, it seems to come from a flock issue since I can find this sequence in all my dumps. The stack at #28 is most likely the 30s timeout and the flock caused a dead lock. #27 0x004481bb in just_die (sig=Variable "sig" is not available. ) at prefork.c:328 #28 #29 0x00080141f8fc in flock () from /lib/libc.so.7 More to come... Previous Comments: [2012-08-30 17:03:22] sergiu dot ionescu at gmail dot com apc alone does not generate this. It's related to apc+Magento+a Multi-location module for Magento... That's why it's hard to give you a script to reproduce it. All i can say that the specific module uses allot of weird obfuscation: eval's and other stuff you don't necessarily need. [2012-08-30 16:39:29] larue...@php.net so, this is related to apc? [2012-08-30 16:13:15] sergiu dot ionescu at gmail dot com Setting apc.enable_cli=0 so far has eliminated the issue. I don't this fixed the underlying issue but at least it gets rid of the nasty exit code at the end on the script. [2012-08-28 08:04:19] larue...@php.net if I don't get a script to reproduce it, then I think,, I can do nothing.. since there is not much info can get from the backtrace [2012-08-28 07:02:45] sergiu dot ionescu at gmail dot com I could, but i think it won't help much. As i stated initially it's a cli script form a Magento/ZF application with quite a few contributed modules. If i can get to a one file script that produces the error i will post it. Is there anything else you can do while you don't have that? 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=62929 -- Edit this bug report at https://bugs.php.net/bug.php?id=62929&edit=1
Bug #63249 [Fbk->Opn]: built-in webserver does not work with Opera browser
Edit report at https://bugs.php.net/bug.php?id=63249&edit=1 ID: 63249 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:built-in webserver does not work with Opera browser -Status: Feedback +Status: Open Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: good guess : http://[::1]:8002/ works my /etc/hosts lists localhost as 127.0.0.1 Previous Comments: [2012-10-09 16:38:23] johan...@php.net As a guess: Might this be an IPv6 issue? Can you try loading http://127.0.0.1:8002/ and http://[::1]:8002/ Please also checks whether your /etc/hosts lists "localhost" as ::1 or 127.0.0.1 [2012-10-09 15:25:25] larue...@php.net sounds very weird, maybe you can debug it with tcpdump, to check whether the request really arrived. [2012-10-09 15:10:31] pascal dot chevrel at free dot fr Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit this bug report at https://bugs.php.net/bug.php?id=63249&edit=1
Bug #63249 [Opn->Fbk]: built-in webserver does not work with Opera browser
Edit report at https://bugs.php.net/bug.php?id=63249&edit=1 ID: 63249 Updated by: johan...@php.net Reported by:pascal dot chevrel at free dot fr Summary:built-in webserver does not work with Opera browser -Status: Open +Status: Feedback Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: As a guess: Might this be an IPv6 issue? Can you try loading http://127.0.0.1:8002/ and http://[::1]:8002/ Please also checks whether your /etc/hosts lists "localhost" as ::1 or 127.0.0.1 Previous Comments: [2012-10-09 15:25:25] larue...@php.net sounds very weird, maybe you can debug it with tcpdump, to check whether the request really arrived. [2012-10-09 15:10:31] pascal dot chevrel at free dot fr Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit this bug report at https://bugs.php.net/bug.php?id=63249&edit=1
Bug #63249 [Opn]: built-in webserver does not work with Opera browser
Edit report at https://bugs.php.net/bug.php?id=63249&edit=1 ID: 63249 Updated by: larue...@php.net Reported by:pascal dot chevrel at free dot fr Summary:built-in webserver does not work with Opera browser Status: Open Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: sounds very weird, maybe you can debug it with tcpdump, to check whether the request really arrived. Previous Comments: [2012-10-09 15:10:31] pascal dot chevrel at free dot fr Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit this bug report at https://bugs.php.net/bug.php?id=63249&edit=1
[PHP-BUG] Bug #63249 [NEW]: built-in webserver does not work with Opera browser
From: pascal dot chevrel at free dot fr Operating system: Linux PHP version: 5.4.7 Package: Built-in web server Bug Type: Bug Bug description:built-in webserver does not work with Opera browser Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit bug report at https://bugs.php.net/bug.php?id=63249&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63249&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63249&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63249&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63249&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63249&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63249&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63249&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63249&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63249&r=support Expected behavior: https://bugs.php.net/fix.php?id=63249&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63249&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63249&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63249&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63249&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63249&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63249&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63249&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63249&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63249&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63249&r=mysqlcfg
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Updated by: re...@php.net Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: @Pascal, I like the idea to make it more modern, I just think the color you choose it not well consist with PHP's blue color and visual identity. Previous Comments: [2012-10-09 12:02:24] pascal dot chevrel at free dot fr I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. 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=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
[PHP-BUG] Bug #63248 [NEW]: ext\fileinfo\tests\bug61964.phpt fails
From: ab Operating system: Windows PHP version: 5.4Git-2012-10-09 (Git) Package: *General Issues Bug Type: Bug Bug description:ext\fileinfo\tests\bug61964.phpt fails Description: As one can see from the diff, there a permissions warning. Tries to set the full permissions didn't work, so I've debugged it. Here is the VS backtrace php_fileinfo.dll!apprentice_map(magic_set * ms, magic * * magicp, unsigned int * nmagicp, const char * fn) Line 2219 C php_fileinfo.dll!apprentice_1(magic_set * ms, const char * fn, int action, mlist * mlist) Line 271 C php_fileinfo.dll!file_apprentice(magic_set * ms, const char * fn, int action) Line 369C php_fileinfo.dll!magic_load(magic_set * ms, const char * magicfile) Line 308 C php_fileinfo.dll!zif_finfo_open(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr, _zval_struct * this_ptr, int return_value_used, void * * * tsrm_ls) Line 345 C php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls) Line 642 C php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls) Line 2236 C php5ts_debug.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls) Line 410C php5ts_debug.dll!zend_execute_scriapts(int type, void * * * tsrm_ls, _zval_struct * * retval, int file_count, ...) Line 1309 C php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file, void * * * tsrm_ls) Line 2482 C php.exe!do_cli(int argc, char * * argv, void * * * tsrm_ls) Line 988 C php.exe!main(int argc, char * * argv) Line 1364 C php.exe!__tmainCRTStartup() Line 582C The warning is produced by the finfo_open() when an existing directory is passed as a magic path. Expected result: Test pass Actual result: -- 003+ Warning: finfo_open(C:\php-sdk\php54\vc9\x86\php-src\ext\fileinfo\tests\test-folder): failed to open stream: Permission denied in C:\php-sdk\php54\vc9\x86\php-src\ext\fileinfo\tests\bug61964.php on line 16 006- Notice: finfo_open(): Warning: offset `string' invalid in %sbug61964.php on line %d 007- 008- Notice: finfo_open(): Warning: offset ` Core' invalid in %sbug61964.php on line %d 008+ Warning: finfo_open(C:\php-sdk\php54\vc9\x86\php-src\ext\fileinfo\tests\test-folder): failed to open stream: Permission denied in C:\php-sdk\php54\vc9\x86\php-src\ext\fileinfo\tests\bug61964.php on line 30 009+ DONE: testing dir with files 010+ ===DONE=== 009- 010- Notice: finfo_open(): Warning: type `Core' invalid in %sbug61964.php on line %d 011- 012- Notice: finfo_open(): Warning: offset `a' invalid in %sbug61964.php on line %d 013- 014- Notice: finfo_open(): Warning: type `a' invalid in %sbug61964.php on line %d 015- 016- Notice: finfo_open(): Warning: offset `b' invalid in %sbug61964.php on line %d 017- 018- Notice: finfo_open(): Warning: type `b' invalid in %sbug61964.php on line %d 019- 020- Warning: finfo_open(): Failed to load magic database at '%stest-folder'. in %sbug61964.php on line %d 021- DONE: testing dir with files 022- ===DONE=== -- Edit bug report at https://bugs.php.net/bug.php?id=63248&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63248&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63248&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63248&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63248&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63248&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63248&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63248&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63248&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63248&r=support Expected behavior: https://bugs.php.net/fix.php?id=63248&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63248&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63248&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63248&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63248&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63248&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63248&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63248&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63248&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63248&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63248&r=mysqlcfg
Bug #62886 [Com]: PHP-FPM may segfault/hang on startup
Edit report at https://bugs.php.net/bug.php?id=62886&edit=1 ID: 62886 Comment by: slim at inbox dot lv Reported by:pierre at archlinux dot de Summary:PHP-FPM may segfault/hang on startup Status: Closed Type: Bug Package:FPM related Operating System: Arch Linux PHP Version:5.4.6 Assigned To:fat Block user comment: N Private report: N New Comment: still same problem with the patch on high loaded php. in logs: [09-Oct-2012 03:11:40] NOTICE: Reloading in progress ... [09-Oct-2012 03:11:40] ERROR: unable to read what child say: Bad file descriptor (9) [09-Oct-2012 03:11:40] ERROR: unable to read what child say: Bad file descriptor (9) [09-Oct-2012 03:11:40] ERROR: unable to read what child say: Bad file descriptor (9) Previous Comments: [2012-10-02 17:19:57] per at techspot dot com Confirmed working on my testserver, thank you! The patch has already been backported into remi's repository, both v5.4 & v5.3 http://rpms.famillecollet.com/enterprise/6/remi/x86_64/repoview/php.html [2012-09-29 05:35:51] f...@php.net done ! [2012-09-28 18:34:29] per at techspot dot com fat: you can probably link this fix to bug #62937 aswell. APC is listed in that bug report, but any opcode cacher just makes this problem with php-fpm surface more regularly due to the increased concurrency... Thanks for the fix! (I'll wait for it's inclusion in the next PHP release though) [2012-09-27 22:55:48] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=75c63c5503b1c6b72e5e1daf5b4bfd02c68a4b79 Log: - Fixed bug #62954 (startup problems fpm / php-fpm) - Fixed bug #62886 (PHP-FPM may segfault/hang on startup) [2012-09-27 22:08:34] f...@php.net Automatic comment on behalf of fat Revision: http://git.php.net/?p=php-src.git;a=commit;h=b5eb1456aa17e83b7b734dfc2316d632c9adcc6c Log: - Fixed bug #62954 (startup problems fpm / php-fpm) - Fixed bug #62886 (PHP-FPM may segfault/hang on startup) 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=62886 -- Edit this bug report at https://bugs.php.net/bug.php?id=62886&edit=1
Bug #63247 [Csd->Asn]: Implemented abstract function with additional parameter having default value
Edit report at https://bugs.php.net/bug.php?id=63247&edit=1
ID: 63247
User updated by:olivier at m2mobi dot com
Reported by:olivier at m2mobi dot com
Summary:Implemented abstract function with additional
parameter having default value
-Status: Closed
+Status: Assigned
Type: Bug
-Package:Documentation problem
+Package:Class/Object related
Operating System: Windows/Linux
PHP Version:5.4.7
Assigned To:googleguy
Block user comment: N
Private report: N
New Comment:
Pacakge didi not match
Previous Comments:
[2012-10-09 14:28:28] google...@php.net
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation better.
[2012-10-09 14:26:49] google...@php.net
This is actually a documentation problem not a bug. The documentation states
"Furthermore the signatures of the methods must match, i.e. the type hints and
the number of required arguments must be the same.", which means that any
number
of optional arguments are allowed in the child method's signature. This is
what's happening here. The second argument is options so it doesn't actually
conflict with the documented behavior.
However, I too did not catch this at first glance. So I've expanded on the docs
for abstract to elaborate on this a bit and added an example in the
documentation demonstrating this feature.
That should help clarify in the future :)
[2012-10-09 13:52:25] olivier at m2mobi dot com
Description:
Implemented abstract function with additional parameter having default value
doesn't cause any error.
Will output:
I am the first arg. I am the additional arg.
I am the first arg. I am the additional arg default value.
If no default value the script crash.
Test script:
---
methodWithOneArg( "I am the first arg.", "I am the additional arg.") ;
echo "" ;
$child->methodWithOneArg("I am the first arg.") ;
Expected result:
FATAL ERROR thrown
Actual result:
--
Just works, addition of a third argument is ignored:
" ;echo "" ;
$child2 = new ConcreteChild2() ;
$child->methodWithOneArg( "I am the first arg.", "I am the additional arg.", "I
am the other additional arg") ;
echo "" ;
$child->methodWithOneArg( "I am the first arg.", "I am the additional arg.") ;
echo "" ;
$child->methodWithOneArg("I am the first arg.") ;
?>
Will output:
I am the first arg. I am the additional arg.
I am the first arg. I am the additional arg.
I am the first arg. I am the additional arg default value.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63247&edit=1
[PHP-BUG] Bug #63247 [NEW]: Implemented abstract function with additional parameter having default value
From: olivier at m2mobi dot com
Operating system: Windows/Linux
PHP version: 5.4.7
Package: Class/Object related
Bug Type: Bug
Bug description:Implemented abstract function with additional parameter having
default value
Description:
Implemented abstract function with additional parameter having default
value
doesn't cause any error.
Will output:
I am the first arg. I am the additional arg.
I am the first arg. I am the additional arg default value.
If no default value the script crash.
Test script:
---
methodWithOneArg( "I am the first arg.", "I am the additional
arg.") ;
echo "" ;
$child->methodWithOneArg("I am the first arg.") ;
Expected result:
FATAL ERROR thrown
Actual result:
--
Just works, addition of a third argument is ignored:
" ;echo "" ;
$child2 = new ConcreteChild2() ;
$child->methodWithOneArg( "I am the first arg.", "I am the additional
arg.", "I am the other additional arg") ;
echo "" ;
$child->methodWithOneArg( "I am the first arg.", "I am the additional
arg.") ;
echo "" ;
$child->methodWithOneArg("I am the first arg.") ;
?>
Will output:
I am the first arg. I am the additional arg.
I am the first arg. I am the additional arg.
I am the first arg. I am the additional arg default value.
--
Edit bug report at https://bugs.php.net/bug.php?id=63247&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63247&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63247&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63247&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63247&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63247&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63247&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63247&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63247&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63247&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63247&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63247&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63247&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63247&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63247&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63247&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63247&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63247&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63247&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63247&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63247&r=mysqlcfg
Req #63242 [Com]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. Previous Comments: [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. 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=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). Previous Comments: [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. [2012-10-08 17:53:00] pascal dot chevrel at free dot fr Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. 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=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Updated by: larue...@php.net Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" Previous Comments: [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. [2012-10-08 17:53:00] pascal dot chevrel at free dot fr Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. [2012-10-08 17:41:00] pascal dot chevrel at free dot fr Description: The default error page in the built-in webserver is very ugly. Looking at the history of the file in the git repository, these styles and html were copied from the phpinfo styling created in 2002 with CSS selectors that had Netscape 4/IE4 compatibility in mind. Appearances matter :) It makes this new PHP feature look already outdated. I am going to attach a patch that: * will make it look a bit more modern and works in responsive mode too * will remove unused css rules from the code * will add an html5 doctype to the error page * will remove unnecesary html attributes in html5 (I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce some of this html, I don't know how tests work for php but I can give a shot at updating the expected results of the tests in the patch if required) -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Updated by: larue...@php.net Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: @pascal, thanks it will be better if you can improve the skeleton keep the "looks" Previous Comments: [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. [2012-10-08 17:53:00] pascal dot chevrel at free dot fr Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. [2012-10-08 17:41:00] pascal dot chevrel at free dot fr Description: The default error page in the built-in webserver is very ugly. Looking at the history of the file in the git repository, these styles and html were copied from the phpinfo styling created in 2002 with CSS selectors that had Netscape 4/IE4 compatibility in mind. Appearances matter :) It makes this new PHP feature look already outdated. I am going to attach a patch that: * will make it look a bit more modern and works in responsive mode too * will remove unused css rules from the code * will add an html5 doctype to the error page * will remove unnecesary html attributes in html5 (I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce some of this html, I don't know how tests work for php but I can give a shot at updating the expected results of the tests in the patch if required) -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Bug #63240 [Opn]: stream_get_line return contains delimiter string
Edit report at https://bugs.php.net/bug.php?id=63240&edit=1
ID: 63240
Updated by: datib...@php.net
Reported by:scope at planetavent dot de
Summary:stream_get_line return contains delimiter string
Status: Open
Type: Bug
Package:Streams related
Operating System: Windows Server 2008 / RHEL 6.2
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
Added a patch that will apply to 5.4.4
Previous Comments:
[2012-10-09 09:02:18] datib...@php.net
The following patch has been added/updated:
Patch Name: getrecord-delimiter-search-fix
Revision: 1349773338
URL:
https://bugs.php.net/patch-display.php?bug=63240&patch=getrecord-delimiter-search-fix&revision=1349773338
[2012-10-09 03:35:35] datib...@php.net
Reduced test:
$file = __DIR__ . '/input_dummy.txt';
$data = str_repeat( '.', 8189 ) . '';
file_put_contents( $file, $data );
$fh = fopen( $file, "rb" );
$delimiter = "MM";
stream_get_line($fh, 4096, $delimiter);
stream_get_line($fh, 4096, $delimiter);
if ($delimiter === stream_get_line($fh, 4096, $delimiter)) {
echo "BROKEN";
} else {
echo "OK";
}
fclose($fh);
unlink($file);
The amount of dots seems to be related to the used buffer length:
( + 3) % ( x 2) == 0
The length of the delimiter also seems to play a role, but I'm not sure what
that would be.
[2012-10-08 16:03:38] scope at planetavent dot de
Description:
On specific file input stream_get_line returns a "line" that actually contains
the delimiter.
PHP 5.3.10 does not show this problem, PHP versions from 5.3.11 to 5.3.17 do.
PHP 5.4.7 seems to be affected as well.
Bug #44607 seems to be related, but was fixed long time ago.
Test script:
---
https://bugs.php.net/bug.php?id=63240&edit=1
Bug #63240 [PATCH]: stream_get_line return contains delimiter string
Edit report at https://bugs.php.net/bug.php?id=63240&edit=1
ID: 63240
Patch added by: datib...@php.net
Reported by:scope at planetavent dot de
Summary:stream_get_line return contains delimiter string
Status: Open
Type: Bug
Package:Streams related
Operating System: Windows Server 2008 / RHEL 6.2
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: getrecord-delimiter-search-fix
Revision: 1349773338
URL:
https://bugs.php.net/patch-display.php?bug=63240&patch=getrecord-delimiter-search-fix&revision=1349773338
Previous Comments:
[2012-10-09 03:35:35] datib...@php.net
Reduced test:
$file = __DIR__ . '/input_dummy.txt';
$data = str_repeat( '.', 8189 ) . '';
file_put_contents( $file, $data );
$fh = fopen( $file, "rb" );
$delimiter = "MM";
stream_get_line($fh, 4096, $delimiter);
stream_get_line($fh, 4096, $delimiter);
if ($delimiter === stream_get_line($fh, 4096, $delimiter)) {
echo "BROKEN";
} else {
echo "OK";
}
fclose($fh);
unlink($file);
The amount of dots seems to be related to the used buffer length:
( + 3) % ( x 2) == 0
The length of the delimiter also seems to play a role, but I'm not sure what
that would be.
[2012-10-08 16:03:38] scope at planetavent dot de
Description:
On specific file input stream_get_line returns a "line" that actually contains
the delimiter.
PHP 5.3.10 does not show this problem, PHP versions from 5.3.11 to 5.3.17 do.
PHP 5.4.7 seems to be affected as well.
Bug #44607 seems to be related, but was fixed long time ago.
Test script:
---
https://bugs.php.net/bug.php?id=63240&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. Previous Comments: [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. [2012-10-08 17:53:00] pascal dot chevrel at free dot fr Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. [2012-10-08 17:41:00] pascal dot chevrel at free dot fr Description: The default error page in the built-in webserver is very ugly. Looking at the history of the file in the git repository, these styles and html were copied from the phpinfo styling created in 2002 with CSS selectors that had Netscape 4/IE4 compatibility in mind. Appearances matter :) It makes this new PHP feature look already outdated. I am going to attach a patch that: * will make it look a bit more modern and works in responsive mode too * will remove unused css rules from the code * will add an html5 doctype to the error page * will remove unnecesary html attributes in html5 (I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce some of this html, I don't know how tests work for php but I can give a shot at updating the expected results of the tests in the patch if required) -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Bug #63241 [Opn->Asn]: PHP fails to open Windows deduplicated files
Edit report at https://bugs.php.net/bug.php?id=63241&edit=1 ID: 63241 Updated by: paj...@php.net Reported by:daniel dot stelter-gliese at innogames dot de Summary:PHP fails to open Windows deduplicated files -Status: Open +Status: Assigned Type: Bug Package:Win32API related Operating System: Windows Server 2012 PHP Version:5.4.7 -Assigned To: +Assigned To:mattficken Block user comment: N Private report: N New Comment: Matt, can you try to reproduce it please? Previous Comments: [2012-10-08 16:17:44] daniel dot stelter-gliese at innogames dot de Description: Opening a file that was deduplicated by Windows Server 2012 deduplication fails with "No such file or directory". The behavior can be reproduced locally and through SMB shares (on Win7 and Win8 clients). I've tried 5.3.15 and 5.4.7 - judging from the code latest snapshots are affected, too. I could trace this to a problem with reparse points: deduplication adds the new reparse tag IO_REPARSE_TAG_DEDUP. There seems to be no documentation on this tag, so I could only interpret it as a flag to be ignored. The attached patch simply treats a IO_REPARSE_TAG_DEDUP file as a substitute on the same path, which worked well. Test script: --- $path = 'S:\\test.exe'; var_dump(filesize($path)); var_dump(realpath($path)); var_dump(strlen(file_get_contents($path))); var_dump(fopen($path, 'rb')); Expected result: int(5448704) string(50) "S:\test.exe" int(5448704) resource(6) of type (stream) Actual result: -- int(5448704) bool(false) Warning: file_get_contents(S:\test.exe): failed to open stream: No such file or directory in C:\php-sdk\php54dev\vc9\x64\ php-5.4.7-src\x64\Release\test.php on line 6 int(0) Warning: fopen(S:\test.exe): failed to op en stream: No such file or directory in C:\php-sdk\php54dev\vc9\x64\php-5.4.7-sr c\x64\Release\test.php on line 7 bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=63241&edit=1
Bug #63245 [Opn->Nab]: Upgrade from 5.3.6 to 5.3.17 resulted in PHP Fatal error..
Edit report at https://bugs.php.net/bug.php?id=63245&edit=1 ID: 63245 Updated by: paj...@php.net Reported by:cetojevic at hotmail dot com Summary:Upgrade from 5.3.6 to 5.3.17 resulted in PHP Fatal error.. -Status: Open +Status: Not a bug Type: Bug Package:Reproducible crash Operating System: Windows Server Standard Sp1 PHP Version:5.3.17 Block user comment: N Private report: N New Comment: Enable the com_dotnet extension in your php.ini. The extension has been built as shared lately for security reasons. Previous Comments: [2012-10-09 07:42:54] cetojevic at hotmail dot com Description: Simple upgrade from 5.3.6 to 5.3.17 resulted in PHP Fatal error: Class 'VARIANT' not found. PHP code that worked flawlessly under version 5.3.6, without any change, under version 5.3.17 failed on following line: $this->_affectedRows = new VARIANT; -- Edit this bug report at https://bugs.php.net/bug.php?id=63245&edit=1
[PHP-BUG] Bug #63245 [NEW]: Upgrade from 5.3.6 to 5.3.17 resulted in PHP Fatal error..
From: cetojevic at hotmail dot com Operating system: Windows Server Standard Sp1 PHP version: 5.3.17 Package: Reproducible crash Bug Type: Bug Bug description:Upgrade from 5.3.6 to 5.3.17 resulted in PHP Fatal error.. Description: Simple upgrade from 5.3.6 to 5.3.17 resulted in PHP Fatal error: Class 'VARIANT' not found. PHP code that worked flawlessly under version 5.3.6, without any change, under version 5.3.17 failed on following line: $this->_affectedRows = new VARIANT; -- Edit bug report at https://bugs.php.net/bug.php?id=63245&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63245&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63245&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63245&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63245&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63245&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63245&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63245&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63245&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63245&r=support Expected behavior: https://bugs.php.net/fix.php?id=63245&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63245&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63245&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63245&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63245&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63245&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63245&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63245&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63245&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63245&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63245&r=mysqlcfg
